The Apache Maven project just announced the next version (2.7) of the Maven Eclipse plugin. This is the plugin that generates the .classpath and .project files.
All well and good. Except that version 2.6 introduced at least one new massive bug – it puts the JRE at the end of the project classpath, instead of at the start. This means that, due to some projects out there doing stupid shit liking including JDK classes, you can get code breakages (e.g. you use generic collections, but this bug causes you to compile against the 1.4 Collection API). This bug is rated as ‘CRITICAL’ on their own issue tracker. It was caused by a patch for a ‘MINOR’ issue.
This bug is not fixed in the new 2.7 version.
Why, Maven developers? Why? Why are you releasing any new versions yet? According to your JIRA instance, you have 1 BLOCKER – introduced in 2.6 – and 14 CRITICAL bugs, going back as far as 2.0. In 2.7, you “fixed” one CRITICAL bug – by calling it a duplicate of a bug that was only MAJOR.
I know, I know – it’s open source, it’s free, and you get what you pay for. But there is no excuse for this. Those priority levels are meant to reflect the urgency felt by the project team. If they really feel an issue is a BLOCKER, they shouldn’t release. If they feel an issue is CRITICAL, they shouldn’t be working on trivial issues. If they don’t feel that these issues are CRITICAL, they should change the status.
And, in the meantime, I’m staying on 2.5.1.
Share this:
Software is too expensive to build cheaply.... 
You should try another open source Maven plugin by Sonatype – Maven Integration for Eclipse – http://m2eclipse.codehaus.org/
I looked at it some time ago, found it rather poor. I’m willing to reconsider though. 😉
Still – the real problem I’ve got with Maven is how poor their process is and how lackadaisical they seem to be in regards to quality. This issue with the issue tracking is not unique to the maven-eclipse-plugin; the majority of Maven modules are similar.
Pitching in to second Logans opinion: the m2eclipse plugin is a wonder, and does real integration, rather than being a write-only shim that takes a maven setup and dumps an eclipse configuration.
Hi Robert,
You are right, we voluntarily creates shitty releases in Maven. We like to bother our users to be sure that they’ll go back to ant !!!
More seriously, we asked several times to our users on the mailing list to test the 2.7 before to release it and we had no feedback about this issue. You’re right on the fact that we should have to wait that all bugs were fixed before the release. I don’t like to do it, but I prefer to release something with less bugs than having to wait several monthes years to fix them all. You can criticize, our job, but remember that we are doing it for free. There are more than 200 issues on this plugin and we try do fix them with the few time we have. About MECLIPSE-442 I understand that using shitty libraries creates conflict with JRE classes. Our community is many more active on m2eclipse or Q4E and you should try to help us to improve those plugins which are the target. The eclipse:eclipse will die on its own weight. It supports too many things, tests aren’t validating that generated projects are working in eclipse and moreover, eclipse stores many many more settings in the workspace instead of in project’s config file.
Cheers,
Arnaud, you miss the point. I agree your time is limited. That’s what issue management is for – to allow you to focus on the things you have decided that matter.
You guys control the priority of the issues in _your_ JIRA instance. If you don’t think an issue is important, lower the priority. Mark it “won’t fix”. Whatever. But please, please, please don’t push out releases with a dozen minor issues fixed and not one of the outstanding critical or blocker issues. That’s the problem – not that the bug is there, but you aren’t paying attention to the issues in your own system.
Don’t worry – I’m not just picking on your module. Nearly all of the maven modules seem to have the same problem. Heck – Maven Core has a blocker open from 2.0.2.
Managing your issues pro-actively is a very cheap way to help engage your users, Arnaud. If you don’t think a bug is serious, lower the priority. If you want to try and get it fixed before a given release, assign it a target release – this is a good way for the project dev’s to agree on what should be fixed for a release. Leaving critical bugs open for extended periods with no feedback on the status is a very good way to push your users away.
This is not a rant about a bug. This is a rant about your bug tracking process.
On the plus side: I see the bug got fixed today. I’ll give 2.8 a go when it’s out.
FWIW: Something that may be magnifing this issue is that JIRA doesn’t have a field to track severity. In lieu of that most people use the priority field. Many organizations add a custom field for this, which helps to separate using priority to plan the release contents vs severity to indicate the impact of an issue.