Hi Stephen,
> the issue is transitive version resolution. If one of your > dependencies depends on org.jdom:jdom:1.x and the other depends on > org.jdom:jdom:2.x then you're going to end up with something broken as > maven will resolve only one version of org.jdom:jdom... so you will > end up having to play the exclusions game to stop that version being > pulled in and manually add a dependency to org.jdom:jdom2... > OK, I see how that gets ugly. Your suggestion of using relocation POMs for future org.jdom:jdom:2.0.x GAVs (and then discontinuing them at 2.1.x) sounds like the best way to go. But it's too bad that the existing versions of org.jdom:jdom:2.0.x will forever have this problem. Is there any facility with Maven Central to delete or amend erroneously published releases? I know it's a drastic measure, but in cases like these, it may actually be desirable for the build to fail for those who have begun depending on the versions in question (ideally with a message about how to deal with it). I realize there are myriad issues with altering a release, but you could imagine a smarter future Maven that is capable of detecting amended releases efficiently, and warning the user about it. You could even guarantee continued repeatable builds by only allowing very specific sorts of amendment, such as a deprecation element... > this is why one of the major feature adds I want to get into maven 4 > is a provides scope. > How would that work? Regards, Curtis On Tue, May 29, 2012 at 9:00 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On 29 May 2012 14:53, Curtis Rueden <ctrue...@wisc.edu> wrote: > > Hi Rolf, > > > > > >> Unfortunately, there are already some 'third party' packages that depend > >> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have two > >> different versions of the same jar .... right? ... which is perhaps > worse > >> than not having it at all ... ;-) > >> > > > > Since your goal is to allow JDOM 1.x and JDOM 2.x in the same JVM from a > > Maven project, publishing as org.jdom:jdom2:2.0.x seems like the way to > go. > > You can continue publishing org.jdom:jdom:2.0.x as well; the duplication > > does not really cause any problems other than potential confusion. > > Curtis, > > the issue is transitive version resolution. If one of your > dependencies depends on org.jdom:jdom:1.x and the other depends on > org.jdom:jdom:2.x then you're going to end up with something broken as > maven will resolve only one version of org.jdom:jdom... so you will > end up having to play the exclusions game to stop that version being > pulled in and manually add a dependency to org.jdom:jdom2... > > this is why one of the major feature adds I want to get into maven 4 > is a provides scope. > > > As long > > as you document why org.jdom:jdom2 exists, it seems fine to me. > > > > -Curtis > > > > > > On Mon, May 28, 2012 at 5:15 PM, Rolf Lear <j...@tuis.net> wrote: > > > >> Unfortunately, there are already some 'third party' packages that depend > >> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have two > >> different versions of the same jar .... right? ... which is perhaps > worse > >> than not having it at all ... ;-) > >> > >> Rolf > >> > >> > >> On 28/05/2012 6:12 PM, Benson Margulies wrote: > >> > >>> Publish another copy with a '2' in the artifactId? > >>> > >>> On Mon, May 28, 2012 at 6:09 PM, Rolf Lear<j...@tuis.net> wrote: > >>> > >>>> Hi all. > >>>> > >>>> I maintain the JDOM project, and unfortunately it seems I made a > 'novice' > >>>> error when deploying a new version of JDOM to maven-central. > >>>> > >>>> Thus, the situation is as follows: > >>>> http://search.maven.org/#**browse|-1946144149< > http://search.maven.org/#browse%7C-1946144149> > >>>> > >>>> JDOM 2.x was released with a separate (new) package name for the > express > >>>> purpose of allowing the user to run both JDOM 1.x and 2.x in the same > >>>> JVM. > >>>> This works fine for non-maven users, but maven users are not able to > have > >>>> dependencies on both JDOM 1.1.3 and JDOM 2.0.1 simultaneously. > >>>> > >>>> So, I have already been 'criticized' for the fact that this situation > >>>> could > >>>> have been avoided by using a different artifact id for the new JDOM > 2.x > >>>> releases... and I am not looking for more criticism... what I need is > >>>> some > >>>> insight as to what the correct procedure would be to do *now* to > produce > >>>> the > >>>> best outcome. > >>>> > >>>> How do I best resolve this situation? > >>>> > >>>> Bear in mind that people use JDOM from all sorts of places... and JDOM > >>>> 1.x > >>>> versions are dependencies of many other 'third-party' maven projects. > >>>> > >>>> Rolf > >>>> > >>>> ------------------------------**------------------------------** > >>>> --------- > >>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > >>>> For additional commands, e-mail: users-h...@maven.apache.org > >>>> > >>>> > >>> > ------------------------------**------------------------------**--------- > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > >> > >> > ------------------------------**------------------------------**--------- > >> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > users-unsubscr...@maven.apache.org> > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
