Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor mentioned, could be used as uris, sorta).
Nx even today stores all the urls a cached artifact was downloaded in its own attributes (you can check it with ?describe request). The only problem currently is that if you access repo over a group - the mrm side of nasty mirrorOf - the overlaid paths are "shaded", this is why group member ordering matters. Also, currently nx does not receive any extra hint beside the path, so it cannot tinker a lot about maven expectations, this should be part of richer mrm protocol. thanks (phone), ~t~ On Jul 5, 2014 2:17 AM, "Martin Gainty" <mgai...@hotmail.com> wrote: > > > > Date: Fri, 4 Jul 2014 18:31:35 -0500 > > Subject: Re: Maven Developer Hangout > > From: pbened...@apache.org > > To: dev@maven.apache.org > > > > 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. > > MG>Paul..Where would the discovered repository metadata be > written?..distributionManagement? > > MG>Tamas ...is this possible? > > > > > > 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 > > > > > > >
