What Xavier is describing is exactly what I thought Maven should have been- a
standard way to lay out projects, with Ant underneath to use as needed. And
once your projects become non-trivial there is always the "as needed" part.
We spent a long painful month trying to move from Maven1 to Maven2, and
ultimately gave up. We quickly grew tired of trying to write plugins to
handle things that would have othewise been 5 lines of Ant (or things that
worked in M1 but no longer work in M2). Not to bash Maven, but things
become really hard once you move outside the lines a little bit. Then on
the other extreme you have Ant- complete freedom to do things are you see
fit, but there is not much in the way of standards or guidelines. There
ought to be a middle ground here somewhere.
We're currently in the process standardizing on a common set of Ant scripts
that get imported, using Ivy for dependency management. I can tell you-
things become a LOT simpler once you get a few common use cases worked out,
and just refer to them from each project's build.xml.
In general we are following the Maven directory model, so things are laid
out like:
src/
main/
java/
resources/
test/
java/
resources/
webapp/
WEB-INF
Things generated by the build (classes, artifacts, etc) get built in
"target". A build.xml for a simple jar project is about 5 lines of
boilerplate:
<project basedir="." default="package" name="my-project">
<property name="org" value="my-org"/>
<import file="../../../../common/antbuild/common-build.xml"/>
<target depends="jar" name="package"/>
</project>
Dependencies are external in ivy.xml, but that's all that's need to resolve
dependencies, compile, test, package and deploy this project. War and Ear
projects are not much more complicated than this either. I would very much
like to discuss this idea, and hear what others are doing.
George
Xavier Hanin wrote:
>
> 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/
>
>
--
View this message in context:
http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p15418993.html
Sent from the Ant - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
