Because I want to hear other opinions from the other committers first.
So far, none of the others responded. And I've stated in the past I
won't spend any more time on anything Maven-related, so I'm unlikely to
process the patch myself. I won't veto the addition but I certainly
won't spend any time maintaining it.

On 07.09.2010 09:29:15 Glenn Adams wrote:
> ok; but is there any reason not to commit the patch to permit those who find
> maven useful to use it? there are many features in FOP that cater to
> specific interests, why not permit that with the build process as well?
> 
> regards,
> glenn
> 
> On Tue, Sep 7, 2010 at 1:52 PM, Jeremias Maerki 
> <d...@jeremias-maerki.ch>wrote:
> 
> > 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
> >
> >




Jeremias Maerki

Reply via email to