maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rolf Lear <j...@tuis.net>
Subject Re: Recommendations to resolve artifact/version fubar
Date Sun, 03 Jun 2012 16:05:37 GMT
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<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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message