How maven repositories are resolved?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How maven repositories are resolved?

Debraj Manna
Cross-posting from stackoverflow
<https://stackoverflow.com/questions/63071141/how-maven-repositories-are-resolved>

Let's say my settings.xml is defined like below

<?xml version="1.0" encoding="UTF-8"?><settings
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0
http://maven.apache.org/xsd/settings-1.1.0.xsd"
xmlns="http://maven.apache.org/SETTINGS/1.1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <profiles>
   <profile>
     <repositories>
       <repository>
         <snapshots>
           <enabled>false</enabled>
         </snapshots>
         <id>central</id>
         <name>libs-release</name>
         <url>http://artifactory.ark.local:8080/libs-release</url>
       </repository>
       <repository>
            <id>vmware-repo</id>
            <name>VM Nexus Repo</name>
            <url>http://build-squid.eng.vm.com/nexus/content/groups/repo</url>
            <releases>
                <enabled>true</enabled>
            </releases>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
        </repository>
       <repository>
         <snapshots />
         <id>snapshots</id>
         <name>libs-snapshot</name>
         <url>http://artifactory.ark.local:8080/libs-snapshot</url>
       </repository>
     </repositories>
     <pluginRepositories>
       <pluginRepository>
         <snapshots>
           <enabled>false</enabled>
         </snapshots>
         <id>central</id>
         <name>plugins-release</name>
         <url>http://artifactory.ark.local:8080/plugins-release</url>
       </pluginRepository>
       <pluginRepository>
         <snapshots />
         <id>snapshots</id>
         <name>plugins-snapshot</name>
         <url>http://artifactory.ark.local:8080/plugins-snapshot</url>
       </pluginRepository>
     </pluginRepositories>
     <id>artifactory</id>
   </profile>
 </profiles>
 <activeProfiles>
   <activeProfile>artifactory</activeProfile>
 </activeProfiles></settings>

In a multimodule project of the form

main
    storage
        metrics
        config
    common

Let's say in metrics pom if a repository is added.

<repository>
  <id>cloudera</id>
  <url>https://repository.cloudera.com/artifactory/cloudera-repos/</url></repository>


   1.

   If a dependency is defined in A which is present in both cloudera repo
   and local nexus repo how maven will resolve the repository? Will, it first
   try to download from cloudera repo and if there is some problem then it
   will go in local nexus repo or it will check only in cloudera repo and if
   it is not present it will give error without trying from local nexus repo?
   2.

   Does the answer to the above question change based on if A is defined as
   a dependency in metric or some other pom where the repository is not
   defined?

Maven Version - 3.6.3
Reply | Threaded
Open this post in threaded view
|

Re: How maven repositories are resolved?

John Patrick
The answer depends on the following;

1) is it a release version or snapshot version. As if the release
version is in local repo then no remote repo's are checked.
2) order your pom's are executed

I've simplified your profiles with central repo and company repo, and
Aa, Ab and Ac are the same GAV but it's just so in the explanation
it's easier to know what A i'm talking about.

settings
- central repo (contains Aa)
- company repo (contains Ab)

parent-pom
- alpha
-- A
- bravo (has extra R repository like your cloudera, contains Ac)
-- A
- charlie
-- A

For release version assuming empty local repo.
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list
- Bravo needs A, it sees Aa in local repo and uses it
- Charlie needs A, it sees Aa in local repo and uses it

Same as before but maven believe build order is bravo, alpha, charlie,
i.e. you've changed an internal dependency or reorder you modules
section.
- Bravo needs A, and Ac is downloaded as it's in R repo and that was
1st repo in the order list, which i think it's pom repo's then parent
pom's then settings file.
- Alpha needs A, it sees Ac in local repo and uses it
- Charlie needs A, it sees Ac in local repo and uses it

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-1
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Aa is newer so Aa is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Aa is used.

Next is if A is a -SNAPSHOT dependency assuming empty local repo, Aa
is v 1-1, Ab is v1-1 and Ac is v1-2
- Build order this time alpha, bravo, charlie
- Alpha needs A, and Aa is downloaded as it's in central repo and that
was 1st repo in the order list, but it has a cache of Ab existing
- Bravo needs A, it sees it doesn't have a cache of A from R repo, so
looks up A from R repo, and if Ac in R repo is newer it is downloaded
and used. in this case Ac is newer so Ac is used.
- Charlie needs A, it sees all repo's have caches of A, and just uses
the A in the local repo, in this case Ac is used.



As you can see it can get very messy when -SNAPSHOT's are being used
and different pom's have repo. This is my hands-on experience of trial
and error, debugging and troubleshooting of build processes.

Hope it was helpful.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]