By the way, I live in a third world country (Philippines) with highly variable connectivity and usually get no more than 20-30kB/s for downloads. Furthermore, I don't have an IT infrastructure or servers, but am using an isolated Macbook Pro for my work. Yet, with all that, I have not had any particular trouble with maven dependency downloads.
Regarding transitive dependency analysis and license verification, it seems that maven provides useful tools to audit this. If Apache applications of maven fail to pay attention to this information, then it isn't the fault of maven. In any case, I have not and am not proposing to substitute maven for ant. I only wish to share a useful build process with others that are comfortable with using maven. Those that are not can ignore this feature. Regards, G. On Tue, Sep 7, 2010 at 3:29 PM, Glenn Adams <gl...@skynav.com> 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 >> >> >
