The only thing that halfway works for rebuilt / modified artifacts is to modify the version number (e.g. 3.5-mod-by-NameOModifier).
Stan ----- Original Message ----- From: Brian Fox <bri...@infinity.nu> To: Maven Developers List <dev@maven.apache.org> Sent: Wed Jul 08 17:36:55 2009 Subject: Re: Depending on Artifacts not in central BTW, we already wrote a proposal on this that got relatively little feedback: http://docs.codehaus.org/display/MAVEN/Artifact+resolution+and+repository+discovery On Wed, Jul 8, 2009 at 5:29 PM, Paul Gier<pg...@redhat.com> wrote: > Daniel Kulp wrote: >> >> 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 >> > > Yes, this is the major problem that we would have with changing the groupId > for rebuilt artifacts. It works fine for small projects, but for a large > dependency tree it is currently a big hassle to try to track down and > exclude every place where the original groupId/artifactId is included > transitively. > > Allowing some kind of global exclusions would be a good start (MNG-1977, > MNG-3196). We currently use the enforcer plugin, but I still have to add in > exclusions every time the same dependency is reintroduced in a new location > in the tree. Also, anyone depending on the JBoss project might then have to > add exclusions to their projects to get only the correct dependencies. > > But ideally there would be some way to link groupId:artifactId combinations > as suggested by Stephen and Carlos. This would also help resolve artifacts > that are renamed between versions which happens occasionally. Is there any > work to handle this use case in Mercury? > >> >>> >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
