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.


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.

1 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.

  • 1
    If I only have Local Repository, then does that mean every time it will collect dependencies from internet and only publishes my project artifacts to repository?
    – Xason Jack
    Jan 9, 2019 at 3:10
  • If you only have a local repository in Artifactory and your Maven configuration only points to that repository, it will only try to collect the dependencies from Artifactory and your builds will fail if the dependency isn't in Artifactory. That's why most people set up a remote repository as well and combine those two in a virtual repository. That virtual repo is used in the Maven configuration. In that case, your builds will get the local dependencies from Artifactory and the others from another service (like jCenter).
    – retgits
    Jan 11, 2019 at 0:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.