Maven & Howard: How to Execute the Perfect OSS Drive-by Shooting

This post is a response to a post on Ship's blog from Friday.

Dependency management is not conflated with builds in the framework as a whole, it is an essential part of a build sytem. While you intended to speak about subtracting dependency management from the build, you end up reinventing the wheel simply because you can't be bothered to learn how to use Maven. Your entry is the rant of an angry five year-old. I can't figure out Maven, so I'm going to propose using it for dependency management, grafting it to a custom Ant script, and then using Ruby to craft a classpath. You don't have a single qualified statement in the whole entry and you go on to suggest things that work again the idea of creating sensible, easily understood standards for developers. I'll pick two.

1) "Because the build system is so awful." You always blather on and on about this but we have thousands of users (and Sonatype hundreds of clients) who would say otherwise. We can't seem to get rid of you but maybe you should just use a completely non-Maven build system so we don't have to continue to hear from someone who can't be bothered to learn about something he didn't invent.

I'm willing to bet my life you'll still be the physical embodiment of a build system diatribe. Howard, if you weren't so unconstructive and rude you might get a little more help. It's called tact, sometimes it's useful. It's the combination of plugins that always present problems to users because we don't validate every possible combination and interaction between plugins. It has taken us many years of listening to users and incorporating feedback from constructive participants to get to where we are. As far as your specific issue, that's just a hard problem and inside Eclipse the problem is exacerbated. We're working on it, if you would like to help us converge on a solution, you are more than welcome, but your sniping tells me you are less than interested in being constructive.

2) "Without using the often flakey and undependable M2Eclipse plugin." No version specified, no discussion, no tests, no qualification. No emails to the m2eclipse development team, no bug reports, nothing. We have many organizations and users that we are working with to address specific issues on m2eclipse, and we're making quick progress on the 1.0 release. If you had been participating, if you had been communicating, we probably could've either solved your problem immediately or pointed you in the right direction. Despite the fact that you frequently snipe us, maybe it would have been a good opportunity to get some constructive feedback from a critic.

You are likely using 0.9.8, which is, frankly, ancient and not supported at the moment. We've recommended people use the 0.9.9 dev builds for some time, and the two builds are a universe apart. If you're using 0.9.9 dev builds we're pretty quick at fixing problems because the Maven 3.x trunk is synced up with the M2E dev builds. See Howard, useful information. Some constructive feedback. You do know that with the 0.9.9 dev builds we have customizable lifecycle mappings which allow you to eliminate as much of the Maven lifecycle as you wish? Which in your case may be all of it which is perfectly valid. But your solution negates workspace resolution, automatic javadoc and source downloading which are vital for debugging, the POM editing capabilities, searching for dependencies and a slew of other conveniences and your Ruby script just really isn't a decent substitute.

Eclipse is just hard to integrate with because it has its own world of resources, files, classpath and pretty much everything else. That's not a cop out, it's a challenge that we're overcoming with real effort. That's life and we can deal but that's why the M2E plugin is not 1.0 yet. But in all seriousness try 0.9.9 dev builds if you haven't. If it's WTP problems you're having then that isn't entirely our fault. WTP is another world of integration ... trying to find a nice euphimism ... challenges.

Did you ever stop to consider that you basically can't resuse anyone else's software and that you just rewrite everything? The build system doesn't seem to be any different. Why don't you just write your own if you're not happy with anything else? I volunteer to be the first to try Hive Build. Or, why don't you just stop and actually spend all this energy trying to help fix some of these problems? You can't just take what you like out of a system – in this case the dependency management – and then slag the rest with unqualified nonsense. If it didn't work for you and you had a vitriolic, cathartic reaction like Assaf did. At least Assaf redirected his energy toward creating Buildr, and I can respect that. I don't think Assaf is entirely accurate, but he said his peace and then made something he likes better. Good for him, and more power to him. You, on the other hand, take what pieces you like, continually bitch, and periodically drive by and shoot us in the back without lifting a finger to help or even communicate.

You know how many things I like about Tapestry? Zero. I've had to work with it in a few places I've been, and I certainly have my opinions.

How many blog entries do you see me taking pot shots at Tapestry. Zero. I've actually had to use Tapestry and I can't say it was very enjoyable for me. I could whine and bitch, but I wasn't prepared to do anything to fix the issues. So it serves no purpose to complain and I'm sure there are people who find Tapestry useful and are happy with it.

If you actually had qualified explanations of problems you might get help, but more often than not you lead in with rancor. Doesn't exactly endear anyone to your plight. You suffer from "obnoxious user deficit". Instead of showing up at the front door asking questions and providing quality feedback, you barge in shouting about how awful everything is. You start off by annoying the people who could help you the most. I'm certainly not compelled to do anything for you. You're one of those users who thinks acrimony is more effective at delivering results then civil dialog. Don't be a tactless open source sniper espousing rancor (TOSSER).