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 <j...@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.conno...@gmail.com> wrote: >>> >>> On 29 May 2012 15:26, Rolf Lear<j...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
