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.

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,

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.