Maven difficult to customize. Basically antlibs for
especially, Ivy. :) In fact, I already came up with
"Shaven". ;)
> Hi,
>
> It's been a long time since I'm thinking about this,
> and thought it might be
> interesting to share with you and see where the idea
> can go.
>
> I see many developers adopt Maven because they want
> a build system able to
> provide common features with no effort. Most of them
> don't want to spend
> much time writing an Ant script, or have seen or
> heard that maintaining Ant
> build scripts is troublesome. So they choose to use
> Maven only because it's
> easy to use for common use cases: install, write a
> simple pom of a few lines
> or generate it using an archetype, and you're ready
> to compile, test and
> package your new project following the Maven
> standard structure. They also
> get dependency management for free, and with only a
> few more effort they
> have multi module builds, and some nice features
> like code analysis,
> coverage, and a set of report gathered in a web
> site. That's really nice and
> that's what I like about Maven.
>
> But Maven suffers from a lack of flexibility and
> robustness IMHO. And later
> the same people who first adopted Maven because of
> its perceived ease of use
> become frustrated when they need to tweek the system
> to their own needs or
> don't understand how the release plugin work. Then
> some of them go back to
> Ant, first having to go through a sometimes painful
> road to describe their
> whole build system in xml, especially if they aren't
> Ant experts. Others try
> to use new build tools like raven, buildr or others.
>
> I really like Ant, and think it is a very good basis
> for robust and flexible
> build systems. People with enough knowledge of Ant
> can write very good build
> systems, testable, maintainable and adaptable. But
> you need to get your
> hands dirty, and you need to get a good knowledge of
> some of the mechanisms
> which can make an Ant based build system manageable:
> import, scripts and
> scriptdef, macrodef, presetdef, and so on.
>
> Hence I'm wondering if it wouldn't be a good idea to
> package a set of Ant
> build files, providing all the basic features of a
> build system for java
> projects: dependency management, compilation,
> testing and packaging, plus
> maybe some more advanced features like code coverage
> and code auditing.
> Multi module build support would be nice to have
> too. Then someone needing
> only those features could simply have a build file
> per project mostly
> consisting of a single import of the common build
> file provided. Some
> needing more could provide plugins to the build
> system itself. Some needing
> to tweak the system could simply override some
> target definitions or
> properties. Others with very specific needs could
> simply use the build
> scripts as examples or basis.
>
> I guess most people on this list know the benefit of
> having such a build
> system and how well it scales, and most of us
> already have developed such a
> set of build files. But providing the basis of such
> a good build system well
> packaged and documented could improve the Ant
> community IMO. With some
> efforts from our community we could end up with
> something interesting pretty
> easily. Most of us don't have much time, but we
> probably already have a good
> basis from the build files we work with around, and
> if this can be done in a
> community effort it could remain affordable in terms
> of time required.
>
> So, what do you think? Do you think this would be
> useful? Would you be
> interested in contributing? Do you think a new Ant
> sub project would be a
> good fit?
>
> Xavier
> --
> Xavier Hanin - Independent Java Consultant
>
http://xhab.blogspot.com/>
http://ant.apache.org/ivy/>
http://www.xoocode.org/>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.