Re: Recommendations to resolve artifact/version fubar
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 j...@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 groupIdorg.jdom/groupId artifactIdjdom/artifactId version2.0.1/version scopecompile/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 groupIdnet.sourceforge.htmlcleaner/groupId artifactIdhtmlcleaner/artifactId version2.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 groupIdorg.jdom/groupId artifactIdjdom.dep/artifactId version1.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 stephen.alan.conno...@gmail.com wrote: On 29 May 2012 15:26, Rolf Learj...@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:
Re: Recommendations to resolve artifact/version fubar
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
groupIdorg.jdom/groupId
artifactIdjdom/artifactId
version2.0.1/version
scopecompile/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
groupIdorg.jdom/groupId
artifactIdjdom/artifactId
version2.0.1/version
scopecompile/scope
/dependency
dependency
groupIdorg.jdom/groupId
artifactIdjdom-legacy/artifactId
version1.1.3/version
scopecompile/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 Learj...@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
groupIdorg.jdom/groupId
artifactIdjdom/artifactId
version2.0.1/version
scopecompile/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
groupIdnet.sourceforge.htmlcleaner/groupId
artifactIdhtmlcleaner/artifactId
version2.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
groupIdorg.jdom/groupId
artifactIdjdom.dep/artifactId
version1.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
stephen.alan.conno...@gmail.comwrote:
On 29 May 2012 15:26, Rolf Learj...@tuis.netwrote:
So, being
Re: Recommendations to resolve artifact/version fubar
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 groupIdorg.jdom/groupId artifactIdjdom/artifactId version2.0.1/version scopecompile/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 groupIdnet.sourceforge.htmlcleaner/groupId artifactIdhtmlcleaner/artifactId version2.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 groupIdorg.jdom/groupId artifactIdjdom.dep/artifactId version1.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 stephen.alan.conno...@gmail.com wrote: On 29 May 2012 15:26, Rolf Learj...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
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 groupIdorg.jdom/groupId artifactIdjdom/artifactId version2.0.1/version scopecompile/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 groupIdnet.sourceforge.htmlcleaner/groupId artifactIdhtmlcleaner/artifactId version2.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 groupIdorg.jdom/groupId artifactIdjdom.dep/artifactId version1.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 stephen.alan.conno...@gmail.com wrote: On 29 May 2012 15:26, Rolf Learj...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com
Re: Recommendations to resolve artifact/version fubar
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 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 Learj...@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|-1946144149http://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.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
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 Learj...@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|-1946144149http://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.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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
Re: Recommendations to resolve artifact/version fubar
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 Learj...@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
Re: Recommendations to resolve artifact/version fubar
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 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
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 stephen.alan.conno...@gmail.com wrote: On 29 May 2012 14:53, Curtis Ruedenctrue...@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 Learj...@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:
Re: Recommendations to resolve artifact/version fubar
On 29 May 2012 15:26, Rolf Lear j...@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; modelVersion4.0.0/modelVersion groupIdorg.jdom/groupId artifactIdjdom-deprecated/artifactId version1.1.3-SNAPSHOT/version nameJDOM Deprecated API and implementation/name properties project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding project.build.outputEncodingUTF-8/project.build.outputEncoding project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.jdom/groupId artifactIdjdom/artifactId version1.1.3/version /dependency /dependencies build plugins plugin artifactIdmaven-shade-plugin/artifactId version1.6/version executions execution goals goalshade/goal /goals configuration createDependencyReducedPomtrue/createDependencyReducedPom createSourcesJartrue/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 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
Re: Recommendations to resolve artifact/version fubar
So what this does is On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 29 May 2012 15:26, Rolf Lear j...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
On 29 May 2012 16:38, Rolf Lear j...@tuis.net wrote: So what this does is On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 29 May 2012 15:26, Rolf Lear j...@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-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
Re: Recommendations to resolve artifact/version fubar
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 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-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
Re: Recommendations to resolve artifact/version fubar
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 Learj...@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-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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Recommendations to resolve artifact/version fubar
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 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 Learj...@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-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 - To unsubscribe, e-mail: 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
