> > > 1. maintain the ability for a user to checkout your code and run mvn > install and have it work with no prior setup on their part. > > Hmmm... there are +++'s and ---'s with this one
> > 1. > 2. be able to depend on some jar and not worry about any repositories > required for transitive resolution (ie discover the repositories > transitively as dependencies are processed) *(this is controversial and > may be eliminated. First it contributes to the Problem #4 above in that SAT > can't be done on a bounded list of repositories. It also doesn't work > normally behind a repository manager because the list of repos is usually > controlled in the repo manager and thus autodiscovery is intentionally > blocked, usually via a mirrorOf * to circumvent the repos maven finds in > the > poms.)* > > Not sure i agree with this one > > 1. ** > 2. be able to separate the dependencies needed by maven plugins from > those needed by the build. This means not only where they are resolved > from, > but also how they are stored locally to prevent cross-contamination. > > I am less convinced this is necessary these days... better is separation of repo caches in local > > 1. > 2. Repository identification: at this point we are pretty much in > agreement that the URL should be the unique identifier for a repository. > People who care about what they are publishing either need to use canonical > repositories like Maven central or need to guarantee the existence of the > repositories or have decent pointers. In a fully distributed system the > relocation mechanism we have does not work in a fully distributed system > without a master to manage relocations. > > +1 2009/7/8 Brian Fox <bri...@infinity.nu>: > BTW, we already wrote a proposal on this that got relatively little > feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery > > On Wed, Jul 8, 2009 at 5:29 PM, Paul Gier<pg...@redhat.com> wrote: >> Daniel Kulp wrote: >>> >>> On Wed July 8 2009 4:13:24 pm Benjamin Bentmann wrote: >>>> >>>> Paul Gier wrote: >>>>> >>>>> One issue that will need to be resolved before we can sync, is how to >>>>> handle our rebuilt thirdparty jars. For example, if a jboss project >>>>> needs to patch some thirdparty jar, rebuild it, and upload it to our >>>>> repository >>>> >>>> AFAIK, somebody building a patched third-party artifact is supposed to >>>> not deploy this derived artifact with its original group id but with the >>>> group id of the patch creator. So if JBoss creates a patched version of >>>> say log4j, it would need to get deployed with org.jboss:log4j or >>>> similar. This should be allowed to get synced into central as it can be >>>> distinguished from the original log4j:log4j artifact of the project >>>> owner. >>> >>> Except there THEN becomes the issue if someone depends on the normal log4j >>> artifact as well as some JBoss artifact that then transitively pulls in >>> org.jboss:log4j, they end up with two versions of log4j on the classpath >>> with all kinds of non-fun things happening. >>> >>> Dan >>> >> >> Yes, this is the major problem that we would have with changing the groupId >> for rebuilt artifacts. It works fine for small projects, but for a large >> dependency tree it is currently a big hassle to try to track down and >> exclude every place where the original groupId/artifactId is included >> transitively. >> >> Allowing some kind of global exclusions would be a good start (MNG-1977, >> MNG-3196). We currently use the enforcer plugin, but I still have to add in >> exclusions every time the same dependency is reintroduced in a new location >> in the tree. Also, anyone depending on the JBoss project might then have to >> add exclusions to their projects to get only the correct dependencies. >> >> But ideally there would be some way to link groupId:artifactId combinations >> as suggested by Stephen and Carlos. This would also help resolve artifacts >> that are renamed between versions which happens occasionally. Is there any >> work to handle this use case in Mercury? >> >>> >>>> >>>> Benjamin >>>> >>>> --------------------------------------------------------------------- >>>> 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 > >
