You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Rolf Lear <jd...@tuis.net> on 2012/05/29 00:09:44 UTC
Recommendations to resolve artifact/version fubar
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 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
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 though these versions internally have
> different packages (org.jdom.* and org.jdom2.* ). The problem is that
> it is necessary in some conditions to have both version 1.x and 2.x in
> a maven project (typically because the 1.x version is used by some
> third-party dependency).
Why will the 2.x version not work with code that was written to the 1.x
spec?
>
> I have been trying to find the 'best' way to 'recover' the mess in the
> JDOM artifact so that it is possible to have both 1.x as well as 2.x,
> but to do it in such a way that it has the least impact on current
> users, and for those users who *need* both versions, it can be done as
> simply as possible.
>
> In my experimentation I think I have found that the *easiest* and also
> the *neatest* solution is to duplicate the latest JDOM 1.x artifact
> with a different artifact-id. In my local nexus I have duplicated the
> JDOM 1.1.3 artifact as jdom.dep 1.1.3.
>
> The way I see this working is that for the 'simple' user, they do not
> have the complicated requirement to have both 1.x and 2.x. In their
> case they can just continue doing what they do.... and when they are
> ready they can upgrade their code to use JDOM 2.x, changing their
> dependency from jdom 1.x to jdom 2.x when they do.
>
> For the complicated user, they will be needing both versions. Right
> now they can't run their code because they can't have both 1.x and 2.x
> in their compile. In the typical case there is a third-party
> dependency which in turn depends on jdom 1.x. Since 'our' project
> depends on jdom 2.x and the 3rd party depends on 1.x, maven will
> automatically just pull the 'newer' jdom 2.x version. This means that
> the 3rd-party code will be failing because it is missing classes.
>
Why not add the classes back into 2.x that were removed?
> In this case, we can simply add the 'jdom.dep' artifact to our
> project, specifying the 1.x version.
>
> I have 'worked through' the various scenarios, and I think it can be
> expressed as follows:
>
> Say I have my project. It has the simple dependency:
>
> <dependency>
> <groupId>org.jdom</groupId>
> <artifactId>jdom</artifactId>
> <version>2.0.1</version>
> <scope>compile</scope>
> </dependency>
>
> Now I want to include the additional dependency (this is just some
> 'arbitrary' dependency which has an internal dependency to jdom 1.1):
>
> <dependency>
> <groupId>net.sourceforge.htmlcleaner</groupId>
> <artifactId>htmlcleaner</artifactId>
> <version>2.2</version>
> </dependency>
>
> Unfortunately this htmlcleaner code will not work because I am missing
> the org.jdom.* classes because maven has only used the jdom 2.0.1
> version which only has the org.jdom2.* classes.
>
> The solution is, in my project, to also include the 'duplicate' 1.x
> dependency:
>
> <dependency>
> <groupId>org.jdom</groupId>
> <artifactId>jdom.dep</artifactId>
> <version>1.1.3</version>
> </dependency>
>
>
> The bottom line is that only those people who require both versions
> will be affected, and the solution only requires adding a new
> dependency to the project, and there is no need to do 'exclusions' or
> other 'shady' logic....
>
> Further, there is no need for the 'normal' JDOM user (they only
> require the one version of JDOM) to worry about anything because
> things just stay the same.... there is nothing to change.
>
> I would greatly appreciate it if this 'plan' could be inspected and
> criticized/poked/verified/etc.
>
> Thanks in advance
>
> Rolf
>
>
>
> On 29/05/2012 11:38 AM, Rolf Lear wrote:
>>
>> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
>> <st...@gmail.com> wrote:
>>> On 29 May 2012 15:26, Rolf Lear<jd...@tuis.net> 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 around the issue if you are
>>> prepared to introduce a wrapper project...
>>>
>>> something like this:
>>
>>
>> Hmmm... this has gone over my head.... I think I am going to have to
>> spend
>> some time getting to grips with some of the more details in maven...
>>
>> Perhaps I should take a few days and set up my own repo, and try these
>> things out...
>>
>> For what it's worth, I am not sure the maven-shade-plugin is
>> appropriate.... is it? I am not sure how that usage of it helps... I
>> simply
>> don't know enough.
>>
>> Bottom line is that I don't know enough yet... must learn more.
>>
>> Thanks all, I'll figure some more things out and come back with 'more
>> of a
>> clue'.
>>
>> Rolf
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler President Artifact Software Inc email:
rwheeler@artifact-software.com skype: ronaldmwheeler phone:
866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Rolf Lear <jd...@tuis.net>.
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.x
I cannot see anyone needing anything more complicated than this.... am I
right?
In summary, people needing just one JDOM version:
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>2.0.1</version>
<scope>compile</scope>
</dependency>
people needing 1.x and 2.x versions (perhaps because they have a 3rd-party with a dependency on an old version)
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>2.0.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom-legacy</artifactId>
<version>1.1.3</version>
<scope>compile</scope>
</dependency>
Thanks
Rolf
On 03/06/2012 9:41 AM, Stephen Connolly wrote:
> 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<jd...@tuis.net> 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 though these versions internally have different
>> packages (org.jdom.* and org.jdom2.* ). The problem is that it is necessary
>> in some conditions to have both version 1.x and 2.x in a maven project
>> (typically because the 1.x version is used by some third-party dependency).
>>
>> I have been trying to find the 'best' way to 'recover' the mess in the JDOM
>> artifact so that it is possible to have both 1.x as well as 2.x, but to do
>> it in such a way that it has the least impact on current users, and for
>> those users who *need* both versions, it can be done as simply as possible.
>>
>> In my experimentation I think I have found that the *easiest* and also the
>> *neatest* solution is to duplicate the latest JDOM 1.x artifact with a
>> different artifact-id. In my local nexus I have duplicated the JDOM 1.1.3
>> artifact as jdom.dep 1.1.3.
>>
>> The way I see this working is that for the 'simple' user, they do not have
>> the complicated requirement to have both 1.x and 2.x. In their case they can
>> just continue doing what they do.... and when they are ready they can
>> upgrade their code to use JDOM 2.x, changing their dependency from jdom 1.x
>> to jdom 2.x when they do.
>>
>> For the complicated user, they will be needing both versions. Right now they
>> can't run their code because they can't have both 1.x and 2.x in their
>> compile. In the typical case there is a third-party dependency which in turn
>> depends on jdom 1.x. Since 'our' project depends on jdom 2.x and the 3rd
>> party depends on 1.x, maven will automatically just pull the 'newer' jdom
>> 2.x version. This means that the 3rd-party code will be failing because it
>> is missing classes.
>>
>> In this case, we can simply add the 'jdom.dep' artifact to our project,
>> specifying the 1.x version.
>>
>> I have 'worked through' the various scenarios, and I think it can be
>> expressed as follows:
>>
>> Say I have my project. It has the simple dependency:
>>
>>
>> <dependency>
>> <groupId>org.jdom</groupId>
>> <artifactId>jdom</artifactId>
>> <version>2.0.1</version>
>> <scope>compile</scope>
>> </dependency>
>>
>> Now I want to include the additional dependency (this is just some
>> 'arbitrary' dependency which has an internal dependency to jdom 1.1):
>>
>> <dependency>
>> <groupId>net.sourceforge.htmlcleaner</groupId>
>> <artifactId>htmlcleaner</artifactId>
>> <version>2.2</version>
>> </dependency>
>>
>> Unfortunately this htmlcleaner code will not work because I am missing the
>> org.jdom.* classes because maven has only used the jdom 2.0.1 version which
>> only has the org.jdom2.* classes.
>>
>> The solution is, in my project, to also include the 'duplicate' 1.x
>> dependency:
>>
>> <dependency>
>> <groupId>org.jdom</groupId>
>> <artifactId>jdom.dep</artifactId>
>> <version>1.1.3</version>
>> </dependency>
>>
>>
>> The bottom line is that only those people who require both versions will be
>> affected, and the solution only requires adding a new dependency to the
>> project, and there is no need to do 'exclusions' or other 'shady' logic....
>>
>> Further, there is no need for the 'normal' JDOM user (they only require the
>> one version of JDOM) to worry about anything because things just stay the
>> same.... there is nothing to change.
>>
>> I would greatly appreciate it if this 'plan' could be inspected and
>> criticized/poked/verified/etc.
>>
>> Thanks in advance
>>
>> Rolf
>>
>>
>>
>>
>> On 29/05/2012 11:38 AM, Rolf Lear wrote:
>>>
>>> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
>>> <st...@gmail.com> wrote:
>>>> On 29 May 2012 15:26, Rolf Lear<jd...@tuis.net> 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 around the issue if you are
>>>> prepared to introduce a wrapper project...
>>>>
>>>> something like this:
>>>
>>>
>>> Hmmm... this has gone over my head.... I think I am going to have to spend
>>> some time getting to grips with some of the more details in maven...
>>>
>>> Perhaps I should take a few days and set up my own repo, and try these
>>> things out...
>>>
>>> For what it's worth, I am not sure the maven-shade-plugin is
>>> appropriate.... is it? I am not sure how that usage of it helps... I
>>> simply
>>> don't know enough.
>>>
>>> Bottom line is that I don't know enough yet... must learn more.
>>>
>>> Thanks all, I'll figure some more things out and come back with 'more of a
>>> clue'.
>>>
>>> Rolf
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Stephen Connolly <st...@gmail.com>.
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 <jd...@tuis.net> 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 though these versions internally have different
> packages (org.jdom.* and org.jdom2.* ). The problem is that it is necessary
> in some conditions to have both version 1.x and 2.x in a maven project
> (typically because the 1.x version is used by some third-party dependency).
>
> I have been trying to find the 'best' way to 'recover' the mess in the JDOM
> artifact so that it is possible to have both 1.x as well as 2.x, but to do
> it in such a way that it has the least impact on current users, and for
> those users who *need* both versions, it can be done as simply as possible.
>
> In my experimentation I think I have found that the *easiest* and also the
> *neatest* solution is to duplicate the latest JDOM 1.x artifact with a
> different artifact-id. In my local nexus I have duplicated the JDOM 1.1.3
> artifact as jdom.dep 1.1.3.
>
> The way I see this working is that for the 'simple' user, they do not have
> the complicated requirement to have both 1.x and 2.x. In their case they can
> just continue doing what they do.... and when they are ready they can
> upgrade their code to use JDOM 2.x, changing their dependency from jdom 1.x
> to jdom 2.x when they do.
>
> For the complicated user, they will be needing both versions. Right now they
> can't run their code because they can't have both 1.x and 2.x in their
> compile. In the typical case there is a third-party dependency which in turn
> depends on jdom 1.x. Since 'our' project depends on jdom 2.x and the 3rd
> party depends on 1.x, maven will automatically just pull the 'newer' jdom
> 2.x version. This means that the 3rd-party code will be failing because it
> is missing classes.
>
> In this case, we can simply add the 'jdom.dep' artifact to our project,
> specifying the 1.x version.
>
> I have 'worked through' the various scenarios, and I think it can be
> expressed as follows:
>
> Say I have my project. It has the simple dependency:
>
>
> <dependency>
> <groupId>org.jdom</groupId>
> <artifactId>jdom</artifactId>
> <version>2.0.1</version>
> <scope>compile</scope>
> </dependency>
>
> Now I want to include the additional dependency (this is just some
> 'arbitrary' dependency which has an internal dependency to jdom 1.1):
>
> <dependency>
> <groupId>net.sourceforge.htmlcleaner</groupId>
> <artifactId>htmlcleaner</artifactId>
> <version>2.2</version>
> </dependency>
>
> Unfortunately this htmlcleaner code will not work because I am missing the
> org.jdom.* classes because maven has only used the jdom 2.0.1 version which
> only has the org.jdom2.* classes.
>
> The solution is, in my project, to also include the 'duplicate' 1.x
> dependency:
>
> <dependency>
> <groupId>org.jdom</groupId>
> <artifactId>jdom.dep</artifactId>
> <version>1.1.3</version>
> </dependency>
>
>
> The bottom line is that only those people who require both versions will be
> affected, and the solution only requires adding a new dependency to the
> project, and there is no need to do 'exclusions' or other 'shady' logic....
>
> Further, there is no need for the 'normal' JDOM user (they only require the
> one version of JDOM) to worry about anything because things just stay the
> same.... there is nothing to change.
>
> I would greatly appreciate it if this 'plan' could be inspected and
> criticized/poked/verified/etc.
>
> Thanks in advance
>
> Rolf
>
>
>
>
> On 29/05/2012 11:38 AM, Rolf Lear wrote:
>>
>>
>> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
>> <st...@gmail.com> wrote:
>>>
>>> On 29 May 2012 15:26, Rolf Lear<jd...@tuis.net> 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 around the issue if you are
>>> prepared to introduce a wrapper project...
>>>
>>> something like this:
>>
>>
>>
>> Hmmm... this has gone over my head.... I think I am going to have to spend
>> some time getting to grips with some of the more details in maven...
>>
>> Perhaps I should take a few days and set up my own repo, and try these
>> things out...
>>
>> For what it's worth, I am not sure the maven-shade-plugin is
>> appropriate.... is it? I am not sure how that usage of it helps... I
>> simply
>> don't know enough.
>>
>> Bottom line is that I don't know enough yet... must learn more.
>>
>> Thanks all, I'll figure some more things out and come back with 'more of a
>> clue'.
>>
>> Rolf
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Rolf Lear <jd...@tuis.net>.
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 different
packages (org.jdom.* and org.jdom2.* ). The problem is that it is
necessary in some conditions to have both version 1.x and 2.x in a maven
project (typically because the 1.x version is used by some third-party
dependency).
I have been trying to find the 'best' way to 'recover' the mess in the
JDOM artifact so that it is possible to have both 1.x as well as 2.x,
but to do it in such a way that it has the least impact on current
users, and for those users who *need* both versions, it can be done as
simply as possible.
In my experimentation I think I have found that the *easiest* and also
the *neatest* solution is to duplicate the latest JDOM 1.x artifact with
a different artifact-id. In my local nexus I have duplicated the JDOM
1.1.3 artifact as jdom.dep 1.1.3.
The way I see this working is that for the 'simple' user, they do not
have the complicated requirement to have both 1.x and 2.x. In their case
they can just continue doing what they do.... and when they are ready
they can upgrade their code to use JDOM 2.x, changing their dependency
from jdom 1.x to jdom 2.x when they do.
For the complicated user, they will be needing both versions. Right now
they can't run their code because they can't have both 1.x and 2.x in
their compile. In the typical case there is a third-party dependency
which in turn depends on jdom 1.x. Since 'our' project depends on jdom
2.x and the 3rd party depends on 1.x, maven will automatically just pull
the 'newer' jdom 2.x version. This means that the 3rd-party code will be
failing because it is missing classes.
In this case, we can simply add the 'jdom.dep' artifact to our project,
specifying the 1.x version.
I have 'worked through' the various scenarios, and I think it can be
expressed as follows:
Say I have my project. It has the simple dependency:
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>2.0.1</version>
<scope>compile</scope>
</dependency>
Now I want to include the additional dependency (this is just some
'arbitrary' dependency which has an internal dependency to jdom 1.1):
<dependency>
<groupId>net.sourceforge.htmlcleaner</groupId>
<artifactId>htmlcleaner</artifactId>
<version>2.2</version>
</dependency>
Unfortunately this htmlcleaner code will not work because I am missing
the org.jdom.* classes because maven has only used the jdom 2.0.1
version which only has the org.jdom2.* classes.
The solution is, in my project, to also include the 'duplicate' 1.x
dependency:
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom.dep</artifactId>
<version>1.1.3</version>
</dependency>
The bottom line is that only those people who require both versions will
be affected, and the solution only requires adding a new dependency to
the project, and there is no need to do 'exclusions' or other 'shady'
logic....
Further, there is no need for the 'normal' JDOM user (they only require
the one version of JDOM) to worry about anything because things just
stay the same.... there is nothing to change.
I would greatly appreciate it if this 'plan' could be inspected and
criticized/poked/verified/etc.
Thanks in advance
Rolf
On 29/05/2012 11:38 AM, Rolf Lear wrote:
>
> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 29 May 2012 15:26, Rolf Lear<jd...@tuis.net> 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 around the issue if you are
>> prepared to introduce a wrapper project...
>>
>> something like this:
>
>
> Hmmm... this has gone over my head.... I think I am going to have to spend
> some time getting to grips with some of the more details in maven...
>
> Perhaps I should take a few days and set up my own repo, and try these
> things out...
>
> For what it's worth, I am not sure the maven-shade-plugin is
> appropriate.... is it? I am not sure how that usage of it helps... I simply
> don't know enough.
>
> Bottom line is that I don't know enough yet... must learn more.
>
> Thanks all, I'll figure some more things out and come back with 'more of a
> clue'.
>
> Rolf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2012 16:38, Rolf Lear <jd...@tuis.net> wrote:
>
> So what this does is
>
>
> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 29 May 2012 15:26, Rolf Lear <jd...@tuis.net> 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 around the issue if you are
>> prepared to introduce a wrapper project...
>>
>> something like this:
>
>
> Hmmm... this has gone over my head.... I think I am going to have to spend
> some time getting to grips with some of the more details in maven...
>
> Perhaps I should take a few days and set up my own repo, and try these
> things out...
>
> For what it's worth, I am not sure the maven-shade-plugin is
> appropriate.... is it? I am not sure how that usage of it helps... I simply
> don't know enough.
All that shade is doing in this case is repacking the original
dependency under a different name.... we could have used it to remap
the old classes and their references, for example if you had not
renamed the java package name from org.jdom to org.jdom2 we could have
used shade to process the dependencies which use the old version to
rename their org.jdom to org.jdom.deprecated and allow the two
classpaths to co-exist without overlap.
But I am not doing anything that fancy here... all I am showing here
is how a small pom can allow me to work around the issue. if you are
happy to redeploy jdom1 as jdom-deprecated just by changing your
original pom, then that would be simpler, but the pom I have is quite
short! I could have replaced it in a number of ways, for example I
could just use dependency:copy and buildhelper:attach and tell the jar
plugin to skip.. but that would be a more verbose pom... might still
end up with such to get the javadoc artifacts into central if you were
using the above pom... but my example was just a "here is how a user
could solve this" not a "here is how the library producer will give a
solution to users"... the latter is release either a
org.jdom:jdom-deprecated:1.1.4 or org.jdom.deprecated:jdom:1.1.4 (the
war plugin should handle renaming when the artifactIds are the same,
so no worries about that)
>
> Bottom line is that I don't know enough yet... must learn more.
>
> Thanks all, I'll figure some more things out and come back with 'more of a
> clue'.
>
> Rolf
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Rolf Lear <jd...@tuis.net>.
So what this does is
On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> On 29 May 2012 15:26, Rolf Lear <jd...@tuis.net> 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 around the issue if you are
> prepared to introduce a wrapper project...
>
> something like this:
Hmmm... this has gone over my head.... I think I am going to have to spend
some time getting to grips with some of the more details in maven...
Perhaps I should take a few days and set up my own repo, and try these
things out...
For what it's worth, I am not sure the maven-shade-plugin is
appropriate.... is it? I am not sure how that usage of it helps... I simply
don't know enough.
Bottom line is that I don't know enough yet... must learn more.
Thanks all, I'll figure some more things out and come back with 'more of a
clue'.
Rolf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2012 15:26, Rolf Lear <jd...@tuis.net> 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 around the issue if you are
prepared to introduce a wrapper project...
something like this:
<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.jdom</groupId>
<artifactId>jdom-deprecated</artifactId>
<version>1.1.3-SNAPSHOT</version>
<name>JDOM Deprecated API and implementation</name>
<properties>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<project.build.outputEncoding>UTF-8</project.build.outputEncoding>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.1.3</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-shade-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<createDependencyReducedPom>true</createDependencyReducedPom>
<createSourcesJar>true</createSourcesJar>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Will give the user the ability to play the exclusions game
> 2. 'salvages' the current mess as simply as possible for the 'typical'
> maven user.
> 3. is something I can describe on the jdom website and expect people to
> understand how to get it right... ( I don't want to have to do 'maven
> support' ;-)
>
> The way I understand things is that once I deploy to a second artifact
> (either deploy JDOM 2.x to 'jdom2' artifact, or alternately deploy JDOM 1.x
> to 'jdom1' artifact),
rather than call it jdom1 I would call the artifactId something like
jdom-deprecated or jdom-legacy... or even better change the groupId to
org.jdom.deprecated
> then users can 'exclude' any conflicting dependencies
> from their 'required' third-party projects, and substitute them with the
> ones from the 'alternate' artifact.
>
> In my head it seems that creating a jdom1 artifact would be very stable (I
> do not expect any more 1.x JDOM releases....), and then people can 'stick'
> with the 'jdom' artifact, and if they run in to problems they can play the
> 'exclusion' game with the jdom 1.x dependencies, and replace them with the
> jdom1 dependency.
Actually the easier solution is not to play the exclusions game at all
if you move jdom 1.x to jdom-deprecated... a plugin management forcing
2.x at the root will solve the issue of the 2.x versions, and then
just adding the jdom-deprecated (providing they share no classes)
dependency will fix up the classpath.
>
> This 'keeps it simple' for the typical user, but still makes it possible
> for the 'conflicted' user to get their jars.... ? right?
>
> But, would that be 'sensible'? Would a maven user 'follow' that logic?
I think an artifact called jdom-deprecated would be clear to somebody
>
> I am not really in any position to have firm opinions on this. The only
> preferences I have would be:
> 1. I want the official JDOM release (on www.jdom.org) to be identical to
> the releases on maven - I don't want to have different jar names, etc. The
> www.jdom.org release is the 'official' release, and maven is a 'mirror'.
> 2. I would prefer to continue calling it jdom-2.0.2.jar instead of
> jdom2-2.0.2.jar - to keep consistency with what we have already done....
> but this is a lower priority.
>
> Thanks for the insights so far ....
>
> Rolf
>
> On Tue, 29 May 2012 15:00:54 +0100, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 29 May 2012 14:53, Curtis Rueden <ct...@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 <jd...@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
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 that the
version 2 supports all the version 1 calls in exactly the same way as
version 1 did.
Then you tell people that want to use the old methods and the new
methods to simply change the version on the dependency in their POM and
start to use the new library.
That is what most people do.
Not doing this, will have an impact on the reputation of the product for
those interested in total cost of ownership and robustness of their
applications.
If you want to change the functions of existing methods or delete
methods (without warning for several years in advanced - "deprecated")
in ways that will break current, properly written, applications, then
you can do what Hibernate did.
Change the library name to hibernate3 and make the names of all of the
methods have a 3 in their name.
This way the developer would have a real problem if they tried to mix
the old with the new since that is what you need in the case of database
access rather than your situation where it appears that mixing jdom
functions between versions will not result in data corruption.
Ron
On 29/05/2012 10:26 AM, 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).
> 2. 'salvages' the current mess as simply as possible for the 'typical'
> maven user.
> 3. is something I can describe on the jdom website and expect people to
> understand how to get it right... ( I don't want to have to do 'maven
> support' ;-)
>
> The way I understand things is that once I deploy to a second artifact
> (either deploy JDOM 2.x to 'jdom2' artifact, or alternately deploy JDOM 1.x
> to 'jdom1' artifact), then users can 'exclude' any conflicting dependencies
> from their 'required' third-party projects, and substitute them with the
> ones from the 'alternate' artifact.
>
> In my head it seems that creating a jdom1 artifact would be very stable (I
> do not expect any more 1.x JDOM releases....), and then people can 'stick'
> with the 'jdom' artifact, and if they run in to problems they can play the
> 'exclusion' game with the jdom 1.x dependencies, and replace them with the
> jdom1 dependency.
>
> This 'keeps it simple' for the typical user, but still makes it possible
> for the 'conflicted' user to get their jars.... ? right?
>
> But, would that be 'sensible'? Would a maven user 'follow' that logic?
>
> I am not really in any position to have firm opinions on this. The only
> preferences I have would be:
> 1. I want the official JDOM release (on www.jdom.org) to be identical to
> the releases on maven - I don't want to have different jar names, etc. The
> www.jdom.org release is the 'official' release, and maven is a 'mirror'.
> 2. I would prefer to continue calling it jdom-2.0.2.jar instead of
> jdom2-2.0.2.jar - to keep consistency with what we have already done....
> but this is a lower priority.
>
> Thanks for the insights so far ....
>
> Rolf
>
> On Tue, 29 May 2012 15:00:54 +0100, Stephen Connolly
> <st...@gmail.com> wrote:
>> On 29 May 2012 14:53, Curtis Rueden<ct...@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<jd...@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
>>>>
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler President Artifact Software Inc email:
rwheeler@artifact-software.com skype: ronaldmwheeler phone:
866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Rolf Lear <jd...@tuis.net>.
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 something I can describe on the jdom website and expect people to
understand how to get it right... ( I don't want to have to do 'maven
support' ;-)
The way I understand things is that once I deploy to a second artifact
(either deploy JDOM 2.x to 'jdom2' artifact, or alternately deploy JDOM 1.x
to 'jdom1' artifact), then users can 'exclude' any conflicting dependencies
from their 'required' third-party projects, and substitute them with the
ones from the 'alternate' artifact.
In my head it seems that creating a jdom1 artifact would be very stable (I
do not expect any more 1.x JDOM releases....), and then people can 'stick'
with the 'jdom' artifact, and if they run in to problems they can play the
'exclusion' game with the jdom 1.x dependencies, and replace them with the
jdom1 dependency.
This 'keeps it simple' for the typical user, but still makes it possible
for the 'conflicted' user to get their jars.... ? right?
But, would that be 'sensible'? Would a maven user 'follow' that logic?
I am not really in any position to have firm opinions on this. The only
preferences I have would be:
1. I want the official JDOM release (on www.jdom.org) to be identical to
the releases on maven - I don't want to have different jar names, etc. The
www.jdom.org release is the 'official' release, and maven is a 'mirror'.
2. I would prefer to continue calling it jdom-2.0.2.jar instead of
jdom2-2.0.2.jar - to keep consistency with what we have already done....
but this is a lower priority.
Thanks for the insights so far ....
Rolf
On Tue, 29 May 2012 15:00:54 +0100, Stephen Connolly
<st...@gmail.com> wrote:
> On 29 May 2012 14:53, Curtis Rueden <ct...@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 <jd...@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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Curtis Rueden <ct...@wisc.edu>.
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.connolly@gmail.com> wrote:
> On 29 May 2012 14:53, Curtis Rueden <ct...@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 <jd...@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<jd...@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-unsubscribe@maven.apache.org>
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>
> ------------------------------**------------------------------**---------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Recommendations to resolve artifact/version fubar
Posted by Stephen Connolly <st...@gmail.com>.
On 29 May 2012 14:53, Curtis Rueden <ct...@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 <jd...@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<jd...@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<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Curtis Rueden <ct...@wisc.edu>.
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. 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 <jd...@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<jd...@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<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Recommendations to resolve artifact/version fubar
Posted by Stephen Connolly <st...@gmail.com>.
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 <jd...@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<jd...@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
>>>
>>> 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
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Rolf Lear <jd...@tuis.net>.
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<jd...@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
>>
>> 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
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
Posted by Benson Margulies <bi...@gmail.com>.
Publish another copy with a '2' in the artifactId?
On Mon, May 28, 2012 at 6:09 PM, Rolf Lear <jd...@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
>
> 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
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org