For the repository constraint I agree.But what can we recommend to jboss and others company which have this need to be a good maven citizen ? I'll have the same issue soon with my company exoplatform. We are interested to deploy nexus and push some of our artifacts in central but what to do with : - artifacts deployed on repositories not synched with central (java.net & co) - modified oss libraires
Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Wed, Jul 8, 2009 at 10:46 PM, Carlos Sanchez <[email protected]> wrote: > 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<[email protected]> 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 <[email protected]>: > >> other possible names for the scope could be "encapsulated", or "bundled" > >> > >> 2009/7/8 Stephen Connolly <[email protected]>: > >>> 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 <[email protected]>: > >>>> 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: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> [email protected] > >>>> http://www.dankulp.com/blog > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >
