The use of <repositories> even with a symbolic id assumes there's only one canonical location for the artifact. I don't think that's true and would never want to be the end-user who has to manage those symbolic ids. I still advocate removing this tag. I think it's the job of the intermediary (like Nexus) to write some metadata on where it last found the artifact and then only searching others upon failure retrieving a different version / update.
Cheers, Paul On Fri, Jul 4, 2014 at 2:52 PM, Robert Scholte <rfscho...@apache.org> wrote: > I fully agree on the SHA1 check and the repo manager protocol, but as long > as we need the <repositories/> in the pom.xml, the repositoryId can help to > optimize the searchpath for the artifacts. > > That would make the pom responsible for mapping dependency to the original > repositoryUrl and the repository manager for mapping the original > repositoryUrl to the ultimate repositoryUrl. > > Or don't do it to encourage projects to push their artifacts to Maven > Central. > > thanks, > Robert > > Op Fri, 04 Jul 2014 19:08:16 +0200 schreef Jason van Zyl <ja...@takari.io > >: > > If you consider the identity of the artifact to be its SHA1, >> theoretically it doesn't matter where it comes from. This is not to say >> that's optimal to go looking everywhere for an artifact. How this is >> constrained in Nexus is through routing rules where Nexus knows only to >> look for given groupIds in a particular repository and this great optimizes >> lookup times. One might argue this type of logic can be moved back into >> Maven itself. >> >> As we discussed in the hangout, and I agree with Igor, that mirrors were >> an error and likely something we should eliminate in Maven 4.0.0 and work >> on a repository manager protocol like we discussed. >> >> On Jul 4, 2014, at 12:56 PM, Robert Scholte <rfscho...@apache.org> wrote: >> >> In addition to our hangout session: isn't it weird that for a dependency >>> Maven can go over all the repositories, even though when an extra >>> repository is added to the pom.xml, the developer knows exactly which >>> dependencies should make use of that repository. >>> >>> To me it would make sense if you could add a reference to the repository >>> per dependency, like >>> >>> <dependency> >>> <groupId>com.acme</groupId> >>> <artifactId>specialtool</artifactId> >>> <version>1.0-alpha-1</version> >>> <repositoryId>acme-store</repositoryId> <!-- only look in this repo, I >>> know it's not in Central --> >>> </dependency> >>> >>> Robert >>> >>> Op Thu, 03 Jul 2014 00:37:17 +0200 schreef Mark Derricutt < >>> m...@talios.com>: >>> >>> On 3 Jul 2014, at 6:25, Robert Scholte wrote: >>>> >>>> This is probably more than enough for tomorrow. >>>>> >>>> >>>> A discussion on a merits and flaws of <repositories> (when combined >>>> with mirrors) is also warranted after some previous discussion on the list. >>>> >>>> Mark >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> Our achievements speak for themselves. What we have to keep track >> of are our failures, discouragements and doubts. We tend to forget >> the past difficulties, the many false starts, and the painful >> groping. We see our past achievements as the end result of a >> clean forward thrust, and our present difficulties as >> signs of decline and decay. >> >> -- Eric Hoffer, Reflections on the Human Condition >> >> >> >> >> >> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
