Answers: <p>Within Artifactory there are three types of <a href="https://www.jfrog.com/confluence/display/RTF/Configuring+Repositories" rel="nofollow noreferrer">repositories</a>:</p>
  
  <ol>
  <li><strong>Local</strong>: Local repositories are physical, locally-managed repositories
  into which you can deploy artifacts </li>
  <li><strong>Remote</strong>: A remote repository
  serves as a caching proxy for a repository managed at a remote URL</li>
  <li><strong>Virtual</strong>: A virtual repository (or "repository group") aggregates
  several repositories with the same package type under a common URL.</li>
  </ol>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-09T03:10:20.570Z
Answers: 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?
Answers: Xason Jack
Answers: CC BY-SA 4.0
Answers: 2019-01-11T00:49:16.257Z
Answers: 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).
Answers: retgits
Answers: CC BY-SA 4.0
Answers: 2019-01-08T22:20:46.723Z
Answers: 2019-01-08T22:20:46.723Z
Answers: retgits
Body: <p>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.</p>
  
  <pre><code>&lt;distributionManagement&gt;
      &lt;repository&gt;
          &lt;id&gt;central&lt;/id&gt;
          &lt;name&gt;jd-releases&lt;/name&gt;
          &lt;url&gt;http://jd-msg.staging.com/artifactory/myartifactory&lt;/url&gt;
      &lt;/repository&gt;
      &lt;snapshotRepository&gt;
          &lt;id&gt;snapshots&lt;/id&gt;
          &lt;name&gt;jd-snapshots&lt;/name&gt;
          &lt;url&gt;http://jd-msg.staging.com/artifactory/myartifactory&lt;/url&gt;
      &lt;/snapshotRepository&gt;
  &lt;/distributionManagement&gt;
  </code></pre>
  
  <p>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?</p>
  
  <p>In addition artifactory by default recommends some best practices for Local Repositories like the following,</p>
  
  <p>Pre-defined Local Repositories:
  - Artifactory comes with a set of pre-defined local repositories, which reflect best practices in binary repository management as follows: </p>
  
  <pre><code>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)
  </code></pre>
  
  <p>So I am bit confused about the right approach. Suggestions are welcome.</p>
  
Tags: <artifactory>
Title: Recommended JFrog Artifactory Layout setup for Maven Projects
UserDisplayName: Xason Jack
ThreadText: # Recommended JFrog Artifactory Layout setup for Maven Projects
  
  (Asked by: username_0 on 2019-01-08)
  
  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.
  
  **Tags:** artifactory
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-01-08. Score: 0 | Accepted answer
  
  Within Artifactory there are three types of [repositories](https://www.jfrog.com/confluence/display/RTF/Configuring+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.
  
  > **Comments:**
  > **username_0**: 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?  
  > **username_1**: 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).  
  
  ---
  
  