Rename artifactId in jdom2

[vmassol]

Thanks for JDOM2. Gotcha: using same groupId/artifactId than JDOM1 which makes it impossible to use side by side because of version resolution.

What Commons Lang 3 did was use same groupId but suffi a 3 to the artifact Id: org.apache.commons:commons-lang3

So I suggest org.jdom:jdom2 as the new groupId/ArtifactId and to release 2.0.3 ASAP with this.

Thanks!

[rolfl]

http://markmail.org/message/h52eeugc7oz3msnm

Please add a comment if this does not solve your maven problem and I will look in to it some more...

Thanks

Rolf

[vmassol]

Thanks Rolf for the link, I hadn't seen it.

IMO the choice isn't the best one since it means changing stuff that exist which is hard (imagine that you have transitive deps leading to JDOM, you need to add exclusions and then overrides). There's a high risk you're going to screw up somewhere.

ATM I've temporarily solved the issue by publishing a org.jdom:jdom2:2.0.2 artifact in the xwiki maven remote repo at http://maven.xwiki.org/externals/org/jdom/jdom2/2.0.2/ but it's a temporary solution.

I continue to think that the best solution for the JDOM project is to do a new release and change the artifact id. In this manner you have the best of all worlds.

Thanks

[tmortagne]

What I don't understand is that you choose the opposite for Java packages. The issue is exactly the same and the easiest and most consistent at Maven level is to do the same thing and follow Vincent suggestion IMO.

[rolfl]

I disagree.... it is more complicated than you realise, and the solution I have proposed is more simple than you realise.... ;-)

There is no ndeed for exclusions and overrides with the jdom-legacy solution.

You have yourself now made it more complicated by polluting the jdom groupid with the jdom2 artifact.... in the org.jdom2 groupid.... how does that work....

In response to Thomas, the problem was introduced with jdom 2.0.0 and 2.0.1, in the jdom artifact. Admittedly those were a mistake, but, once the mistake is made, it is impossible to 'rename' the artifacts, and the jdom-legacy solution is the best solution given the current state of things.

It is exactly because people (myself included) have made poor decisions about maven artifacts that we are in this position, but, in the balance of things, the jdom-legacy is the best, and most researched solution. See the links:

http://mail-archives.apache.org/mod_mbox/maven-users/201205.mbox/%3C4FC3F7A8.1040307%40tuis.net%3E

and

http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/%3C4FC95E87.8070109@tuis.net%3E

The maven-users threads related to this problem.

Unless there is a well-researched/motivated/presented argument against the jdom-legacy solution then I don't think this will change.

If you still have some concerns, please carefully consider the current state of things, and come up with a solution that solves all the current scenarios (which, for the record, the jdom2 artifact does not).

Rolf

[tmortagne]

In response to Thomas, the problem was introduced with jdom 2.0.0 and 2.0.1, in the jdom artifact. Admittedly those were a mistake, but, once the mistake is made, it is impossible to 'rename' the artifacts, and the jdom-legacy solution is the best solution given the current state of things.

This is very simple for me: this is the best to do on the long run (what are you going to do for 3.X for example ?) so that's what should be done. You have some bad versions on Maven central, so be it. It's really not a big deal.

[rolfl]

Thomas, it is a big deal. because thewre are already people with transitive dependencies on jdom 2.x from the jdom artifact... http://mvnrepository.com/artifact/org.jdom/jdom/2.0.0

What is not a big deal is adding jdom-legacy as a dependency to your project. That is the solution which is very, very simple.

Putting jdom 2.x versions in multiple different artifacts is a worse solution... for multiple reasons.

[vmassol]

Rolf, it's complex. I'm working on the xwiki project and it's a large project (lots of modules) with a lot of dependencies.

I'm definitely not going to track down all usages of JDOM1 throughout the project, nor upgrade them (right now a lot of deps if not all are using JDOM 1.1 - not 1.1.3, and I have no plan to upgrade them ATM and verify that all still work).

All I'm doing is adding a new module in the xwiki platform. This module is independent from the hundreds of other modules and this module wants to use JDOM 2.0.2. I really don't see why I would have to go to extra pains and review the whole build base (it's huge believe me) just to make this new module deploys well at runtime in XWiki.

Thus we have ATM no other real choice than to republish your artifacts in our local repository which is far from the ideal but the only real workable solution for us till we decide to upgrade everything to JDOM2. Too bad :)

[rolfl]

Hi Vincent, you are over thinking things.... there is no need to track down al the 1.x dependencies. There is no complexity.... ;-)

Maven will use the latest 'referenced' version of JDOM fromt he jdom artifact. If you have some dependency that requires 1.1, and another that requires 2.0.2 then maven will 'pull in' 2.0.2

The problem now is that your 1.1-dependant third-party apps will be missing their classes. all you have to do is add jdom 1.x back again with the dependency on jdom-legacy 1.1.3

Thus, the only thing you need to do is add the following to your project:

<dependency>
   <groupId>org.jdom</groupId>
   <artifactId>jdom-legacy</artifactId>
   <version>1.1.3</version>
 </dependency>

[tmortagne]

