On 29 May 2012 15:26, Rolf Lear <[email protected]> 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: <?xml version="1.0" encoding="utf-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>org.jdom</groupId> <artifactId>jdom-deprecated</artifactId> <version>1.1.3-SNAPSHOT</version> <name>JDOM Deprecated API and implementation</name> <properties> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <project.build.outputEncoding>UTF-8</project.build.outputEncoding> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>org.jdom</groupId> <artifactId>jdom</artifactId> <version>1.1.3</version> </dependency> </dependencies> <build> <plugins> <plugin> <artifactId>maven-shade-plugin</artifactId> <version>1.6</version> <executions> <execution> <goals> <goal>shade</goal> </goals> <configuration> <createDependencyReducedPom>true</createDependencyReducedPom> <createSourcesJar>true</createSourcesJar> </configuration> </execution> </executions> </plugin> </plugins> </build> </project> Will give the user the ability to play the exclusions game > 2. 'salvages' the current mess as simply as possible for the 'typical' > maven user. > 3. is something I can describe on the jdom website and expect people to > understand how to get it right... ( I don't want to have to do 'maven > support' ;-) > > The way I understand things is that once I deploy to a second artifact > (either deploy JDOM 2.x to 'jdom2' artifact, or alternately deploy JDOM 1.x > to 'jdom1' artifact), rather than call it jdom1 I would call the artifactId something like jdom-deprecated or jdom-legacy... or even better change the groupId to org.jdom.deprecated > then users can 'exclude' any conflicting dependencies > from their 'required' third-party projects, and substitute them with the > ones from the 'alternate' artifact. > > In my head it seems that creating a jdom1 artifact would be very stable (I > do not expect any more 1.x JDOM releases....), and then people can 'stick' > with the 'jdom' artifact, and if they run in to problems they can play the > 'exclusion' game with the jdom 1.x dependencies, and replace them with the > jdom1 dependency. Actually the easier solution is not to play the exclusions game at all if you move jdom 1.x to jdom-deprecated... a plugin management forcing 2.x at the root will solve the issue of the 2.x versions, and then just adding the jdom-deprecated (providing they share no classes) dependency will fix up the classpath. > > This 'keeps it simple' for the typical user, but still makes it possible > for the 'conflicted' user to get their jars.... ? right? > > But, would that be 'sensible'? Would a maven user 'follow' that logic? I think an artifact called jdom-deprecated would be clear to somebody > > I am not really in any position to have firm opinions on this. The only > preferences I have would be: > 1. I want the official JDOM release (on www.jdom.org) to be identical to > the releases on maven - I don't want to have different jar names, etc. The > www.jdom.org release is the 'official' release, and maven is a 'mirror'. > 2. I would prefer to continue calling it jdom-2.0.2.jar instead of > jdom2-2.0.2.jar - to keep consistency with what we have already done.... > but this is a lower priority. > > Thanks for the insights so far .... > > Rolf > > On Tue, 29 May 2012 15:00:54 +0100, Stephen Connolly > <[email protected]> wrote: >> On 29 May 2012 14:53, Curtis Rueden <[email protected]> wrote: >>> Hi Rolf, >>> >>> >>>> Unfortunately, there are already some 'third party' packages that > depend >>>> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have > two >>>> different versions of the same jar .... right? ... which is perhaps >>>> worse >>>> than not having it at all ... ;-) >>>> >>> >>> Since your goal is to allow JDOM 1.x and JDOM 2.x in the same JVM from > a >>> Maven project, publishing as org.jdom:jdom2:2.0.x seems like the way to >>> go. >>> You can continue publishing org.jdom:jdom:2.0.x as well; the > duplication >>> does not really cause any problems other than potential confusion. >> >> Curtis, >> >> the issue is transitive version resolution. If one of your >> dependencies depends on org.jdom:jdom:1.x and the other depends on >> org.jdom:jdom:2.x then you're going to end up with something broken as >> maven will resolve only one version of org.jdom:jdom... so you will >> end up having to play the exclusions game to stop that version being >> pulled in and manually add a dependency to org.jdom:jdom2... >> >> this is why one of the major feature adds I want to get into maven 4 >> is a provides scope. >> >>> As long >>> as you document why org.jdom:jdom2 exists, it seems fine to me. >>> >>> -Curtis >>> >>> >>> On Mon, May 28, 2012 at 5:15 PM, Rolf Lear <[email protected]> wrote: >>> >>>> Unfortunately, there are already some 'third party' packages that > depend >>>> on jdom 2.0.1, and thus, people using the new jdom2 2.0.2 will have > two >>>> different versions of the same jar .... right? ... which is perhaps >>>> worse >>>> than not having it at all ... ;-) >>>> >>>> Rolf >>>> >>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
