It was an article about EJB, and Bruce was begging Sun not to make the same mistakes with EJB3 as they had done with EJB, and EJB2. They didn't, Spring came along as better alternative and forced EJB3 to become slimmer and better. If not for Spring, EJB3 would probably look very different from what it looks like today.
Well, guess what, there is a new elephant on the block and its name Maven2.
Just like EJB2, Maven2 was born out of something so unbearable that anything else was bliss. Jelly anyone!
But just as EJB was fundamentally flawed, so is Maven2. Build systems, even advanced ones like Maven is fundamentally about two things.
- Check if something that something else depends on has changed
- If so, do something.
The checking may contain various sophisticated methods for detecting if files, subsets of files, all files, web pages, twitter feeds, etc, has changed, but that is really it.
And the doing can be anything, Copy files, commit files, build websites, run tests, generate code, launch missiles, whatever!
But the key to doing this efficiently is a programming language with easy access to system commands and the ability to create simple abstractions, with methods, variables, and objects. The language should also, preferably, be one without a lot of ceremony, like Ruby, Javascript or Python.
There are already build systems like this out there, Buildr, SCons, and Rake come to mind, but they do not have the momentum of Maven, so a merger between Maven and Buildr would be wonderful.
So, Jason, hear my plea, Don't make me eat the elephant again!
6 comments:
Unfortunately a lot of very talented, well intentioned developers make assumptions about Maven that they don't understand. make-like system, with directly available programming constructs are categorically something Maven avoided intentionally and by design.
That wasn't an arbitrary decision, it was a calculated decision based on looking at hundreds of build systems. I've seen many system like BuildR and Grade, and many of them quite elegant at a technical level. But they all fail at the social level in an organization and become the source serious pain and risk. A lot of developers mistakenly think the build infrastructure is an appendage to their own work and not as a delivery mechanism for production software.
If you want to leverage Maven's infrastructure and write a scripting-based solution around it, you should take a look at Polyglot Maven: http://polyglot.sonatype.org. With that you can write an arbitrary system, with your own DSL to do whatever you like, leveraging whatever degree of the internals of Maven you wish.
However, to counter your point that a programming approach is the right one: in the some of the largest organizations there are I have unwound some seriously twisted build systems put together by over zealous developers who thought only of their penchant to turn everything into a programming task. Not considering that in the largest of organizations many who touch the build systems are not day-to-day developers.
Any decent hacker can make a some form of build system in a day. It's a topo-sorted DAG with actions affixed to the nodes in the graph. Everyone thinks it's this easy and that's all that matters. I beg to differ. Programming approaches to build infrastructure fail in large organizations.
Of over 2000 people surveyed at JUGs and companies in the last two years roughly 3% of people asked cared about POMs in different formats and DSLs for Maven. My take on it is that those 3% are extremely able developers who want the same set of constructs through all of their work. They want to code everything from end-to-end. That's totally fine, and that's why we made Polyglot Maven so that people with your disposition can create these systems.
I imagine that this 3%, if they adopted Polyglot Maven, would likely contribute as much back to Maven's internals as the rest of the 97%. That should give you some idea about the different kinds of people involved. Don't mistake your desire to program at every level, for a real organizational need. I can only try to tell you through my own experience these simply are not the same things.
Take a look at Polyglot Maven, it's probably more akin to the hybrid you're looking for.
Hi Jason,
Thanks for replying. I will reply with a blog post since blogger does not allow me to use syntax highlighting in comments.
My 'real organization need' is a tool that doesn't get in my way and is easy to use and extend. Maven is none of that.
Also I find it sad that the 'social level' jason talks about in the following sentence regarding buildr and the likes: "But they all fail at the social level in an organization and become the source serious pain and risk". This sounds to me like an organization that focus more on strict rules and conformity rather than creativity and getting things done.
If something is fun to do, I usually do it a lot better than if it is not. Using Buildr and Rake is fun. Using Maven is definitely not fun.
I rather spend time implementing features the business value, rather than maintain my home brewed build/release system...
I also like to spend my time with business features, but when using Maven I spend more time waiting, rather than doing what I would like to do.
Post a Comment