On 09/07/2010 04:25 AM, Glenn Adams wrote:
Having gone through the process of creating this working maven build
configuration, it seems that the potential benefits of its use include:
* dependency management of the use of external artifacts, which is
not managed by ant, and causes us to include external dependencies
as part of the source (and binary) release, as well as maintain
them in the repository;
FWIW, you can also achieve that with Apache Ivy, which uses the Maven
repos to obtain and manage dependencies, but doesn't require the use of
Maven for builds.
http://ant.apache.org/ivy/
That said, personally I'm reasonably fond of Maven, though I do
sometimes find the maze of plugins and options difficult to deal with
and find managing its configuration challenging. I do really like the
consistency and standardisation it brings to builds - if it's a Maven
project, you know how to build and use it, you can figure out build
issues immediately, you already know how the sources are structured, etc
etc etc.
I've come from the C/C++ world of autotools (autoconf/automake/libtool),
CMake, and other nightmare build systems from hell ... so Maven is a
real breath of fresh air - despite its flaws.
In any case, I view this patch as being experimental, and am willing to
maintain it. If after some time elapses I am the only user of it, then
it could be removed. However, at present, there seems few negatives in
commit it, particularly since it does not touch any other parts of the
hierarchy.
It'll also make it easier to maintain a Maven snapshot repository, which
should improve user testing in real-world use of embedded fop
significantly. I use in-progress code a *lot* more when there's a Maven
snapshot repo availible for it, so I don't have to track svn and
manually update the built jars periodically.
If you're interested in running a snapshot repo, Sonatype Nexus may be
worth looking into.
--
Craig Ringer
