I was reading dion’s response to Howard’s Maven post, and saw a comment there that said:
Howard is also looking at using JAM, which provides a pre-built set of ant tasks, much like Maven except written so I don’t have to learn a whole new tool and language. This seems to be what Maven should have been, if developed by people with sense.
Despite all the complaints about Jelly (most of which come from the Maven developers :), countless people have tried. I don’t quite understand that – you shouldn’t have to learn Jelly to use Maven. Maybe this is a problem with documentation and something I’m trying to fix right now.
I’ve said previously that JAM looks like a good idea – using what Maven is really about to generate Ant that everyone else understands until Maven can handle some of the things that get tricky (in particular multiple source directory handling is inconsistent in Maven 1.x).
A JAM developer posted this comment:
We actually see JAM as step towards Maven, not as a competing framework. But until Maven matures, Ant is still the reliable industry workhorse… and we hope JAM makes it a little easier to use.
This is good to see. I haven’t tried JAM out, but if it does what you need it to do, then I’d say go for it.
It’s a shame that Maven has come out being perceived as a glue for a bunch of Ant tasks. It’s a fair perception, because as I said in my last post, when you give users the option of producing reusable build fragments, it tends to happen real fast, so Maven has a lot of plugins out there.
I certainly look forward to a stronger adoption of Maven’s concepts of project information structure, and hope that Maven can continue to mature down its current path where it becomes the best tool to manage this information and build with it.