That's reasonable. I wasn't asking you to personally commit it. I would commit it myself if I had the privileges, but am dependent on the good graces of other committers at present. Perhaps someone will volunteer.
G. On Tue, Sep 7, 2010 at 3:42 PM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote: > 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 > >
