Well, Ivy has one fundamental problem in common with Maven that many regard
as a great feature: the repository. Numerous times, I couldn't get a Maven
build to complete successfully because some artifact was temporarily or
permanently unavailable. Introducing an external repository immediately
adds a new dependency in form of the repository to the build which is
one more point of failure. And how many times did a Maven/Ivy build
download half the Internet just to build a small project? For a private
project I started out using Ant+Ivy but I'm in the process of dropping
the Ivy part again. And I've had the repository hand-maintained in a
project-local SVN subdirectory. My Eclipse's Maven and Ivy plug-ins are
long uninstalled because of the trouble they caused. Repositories are
probably ok in a corporate environment where you can run over to the
admin to fix the server. For open source projects, my opinion and
experience is that a repository only adds head-aches for some users.

Another problem of an external repository is the lack of license
management. ASF projects have clear requirements what kinds of
dependencies are allowed. If you can't control transitive dependencies
based on a license policy you're bound to run into a problem there. I
know at least a couple of ASF projects which didn't notice a license
problem by themselves and had to be pointed to it.

I can check out (or extract) FOP and build at least a basic version
locally with no outside connection. I like that and would like it to
stay that way.

On 07.09.2010 04:33:02 Craig Ringer wrote:
> 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

Jeremias Maerki

Reply via email to