One of the purposes of the new PDT file is to improve to speed to get the fully resolved POM. One of the downsides of the current pom model is that in case of multiple third-party artifacts with their own repository, Maven will always go top-down through the list of repositories. It would help if there's a reference to the location per artifact.

When the artifact is downloaded, Aether generates a _remote.repositories file, which contains the identifier of the repository when this artifact is coming from.

 

 

 

 

<project>
  <repositories>
    <repository>
      <id/>
      <url/>
    </repository>
  </repositories>

  <artifacts>
    <!-- 
    <artifact>
      <!-- GAV etc -->
      <repository>central</repository> 
    </artifact>
    <artifact>
      <!-- GAV etc -->
      <repository>jboss</repository>
    </artifact>

    <artifact>
      <!-- no repository reference, which means it must be part of a multimodule project.
           When downloading this project, you can use its repository for this artifact too. -->
      <!-- GAV etc -->
    </artifact>

  </artifacts>
</project>

Mirrors

Mirrors were originally intended to redirect old repository URLs to new one. The '*' in case of a repository manager is actually a hack. A repository manager acts as a proxy, hence it might have been better to solve it like that.

When generating the PDT and when there's no '*', the mirror should be seen as a changed URL for the old repository, hence this should be used in the PDT as the repository URL.

 

 

 

 

 

 

 

 

 

 

 

  • No labels

3 Comments

  1. Stephen Connolly

    So is your thinking that this would just be a hint for optimistic optimisation? If the artifacts were not resolved from the users proxy for that id, we'd fall back and try all the other repositories in turn, or would we stop and fail?

    1. Robert Scholte

      That's up to the client. Maven2 and Maven3 always went through repo's one by one until the artifact was found.

  2. Christian Schulte

    It would help if there's a reference to the location per artifact.


    Which leads us to an old proposal on dev@ to use group id and the DNS to get at that information. Question to answer is: Who defines those locations? The producer of the artifact, not the consumer, IMHO. So we could just use DNS TXT records (specifying authoritative locations of an artifact) to tell Maven from where to download artifacts. Controlling this yourself, you would need to point Maven to your own DNS server in e.g. the settings.xml and maintain that server yourself. That's not much of a difference to maintaining your own repository manager which could easily be enhanced to answer DNS requests in addition or instead of HTTP (wink).