A solution I am tending towards is a repositories.xml file adjacent to the pom.xml
This covers #1 and makes #2 redundant #3 and #4 are separate issues IMHO 2009/7/8 Stephen Connolly <stephen.alan.conno...@gmail.com> > >> 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 > I see this as a separate problem from repositories in the pom > > >> 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 > I think this is a bad plan. It's your build, you specify where dependencies can come from. If somebody else depends on your artifact, they specify where dependencies can come from. We should provide tools to make it easy for them to grab the repos you specified (assuming they trust you ;-) ) > > >> 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 > > > > > >
