2009/7/8 Stephen Connolly <stephen.alan.conno...@gmail.com>: > OK, a problem... > > what if I have both org.jboss.thirdparty:log4j *and* > com.sun.thirdparty:log4j on my classpath? > > we have to give a warning of some sort... perhaps fail the build and > let the user resolve this through exclusions.... > > in this regard a scope of "relocation" might be better... as we would > not want people "bundling" several artifacts into the one artifact. >
Or we could blow up the build if you try to have more than one "implements" scope dependency in any one project... that'll solve it! > 2009/7/8 Stephen Connolly <stephen.alan.conno...@gmail.com>: >> Hmmm, how would this work w.r.t. resolving... >> >> If I add log4j:log4j and org.jboss.thirdparty:log4j as dependencies, >> then I would get both artifacts on my classpath with a warning from >> Maven. >> >> If I add log4j:log4j as a direct, and org.jboss.thirdparty:log4j as a >> transitive via another dependency, then I get both artitfacts and >> Maven would print a warning >> >> If I add org.jboss.thirdparty:log4j as a direct, and log4j:log4j as a >> transitive via another dependency, then I get only >> org.jboss.thirdparty:log4j as the transitive dependency has already >> been provided by a nearer dependency >> >> >> 2009/7/8 Stephen Connolly <stephen.alan.conno...@gmail.com>: >>> other possible names for the scope could be "encapsulated", or "bundled" >>> >>> 2009/7/8 Stephen Connolly <stephen.alan.conno...@gmail.com>: >>>> we really need some sort of >>>> >>>> <provides> >>>> <groupId>log4j<groupId> >>>> <artifactId>log4j</artifactId> >>>> <version>[1.2.5,1.3)</version> >>>> </provides> >>>> >>>> another option would be to add a new scope, e.g. implemented >>>> >>>> <dependency> >>>> <groupId>log4j<groupId> >>>> <artifactId>log4j</artifactId> >>>> <version>[1.2.5,1.3)</version> >>>> <scope>implemented</scope> >>>> </dependency> >>>> >>>> that way we can filter out any artifacts which are implemented from the >>>> tree... >>>> >>>> e.g. >>>> >>>> if I depend on org.jboss.thirdparty:log4j >>>> >>>> Maven 2.3.0+, 3.0.0+ can see that this implements log4j:log4j, so that >>>> it does not need to be pulled in via transative dependencies >>>> >>>> 2009/7/8 Daniel Kulp <dk...@apache.org>: >>>>> 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 >>>>> >>>>> >>>>>> >>>>>> >>>>>> Benjamin >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> -- >>>>> Daniel Kulp >>>>> dk...@apache.org >>>>> http://www.dankulp.com/blog >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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
