Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of stephen.alan.connolly@gmail.com
 designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FC95E87.8070109@tuis.net>
References: <4FC3F7A8.1040307@tuis.net>
	<CALhtWkd=dLENp66LJ4hmLgJwcSZKZwskx1_wLVnJ2FtQ4A-gag@mail.gmail.com>
	<4FC3F8FD.8000007@tuis.net>
	<CADN69y=a2OZa5_0i6eFr3TAobEhecHxvx8dwhpBqzDF6K2x56g@mail.gmail.com>
	<CA+nPnMx_BLQv8-TWZ0NF5jUySmycZGf4_XBEfA+HayBVGrv+hQ@mail.gmail.com>
	<05530ad7837f7c41cad2ae6c4b084571@tuis.net>
	<CA+nPnMz7mgtvY-T4oC46ZWWg_5J_7j_B4D5QHZ616BJZP3cJPg@mail.gmail.com>
	<525a08fa9e7e05f0af683e9a2688c2a9@tuis.net>
	<4FC95E87.8070109@tuis.net>
Date: Sun, 3 Jun 2012 14:41:48 +0100
Message-ID: 
 <CA+nPnMw95Zw1FyAF_Rt4ypreoc7+OT3QMWzXfQtFgykB9Su2Pg@mail.gmail.com>
Subject: Re: Recommendations to resolve artifact/version fubar
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 necessa=
ry
> 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 JD=
OM
> artifact so that it is possible to have both 1.x as well as 2.x, but to d=
o
> 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 possibl=
e.
>
> In my experimentation I think I have found that the *easiest* and also th=
e
> *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 hav=
e
> 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 t=
hey
> 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 t=
urn
> 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 i=
t
> 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:
>
>
> =A0 =A0<dependency>
> =A0 =A0 =A0<groupId>org.jdom</groupId>
> =A0 =A0 =A0<artifactId>jdom</artifactId>
> =A0 =A0 =A0<version>2.0.1</version>
> =A0 =A0 =A0<scope>compile</scope>
> =A0 =A0</dependency>
>
> Now I want to include the additional dependency (this is just some
> 'arbitrary' dependency which has an internal dependency to jdom 1.1):
>
> =A0 =A0<dependency>
> =A0 =A0 =A0<groupId>net.sourceforge.htmlcleaner</groupId>
> =A0 =A0 =A0<artifactId>htmlcleaner</artifactId>
> =A0 =A0 =A0<version>2.2</version>
> =A0 =A0</dependency>
>
> Unfortunately this htmlcleaner code will not work because I am missing th=
e
> org.jdom.* classes because maven has only used the jdom 2.0.1 version whi=
ch
> only has the org.jdom2.* classes.
>
> The solution is, in my project, to also include the 'duplicate' 1.x
> dependency:
>
> =A0 =A0<dependency>
> =A0 =A0 =A0<groupId>org.jdom</groupId>
> =A0 =A0 =A0<artifactId>jdom.dep</artifactId>
> =A0 =A0 =A0<version>1.1.3</version>
> =A0 =A0</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 t=
he
> 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> =A0wrote:
>>>
>>> On 29 May 2012 15:26, Rolf Lear<jdom@tuis.net> =A0wrote:
>>>>
>>>>
>>>>
>>>> So, being inexperienced, my intention is to find some solution that:
>>>>
>>>> 1. makes it possible (even if playing exclusion games is needed) to us=
e
>>>> 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 spe=
nd
>> 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