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]
