maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Lear <>
Subject Re: Recommendations to resolve artifact/version fubar
Date Sat, 02 Jun 2012 00:29:59 GMT
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 

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:


Now I want to include the additional dependency (this is just some 
'arbitrary' dependency which has an internal dependency to jdom 1.1):


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 


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' 

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 

Thanks in advance


On 29/05/2012 11:38 AM, Rolf Lear wrote:
> On Tue, 29 May 2012 16:22:27 +0100, Stephen Connolly
> <>  wrote:
>> On 29 May 2012 15:26, Rolf Lear<>  wrote:
>>> So, being inexperienced, my intention is to find some solution that:
>>> 1. makes it possible (even if playing exclusion games is needed) to use
>>> both JDOM 1.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:
For additional commands, e-mail:

View raw message