Thanks Stephen! Wasn't aware that Brett had the same idea a long time ago. Found it now:
http://markmail.org/thread/wqi43wiwbj43vwq6 It would be a good amount of work, but since this seems to pop up regulary, we may think about it for m3. LieGrue, strub ----- Ursprüngliche Mail ---- > Von: Stephen Connolly <stephen.alan.conno...@gmail.com> > An: Maven Developers List <dev@maven.apache.org> > Gesendet: Freitag, den 30. Oktober 2009, 10:27:36 Uhr > Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > > This was a proposal about a year or two back.... IIRC there were other > more pressing issues and nothing much happened since. > > The proposal was part of the "make repository access thread-safe" for > people using maven on CI systems, or running builds in parallel from > the CLI > > -Stephen > > 2009/10/30 Mark Struberg : > > Hi! > > > > Just make a step back and look at the repository problematic from a bit > different perspective. > > > > I'm working for a few companies and even different projects in those > > companies > use different sections in their poms. > > But in my local repo, all the artifacts from those repositories gets merged > > to > a single big landfill. > > > > When I switch to a different project, with no repositories configured, I > > may > pick up a wrong dependency this way. Or I may be able to compile and even > release, but my colleagues are not, because this very is missing in > the projects pom. > > > > What about remembering where an artifact came from in the local repo? > > E.g. something like > > > > ~/.m2/repository // this contains the locally installed artifacts and > > stuff, > and also acts for backward compatibility. It is always 'active'] > > ~/.m2/repositories/[http_repo1.maven.org.maven2]/com/apache... > > ~/.m2/repositories/[http_dev.java.net/maven2]/javax/enterprise... > > > ~/.m2/repositories/[http_dist.codehaus.org_mule_dependencies_maven2]/org/jruby... > > > > If a is not activated for a specific project then the local > artifacts will not be picked up. from .m2/repositories. If a transitive > dependency defines a new those will be added at the end of the > chain. We should think about collision detection, but this should be > detectable > at least. > > > > There are most probably also things to consider for repository managers. > > > > I'm not sure if it is worth the effort though. > > > > LieGrue, > > strub > > > > > > > > > > > > ----- Ursprüngliche Mail ---- > >> Von: Brian Fox > >> An: Maven Developers List > >> Gesendet: Donnerstag, den 29. Oktober 2009, 20:27:00 Uhr > >> Betreff: Re: [DISCUSS] Handling of repositories in POMs of dependencies > >> > >> 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 > > > > > > > > > > > > --------------------------------------------------------------------- > > 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
