Re: Recommendations to resolve artifact/version fubar

2012-06-03 Thread Rolf Lear
OK, that's a good point. So, if I use jdom-legacy ('legacy' is a better description for my situation than 'deprecated') then anyone needing just one or the other version of JDOM can use plain 'jdom', but people needing both can use 'jdom' for version 2.x and and jdom-legacy for version 1

Re: Recommendations to resolve artifact/version fubar

2012-06-03 Thread Stephen Connolly
the convention for an artifact containing deprectated classes is to give it the artifactId "foo-deprecated" or "foo-legacy" Please strongly consider following that convention rather than going with "foo.dep" On 2 June 2012 01:29, Rolf Lear wrote: > Hi again everyone. > > I have taken some time a

Re: Recommendations to resolve artifact/version fubar

2012-06-01 Thread Ron Wheeler
On 01/06/2012 8:29 PM, Rolf Lear wrote: Hi again everyone. I have taken some time and installed a nexus locally, and I have been playing with different alternatives for how to solve my problem To recap, I have JDOM versions 1.x and 2.x both currently deployed in the artifact 'jdom' even

Re: Recommendations to resolve artifact/version fubar

2012-06-01 Thread Rolf Lear
Hi again everyone. I have taken some time and installed a nexus locally, and I have been playing with different alternatives for how to solve my problem To recap, I have JDOM versions 1.x and 2.x both currently deployed in the artifact 'jdom' even though these versions internally have dif

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Stephen Connolly
On 29 May 2012 16:38, Rolf Lear wrote: > > So what this does is > > > On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly > wrote: >> On 29 May 2012 15:26, Rolf Lear wrote: >>> >>> >>> So, being inexperienced, my intention is to find some solution that: >>> >>> 1. makes it possible (even if pla

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Rolf Lear
So what this does is On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly wrote: > On 29 May 2012 15:26, Rolf Lear wrote: >> >> >> So, being inexperienced, my intention is to find some solution that: >> >> 1. makes it possible (even if playing exclusion games is needed) to use >> both JDOM 1.

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Stephen Connolly
On 29 May 2012 15:26, Rolf Lear wrote: > > > So, being inexperienced, my intention is to find some solution that: > > 1. makes it possible (even if playing exclusion games is needed) to use > both JDOM 1.x and 2.x in a maven project (currently it is not). Well actually it is possible to work arou

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Ron Wheeler
Hibernate might be a good model. If jdom2 is upward compatible with jdom1 then you have no need to run 2 versions. It means not changing the behaviour of existing methods except in ways that all current users will like (remove a bug). You add new methods to add functionality and you make sure t

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Rolf Lear
So, being inexperienced, my intention is to find some solution that: 1. makes it possible (even if playing exclusion games is needed) to use both JDOM 1.x and 2.x in a maven project (currently it is not). 2. 'salvages' the current mess as simply as possible for the 'typical' maven user. 3. is so

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Curtis Rueden
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 hav

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Stephen Connolly
On 29 May 2012 14:53, Curtis Rueden 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

Re: Recommendations to resolve artifact/version fubar

2012-05-29 Thread Curtis Rueden
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 al

Re: Recommendations to resolve artifact/version fubar

2012-05-28 Thread Stephen Connolly
you could push a relocation pom to the old GAV for the next couple of 2.0.x releases and then at 2.1 stop with the relocation poms... that would give people with the 2.0.x deps a route but you are kind of ool for now On 28 May 2012 23:15, Rolf Lear wrote: > Unfortunately, there are already s

Re: Recommendations to resolve artifact/version fubar

2012-05-28 Thread Rolf Lear
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 Margu

Re: Recommendations to resolve artifact/version fubar

2012-05-28 Thread Benson Margulies
Publish another copy with a '2' in the artifactId? On Mon, May 28, 2012 at 6:09 PM, Rolf Lear 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

Recommendations to resolve artifact/version fubar

2012-05-28 Thread Rolf Lear
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 JDOM 2.x was released with a separate (new) package name for the expr