This post originated from an RSS feed registered with Java Buzz
by dion.
Original Post: Maven: Extension Points in your Build System
Feed Title: techno.blog(Dion)
Feed URL: http://feeds.feedburner.com/dion
Feed Description: blogging about life the universe and everything tech
Maven gets a lot of flack. Hani enjoy's making fun of it. I even joked about it a little via:
All I wanted was a jar and I got a website
However, the more I get to play with it, the more I like it. And, it sure beats the alternatives :)
One side effect that I have noticed is that it allows me to have clearly defined extension points in my build. And, even more importantly, it allows me to NOT think about every extension point when designing my projects build.
When using Ant, I always found myself spending time really thinking about the dependencies.
Hmm, shall I have this general build target depend on a customer dion-build which I can later override and do cool stuff in sub-projects?
I found that I ended up with a bunch of:
<target .... if="some.magic.property">
In my Maven projects, I don't seem to need any of this. Why don't I?
I think it stems from:
The Plugins: I try really hard to rely on plugins to do the work for me. First, I try to follow their defaults. Second, I tweak their properties to give me some flexibility if needed. Only as a TRUE last resort do I look to hack the maven.xml. I find that it is rare to get to the last resort.
pre/postGoal: A lot of the good plugins have nice extension points. You can almost setup base goals which are NO-OPs, which you can later extend by implementing your own. However, even if this doesn't exist, via pre/postGoal settings, you can extend anything!
Being able to extend anything with a pre/postGoal has proven to be very productive. What I really like about it, is that you don't have any coupling between the original goal, and the extension mechanism.
For example, if you want to extend the java:compile goal to do something else, you can preGoal it to have the extension, say generating some other source code before the compile step. Note that we are not having to tweak the original goal at all. There is no coupling here. Maybe this is a personal preference, but that feels much cleaner than piecing together the puzzle via depends="".