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<[email protected]> 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
<[email protected]> wrote:
On 29 May 2012 15:26, Rolf Lear<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
