> 1) Pretty simple, and works with repository managers. Not sure about that. I'm not into RepoManagers that deep, but don't they have the exact same problem? Means the RepoManager only sees this if the repo got added manually to the manager, or if a project with that missing repo got picked up by compiling a project which defined it?
Or does nexus pick a repo on the list if it detects a transitive dependency containing a <repositories> section? Anyway, it comes down to being one of the 3 use cases we had before. LieGrue, strub ----- Ursprüngliche Mail ---- > Von: Jason van Zyl <ja...@sonatype.com> > An: Maven Developers List <dev@maven.apache.org> > Gesendet: Freitag, den 30. Oktober 2009, 17:16:51 Uhr > Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > > There are three primary variants of how the artifact resolution can work with > respect to repositories where RS is the set of remote repositories that will > be > used for artifact resolution: > > 1) RS is what's available in the effective POM. Easy. > 2) RS is collect from inspecting metadata transitively and reconciling the > repositories found as a set before artifact resolution. Difficult. > 3) RS is collection of partitions of sub-trees where the individual > repositories > are found. The reconciliation process becomes a backchaining mediation. > Extremely difficult. > > 1) Pretty simple, and works with repository managers. Most large > organizations > will use one within a year. I love this idea from a Sonatype perspective, but > from a Maven user perspective we potentially cripple OSS projects. What we > decide to do here has long lasting effects. A variation on what Josh Bloch > says > about APIs. API design (and corresponding behavior) is like sex. Make one > mistake and you support it for the rest of your life. If we pick this method > it > will categorically change the internals of the repository system and it will > make it pretty much impossible to change to 2) or 3) in a practical way. > Based > on empirical observations in that aside from Oleg, Benjamin, Igor, and myself > (all Sonatype at the time of implementation) no one has contributed anything. > This is just not something that can be tinkered with so thinking we can try > this > method and then back it out and make it more sophisticated later is a pipe > dream. > > I think 2) and 3) require a lot of discussion. So really I think it boils > down > to are we going to really make 1) the way it works? Otherwise I think we are > also obliged to look at the models in P2 and OBR because it probably doesn't > make sense to re-invent another mediation and reconciliation mechanism. > > On 2009-10-29, at 12:27 PM, Brian Fox wrote: > > > It's amazing how google's thread compression of a discussion can cause > > me to overlook a huge thread so near and dear to my heart. > > > > To start, Benjamin has hit the nail on the head of a discussion point > > Jason and I have had going for quite some time. In fact, we even wrote > > up a proposal for it months ago that got little feedback. I've also > > blogged on this subject before. > > > > Written and suggested reading in this order: > > > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ > > > http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery > > > > I won't rehash all of what I've already written, and leave it to the > > reader to follow the above urls for the majority of the points however > > I think there is one key argument that is worth reiterating: > > > > The ability of a user to checkout an open source project with no prior > > knowledge of it and simply be able to build it, run the tests and > > patch it the first try is the most powerful way to demonstrate the > > Maven to new users. Simply removing or ignoring repositories in the > > poms will break this functionality that I feel pretty strongly about. > > > > All of the arguments so far in this thread mostly revolve around > > issues in corporate / enterprise use, and for these issues repository > > managers are the best solution. I don't think its in the best interest > > of the community to break OSS use to support Enterprise use, > > particularly when that problem is already covered. > > > > Specifically, I'm pretty strongly in favor of continuing to support > > repositories declared in poms, however they should be scoped for only > > the subtree of dependencies introduced by the pom declaring the repo. > > Further, I recognize that having urls burned into immutable poms is > > not the best way to accomplish this, and I think we need to find a > > better one pretty quickly. > > > > --Brian > > > > On Wed, Oct 28, 2009 at 7:57 PM, Stephen Connolly > > wrote: > >> 2009/10/28 Brett Porter > >> > >>> > >>> On 29/10/2009, at 2:08 AM, Daniel Kulp wrote: > >>> > >>> On Wed October 28 2009 10:53:10 am John Casey wrote: > >>>> > >>>>> I tend to agree, they should not really be used. It seems like these > >>>>> third-party repositories have a strong potential for causing network > >>>>> errors (in cases where the repo is down or on a private network), and > >>>>> they definitely push the user in the direction of trusting anything that > >>>>> comes from anywhere on the internet without thinking twice...not a great > >>>>> idea, and an understandably unpopular one with companies. > >>>>> > >>>>> I think the role of the declaration in the POM should be > >>>>> shifted in Maven 3. I think this along the same lines that Brett was > >>>>> talking, but I'd really like to see them take on an advisory role rather > >>>>> than actively participate in resolution. In other words, if an artifact > >>>>> cannot be found, then display the list of third-party repositories which > >>>>> MIGHT contain the artifact, along with the POM that lists that > >>>>> repository. > >>>>> > >>>> > >>>> I'm OK with that EXCEPT for repositories defined in the current > >>>> pom+parents. > >>>> For transitive dependencies, yes, but not for building the current > >>>> project. > >>>> > >>>> > >>> +1 > >>> > >>> This avoids fudging with settings.xml, which has other problems that > >>> others > >>> have mentioned, and also because you start building a long list of > >>> repositories then used on *every* project (unless Maven adds some other > >>> gid > >>> restriction on repositories). > >> > >> > >> +1... though this has the side-effect that if you checkout a project who's > >> parent is only in a repository specified in the parent... well hey, it's > >> not > >> our fault! ;-) > >> > >> > >>> > >>> > >>> On 29/10/2009, at 4:22 AM, Dan Rollo wrote: > >>> > >>> To advocate the other side: I like the ability to define repositories in > >>>> the pom.xml because team members (oss or corporate) can simply "get > >>>> latest" > >>>> from the source bank and things work OOTB. > >>>> > >>>> I don't like the idea that the only way for things to work OOTB is if all > >>>> artifacts MUST come from 'central'. There are other open source repo's in > >>>> wide use. Same with private/corporate repos. > >>>> > >>>> Forcing an edit to settings.xml (usually located in the user home dir) is > >>>> also a maintenance issue for automated builds. > >>>> > >>> > >>> Agreed - I think the proposal above gives a balance between the two > >>> concerns. > >>> > >>> - Brett > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > 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
