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.


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

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

Reply via email to