Note that even changing the pom (say the dependency section, but really anythng in the pom) is enough to trigger the need for a version change even if the jars remain untouched.
Stan ----- Original Message ----- From: Jason van Zyl <jvan...@sonatype.com> To: Maven Developers List <dev@maven.apache.org> Sent: Wed Jul 08 20:58:43 2009 Subject: Re: Depending on Artifacts not in central On 8-Jul-09, at 6:57 PM, Stan Devitt wrote: > The only thing that halfway works for rebuilt / modified artifacts > is to modify the version number (e.g. 3.5-mod-by-NameOModifier). > I agree. As once the patches reach the OSS project it is much easier to make the change to use the updated library. Paul, but do you rebuild the whole transitive chain? If you actually rebuild everything -- which I though was your policy -- then you are really the maintainer of the transitive chain for your users. Even if you take a tag and rebuild it yourself you've tampered with a released version someone has signed and then becomes your responsibility. If you break it, you buy it. You rebuild it, you own it. > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/SonatypeNexus http://twitter.com/SonatypeM2E ---------------------------------------------------------- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance --------------------------------------------------------------------- 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
