This post is a response to a post on Ship's blog from Friday.
Dependency management is not conflated with builds in the framework, it is an essential part of a build system. 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 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 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 that in 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 took us many years to listen to users and incorporate feedback from constructive participants to get to where we are. As far as your specific issue is, 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 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 with whom we are working 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 to use 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 know that with the 0.9.9 dev builds, we have customizable life cycle mappings, which allow you to eliminate as much of the Maven life cycle 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 isn't a decent substitute.
Eclipse is 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 yet 1.0. 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 challenges.
Did you ever stop to consider that you can't reuse anyone else's software and just rewrite everything? The build system seems no different. Why don't you just write your own if you're unhappy with anything else? I volunteer to be the first to try Hive Build. Or, why don't you just stop and 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, 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 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, 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 enjoyable for me. I could whine, 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 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 shout about how awful everything is. You start 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).