Recommended JFrog Artifactory Layout setup for Maven Projects

Question

We are very new in using Artifactory services, we would like to store all our artifacts in JFrog Artifactory server for dependency as well as for release management. I have currently created one Local Repository in the name 'myartifactory' and I am planning to use the following code in my projects pom.xml file for distribution management.

<distributionManagement>
    <repository>
        <id>central</id>
        <name>jd-releases</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>jd-snapshots</name>
        <url>http://jd-msg.staging.com/artifactory/myartifactory</url>
    </snapshotRepository>
</distributionManagement>

Does the above method looks like a recommended way? How about having "Remote Repositories" and "Virtual Repositories"? Is it mandatory to have? What is the real life example for those?

In addition artifactory by default recommends some best practices for Local Repositories like the following,

Pre-defined Local Repositories: - Artifactory comes with a set of pre-defined local repositories, which reflect best practices in binary repository management as follows:

libs-release-local - Your code releases
libs-snapshot-local - Your code snapshots
ext-release-local - Manually deployed 3rd party libs (releases)
ext-snapshot-local - Manually deployed 3rd party libs (shapshots)
plugins-release-local - Your and 3rd party plugins (releases)
plugins-snapshot-local - Your and 3rd party plugins (snapshots)

So I am bit confused about the right approach. Suggestions are welcome.

Answer 1

Within Artifactory there are three types of repositories:

1. Local: Local repositories are physical, locally-managed repositories into which you can deploy artifacts
2. Remote: A remote repository serves as a caching proxy for a repository managed at a remote URL
3. Virtual: A virtual repository (or "repository group") aggregates several repositories with the same package type under a common URL.

Local and remote repositories are true physical repositories (they exist either on your server on on a remote server somewhere else), while a virtual repository is actually an aggregation of them used to create controlled domains for search and resolution of artifacts.

If you need all of those types depends a bit on your use case. A real world use case for a remote repository would be Maven Central or jCenter where developers host their Maven packages. JFrog Artifactory can serve as a cache for those services so that not every call to resolve Maven dependencies has to go through the Internet. A real world use case for a virtual repository is that I have a remote repo (like the ones I already mentioned) and a few local repos too (like the ones you mentioned in your question). I want to make sure that my developers only need to configure one Maven repository as URL and my virtual repository allows me to do that. With a virtual repo, I can group together all sorts of other repositories and give one URL to developers so I can manage which dependencies are allowed as opposed to resolving them from the Internet every time.

Based on lessons learned we've included some default repositories into Artifactory that follow the flow of most developers that use Maven. Having said that, there is nothing stopping you from adopting your own workflow and not using the default repos.