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 <[email protected]>: > 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 <repositories> 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 <repository> 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 <repository> 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 <repositories> 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 <[email protected]> >> An: Maven Developers List <[email protected]> >> 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
