Developing with Maven
Subject:   Dealing with the kitchen sink
Date:   2003-10-23 11:17:53
From:   kadams54

When we were looking at migrating from Makefiles to Ant scripts, we realized some of the problems Maven is trying to resolve. At that point (about 2 years ago), there was no Maven or Centipede. Gump was just getting started.

We took pretty much the exact route you advocated - an XSLT wrapper around a POM that transformed it into an Ant buildfile.

That approach works great for the 90% that's the same from project to project. The POM covers about 8% that differs from project to project. Unfortunately, there's always the 2% difference from one project to the next that's just unaccounted for. That's where Maven's pre- and post-processing goals excel - filling that 2% in.

And then there's the whole repository thing. To be sure, you could probably implement a JAR repository using Ant's get task, and utilizing the version info in your POM to dynamically generate the get tasks for that specific project. But you know what? That's a lot of hard work! I should know, since I'm adding that to our home-grown system right now.

Same thing with the web site generation. We also added that to our system, utilizing XSLT and Ant tasks. But it's also a lot of re-inventing the wheel that Maven's already done.

Finally, there's XSLT itself. XSLT is just not all that robust a programming/scripting language. Some of the processes I've had to implement to make the build file templating work are just plain ugly.

And therein lies my one beef with the Maven project - the choice of Jelly as a scripting language. From my viewpoint, XML is for data. It was never meant to be a scripting language, and is far to verbose for that. There is a natural synergy or flow when you combine Jelly with Ant, so I can understand why they made the choice, and in the end it's just a matter of opinion.

Once they've got a stable 1.0 release, I'll be looking forward to easing my development and support burden for our homegrown system and switching over to Maven.


Full Threads Newest First

Showing messages 1 through 4 of 4.

  • Dealing with the kitchen sink
    2003-10-23 19:43:56  anonymous2 [View]

    Jelly can also execute scripts in beanshell, rhino or other BSF-capable languages.
  • The Waterfall Model Applied
    2003-10-24 02:32:38  ianfairman [View]


    I'm willing to be persuaded that Maven could be an improvement over raw Ant. But when I look at how Maven is put together it unsettles me. In trying to deal with that 2% I think they've overcomplicated things and forced themselves into making a lot of decisions in a short period of time which I wonder if they'll regret. I've seen this *so* many times and the results are rarely good.

    Maybe XSLT isn't the answer - or maybe it's the whole answer or part of it - I don't know. But the "big bang" release of Maven leaves little room to rework design decisions without breaking things - it's the waterfall model all over again.

    One final thought, which I came across this morning: Orgel's Rule which states "Evolution is cleverer than you are" ( Start with a worse-is-better solution and see where that takes you - if XP has one lesson to teach us it should be that one at least.

    • The Waterfall Model Applied
      2003-10-24 04:47:03  anonymous2 [View]

      I'm curious as to where, specifically, you see examples of unnecessary complication.

      I'm also curious about why you see Maven 1.0, RC1 a "big bang" release of Maven; as far as I know, they've been the typical open source product with all the early alpha and beta releases, etc. Plenty of iterations occurring, plenty of reworking in the design decisions.

      Could you clarify on both of these points?
      • The Waterfall Model Applied
        2003-10-24 08:11:31  ianfairman [View]

        I suppose I'd see the complication as being in terms of too many features being put in version 1.0. Did Maven really need in version 1.0 a repository (with all its configuration management implications), a scripting environment based on Jelly (why choose that?), integration with Gump, project data visualisation, source code metrics?

        As for the "big bang", most developers are not seriously going to use Maven until it goes final - all iterations prior to that will be used by a more limited community. The developers will get a lot of useful feedback then which would have been easier to work with if Maven had been a smaller system.

        Maybe others see Maven differently. I'm willing to be proved wrong. Only time will tell whether the Maven developers took the right approach.