I think you don't realize the complexity you introduce in a build. Maven does not take the last version of the dependencies, it takes the first one it find so no it's not that simple to be sure the right version of jdom 2 and jdom1 will be selected. Your solution imply for every single project that depends on a projects with dependencies on jdom1 and jdom1 to jingle with it's dependencies or put dependencies on both jdom and jdom-legacy before anything else just to be safe even if it does not use it directly.

It's a pity to go for the very hacky solution on the long run just for two bad versions... Serious projects with dependencies on bad versions of jdom 2.x will fix their dependencies. As you can see on http://mvnrepository.com/artifact/org.jdom/jdom/2.0.0 there is only one project on central with dependency on jdom2, so yes this is far from being a big issue IMO.

[vmassol]

No Rolf, it's not like this. Let me give you more information. XWiki has an extension system that allows to install extensions at runtime. It's using maven under the hood (aether to be more specific). Right now it means that we cannot install the new module which depends on jdom2 since aether reports a conflict, the extension/module asks for jdom 2.0.2 but it has 1.1 installed already!

I think you're not seeing a lot of use cases and your solution will only work for a few of them, whereas the other simple solution will work for all cases... You're trying to be too smart and when dealing with Maven it's never a good idea ;)

Anyway, Thomas and I have tried to explain why your solution is not such a brilliant idea... I hope you'll reconsider in some not too far future! :)

Thanks

[aheritier]

Hi Rolf,

I'm sorry about the resolution of this issue too. At exoplatform we have exactly the same case like Vincent/Thomas. For now we had to deploy our own copy of jdom 2 in our repositories with another identity to avoid such conflict between modules in the same project. I would have preferred too a solution based on a new artifactId. I admit it's not simple now you started to publish jdom 2 under the same identity. But couldn't you change your build to produce at the same time the jar under both identities (by adding a new module with a jdom2 artifactId using the assembly or another plugin to rebuild the same content) ? WDYT ? At least you may satisfy everybody ?

[rolfl]

OK, I am no maven expert so I ran it past the maven mailing list, and got what I thought was a reasonable solution with reasonable consensus. Now I have multiple (assumed) experts disagreeing with that solution. I (obviously) do not understand the nuances of maven, so it is apparent that there is still a problem. It has been a couple of months, and it's still causing issues, I intend to release JDOM 2.0.3 in the next couple of weeks, and I am feeling more charitable to maven since 2.0.2 now that I have had some time away from it..... maybe I can rehash this issue.

Since the jdom namespace is already polluted with 2.0.0 (and then 2.0.1 and 2.0.2), and since 'everyone else' (non maven users) is entrenched with the continuation of the version numbers for the 2.x JDOM code, I would consider 'double publishing' JDOM 2.x on maven.

Would this compromise work:

• the main JDOM release is still called jdom-2.0.3.jar
• the maven release is still published to org.jdom artifact jdom version 2.0.3
• the same jar is then copied to jdom2-2.0.3.jar and released to org.jdom artifact jdom2.

non-maven users will be unaffected by this.
maven users who have simple projects will be unaffected.
maven users who have already become familiar with the jdom 2.x jars in the jdom artifact will continue as normal.
maven users new-to-jdom can select either the jdom2 or the jdom artifact
maven users with complex projects could optionally continue using jdom-legacy solution, or the new jdom2 publish.

I may be missing something, but in my estimation, the jdom2 artifact will just create additional problems.... people with 'complex' projects are going to have some third-party dependencies that require jdom 1.1, and other dependencies that require jdom 2.0.0, and now they want to 'solve' it by using jdom2-2.0.3

There is still going to have to be a barrage of 'exclusions' in complex projects.... because now you are going to be getting multiple copies of JDOM 2.x artifacts.....

So, I am reluctant to have multiple 'official' places where people can get 2.x versions of JDOM in maven.... because that will introduce a new type of problem.

On the other hand, I can't keep ignoring 'expert' complaints. At some point I have to say that 'I don't understand' and defer to 'people that do understand'.

• The situation is a mess.
• Maven does not offer a solution to 'repair' the mess, only to 'compound' the mess.
• My instinct is to minimize the potential problems.
• My gut tells me that adding 2.x versions to a new artifact will allow people to have multiple jdom 2.x jars in their builds (with the associated unexpected behaviours)
• Some 'experts' are telling me that the 'jdom2' artifact option is 'better' than the 'jdom-legacy' solution

It is impossible to please everyone.

At the moment it is only people with crazy-complicated build processes that are affected, and they are the same people who actually understand the problem well enough to create the right exclusions....

Maven-central is an unforgiving concept and it is a weakness..... not a strength.

So, I will reopen this issue.

I want comments as to whether double-deploying (to both jdom and jdom2) is a viable 'solution'.

[tmortagne]

For me the only viable solution is what we said already:

• "jdom" for JDOM 1.x
• "jdom2" for JDOM 2.x

Keep releasing wrong artifact id even if you also provide one with the right id does not fix much, people should never use "jdom" for "jdom2" or it will be a mess for anyone depending on their artifact. The best to not do a mistake is that it's impossible to do the mistake.

There is some bad versions on Maven central, OK but it's exactly like you had released version with blocking bug in it: it's just bad versions that people should not use. The sooner the situation is fixed the lower the issue is.