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<[email protected]> 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: [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]
