maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Recommendations to resolve artifact/version fubar
Date Sun, 03 Jun 2012 13:41:48 GMT
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 <jdom@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
>> <stephen.alan.connolly@gmail.com>  wrote:
>>>
>>> On 29 May 2012 15:26, Rolf Lear<jdom@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


Mime
View raw message