see MNG-2316 about handling this issue, it has been there for a long time but talking about the repository it is impossible for jboss to publish their builds under the log4j group
On Wed, Jul 8, 2009 at 1:43 PM, Stephen Connolly<stephen.alan.conno...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
