-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename artifactId in jdom2 #87
Comments
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 |
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 |
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. |
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 |
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. |
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. |
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 :) |
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:
|
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. |
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 |
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 ? |
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:
non-maven users will be unaffected by this. 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'.
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'. |
For me the only viable solution is what we said already:
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. |
Thomas and Vincent (who is for sure an expert of maven, see http://www.oreillynet.com/pub/au/2205) are fully right, and you even seems to agree as well that:
So what else to do than fixing the mistake ? For sure, the past cannot be undone, so fixing it early will cause less troubles than continuing the wrong way. The mistake is currently affecting only a few initial releases of jdom2, this should not prevent you to do it right now. The "jdom2"solution is not better, it is simply correct. The jdom-legacy and double packaging does not really solve anything when you consider transitive dependencies. There is no need to have an over complicated project to encounter such an issue, and well used, maven usually shine solving those dependency issues. It is false to say that maven does not provide proper way to manage complex situation, but you said that you would like to minimize potential problems. Leaving JDOM2 published as jdom will surely cause unexpected troubles. Do you really want that users of maven look at other libraries just because of them ? This would really be a poor situation since JDOM shine at its own task, and missing this great tool because of a simple build problem would be a pity. You seem to dislike maven, but it is really a tool worth being known. I would be happy to discuss this with you, but this is not the right place. Anyway, if you consider useful to release for it, please do it properly and every maven user will thanks you. |
Hi Denis, Vincent, all... See, I actually do agree with you, I agree that it was a mistake to use jdom artifact for jdom2 (in my defense, I checked with a number of people before I did that, most people suggested using jdom2, but when I expressed my desire to keep the jar called jdom-2.0.0.jar instead of jdom2-2.0.0.jar, they did not fight it). I have three comments: Firstly, Denis, you say: "So what else to do than fixing the mistake ?" For me, fixing the mistake means removing the 2.x releases from maven-central.... which is not possible. I am of the opinion that any system which is unforgiving is a broken system. I believe that the maven-central policy of never deleting a resource is a problem. That this JDOM screw-up is a case-in-point. I think that people who defend this policy should both: 1. have a history of never making any mistakes, and 2. volunteer their time to vet any submissions to maven-central and should then take responsibility for screw-ups... So, right now there is one problem, the transitive dependencies are screwed up in JDOM with some projects. Unfortunately, from what I can tell, releasing JDOM 2.x in to the jdom2 artifact does not solve that. People will still have transitive issues because there are already people using the 2.x releases in the jdom artifact. Releasing JDOM in to jdom2 artifact only adds to the problem becaus enow there are multiple places for 2.x releases. The 'right' fix for this problem is to remove the 2.x releases from jdom, and release 2.x to jdom2. The Current 'fix' is not great because people could technically add multiple 1.x releases to their projects (1 from jdom-legacy, one from jdom). The proposed 'fix' of releasing future 2.x to jdom2 (while keeping previous 2.x releases in jdom) does nothing to 'fix' the existing problem, it just adds additional ways for people to mess up their dependencies. maven-central needs a way to do proper fixes. In the absence of that, it does not really matter what I do because I can never make it right. Sure, I can release anything I want, but there's nothing I can do to fix things, only make things worse. You say: And you are right, to a point. Maven does not suit my circumstances (professionally, the companies I work for require tighter (legal) controls over third-party-content). I don't feel that maven adds much to the way I do things. I do not hold this against Maven though. What I really hate though is maven-central, and how one misinformed mistake I make is irreparable. If a system has unrecoverable conditions then it should have systems in place to prevent them. I think it is unforgivable to have a system that is not possible to rectify. Unfortunately, this whole experience has tainted my perspective. Really, my attitude at this point is that no matter what I do someone will be complaining.... this is not a good way to have to 'deal' with maven when there's only going to be negative feedback. So, it is a lost cause. I may as well release to jdom2 artifact, and then have to deal with three sets of disenchanted people:
OK, so 2.0.3 will be released to jdom2 artifact only, and then we will see what mess arises. |
Hi Rolf, Thanks for your decision, I am really confident you will never regret it. If Maven Central allows you to remove existing releases, you would be able to break existing users of these broken releases. You seems to miss the idea that maven also provide versioning to the dependency system, and therefore, there is absolutely no reason to delete something from the past. For older versions of jdom2 actually released under jdom, if you think there is a usage for them (the only I see is a backward compatibility breakage in the upcoming release), you could release them again with the jdom2 artifact. What you really need to do is to clearly state with your upcoming release that previous releases under the jdom artifact as well as the legacy workaround were mistakes, and that these should simply not be used anymore, also encouraging existing users to make themselves a fix release of their own product using the new artifact as soon as possible. So we could expect that properly maintained projects depending on yours will also release a fix and that all this mess will simply be a thing of the past very soon. For others, this is not really important anyway. Thanks for this great library, I am looking forward to your next release. |
Thanks a lot for your decision ! |
It is done, but I anticipate some new problems will arise at some point. Now my hands are tied though... all the bridges are burned, and there's no way off the island ..... If anyone complains now, I can always blame you (all) ... ;-) |
Thanks Rolf! |
Thx Rolf and don't hesitate to ping us if some people don't understand the justification of the change. |
* Use our own JDOM2 artifact (published at http://maven.xwiki.org/externals/org/jdom/jdom2/). See hunterhacker/jdom#87
* Use our own JDOM2 artifact (published at http://maven.xwiki.org/externals/org/jdom/jdom2/). See hunterhacker/jdom#87
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!
The text was updated successfully, but these errors were encountered: