if they rebuild it then it must have something different and they would need to handle the differences in some way. I can't imagine they rebuild the jars just for the sake of doing it.
On Wed, Jul 8, 2009 at 1:18 PM, Arnaud HERITIER<aherit...@gmail.com> wrote: > But it creates many issues to resolve transitive dependencies. With that you > can have in a tree org.jboss.log4j:log4j:1.2.36 and log4j:log4j:1.2.12Is it > working fine if in the pom of org.jboss.log4j:log4j:1.2.36 we set a > relocation ? Can it have some others impacts ? > > Arnaud > > > > On Wed, Jul 8, 2009 at 10:13 PM, Benjamin Bentmann < > benjamin.bentm...@udo.edu> 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. >> >> >> Benjamin >> >> >> --------------------------------------------------------------------- >> 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
