Le samedi 5 juillet 2014 13:30:13 Robert Scholte a écrit : > Op Sat, 05 Jul 2014 10:38:29 +0200 schreef Tamás Cservenák > > <ta...@cservenak.net>: > > Yes. But repo IDs are meaningless imo, urls are a bit better (as Igor > > mentioned, could be used as uris, sorta). > > Exactly. *If* this is solved in the pom, you have to pass the original > repositoryUrl as an extra argument to the repository manager. If there are > multiple repositories, then you could help the searchpath for an artifact > by directly referring to the expected repository, either by adding the > repositoryUrl to the <dependency> or referring to the <repository> by id, > which already exists in the definition of the pom. AFAIK, the 2 layers that change the repository id are: - settings' mirror, where 1 mirror id hides multiples repository ids - repository manager, which can sum multiple repositories behind 1 url improving the protocol between mirror and repository manager could bring back a meaning to the repository id
> > Removing the repository elements from the pom would mean that users: > 1. are required to use a repository manager. > 2. have to know the target repository and configure it. > I don't think users want to do this kind of additional actions to have > their project up and running. +1 Regards, Hervé > > thanks, > Robert > > > 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 > > --------------------------------------------------------------------- > 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
