You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@maven.apache.org by Debraj Manna <su...@gmail.com> on 2020/07/29 14:07:46 UTC

How maven repositories are resolved?

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

Re: How maven repositories are resolved?

Posted by Debraj Manna <su...@gmail.com>.

Thanks John for such a detailed explanation. Few doubts

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


When you say central repo is the first repo in the order list , how is
order determined? Is it because central repo is defined before company repo
in the settings.xml ?

What is the "cache" you are referring to in your answer?


On Thu, Jul 30, 2020 at 1:33 AM John Patrick <nh...@gmail.com> wrote:

> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: How maven repositories are resolved?

Posted by John Patrick <nh...@gmail.com>.

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org