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;
   - automated report generation
   - improved continuous integration management tools

Although I had to puzzle through some aspects of maven configuration, I
found it was sufficiently flexible, particularly in combination with the
antrun plugin, to produce good results. I don't particularly see the use of
maven as a maven vs ant issue. They both have their uses, and given the
antrun plugin, one can accomplish the necessary customization of maven goals
using ant, as opposed to writing custom, one-off plugins.

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.


P.S. I did not try a WIN (cygwin) build. For symlinks, I used the ant
<symlink/> task, both to create and delete. If that task is implemented on
WIN, then I would expect it to work.

On Mon, Sep 6, 2010 at 10:17 PM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote:

> Personally, I'd not be happy if we added a parallel build system. Given
> that so much Ant code is necessary to handle some details shows how
> inflexible Maven is. I haven't checked how much Ant code is duplicated
> between the root-level build.xml and the files in the "maven"
> subdirectory. IMO, this would be a maintenance head-ache since the two
> always have to be kept in sync. If build.xml would be split into
> re-usable sub-file (Ant is quite flexible), some duplication could be
> avoided maybe. But that would still impose some level of redundancy. At
> any rate, you probably can't count me in to help maintain the Maven side
> due to my very bad experiences with it.
> Also, I'm not sure if the <symlink> task will work as expected on
> Windows.
> On 04.09.2010 12:41:14 bugzilla wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=49881
> >
> >            Summary: [PATCH] add maven build support
> >            Product: Fop
> >            Version: 1.1dev
> >           Platform: All
> >         OS/Version: All
> >             Status: NEW
> >           Severity: enhancement
> >           Priority: P2
> >          Component: general
> >         AssignedTo: fop-dev@xmlgraphics.apache.org
> >         ReportedBy: gl...@skynav.com
> >
> >
> > This patch adds support for building with maven 2.2.X or later. I have
> tested
> > it with the current version (2.2.1) on a JDK 1.6 platform.
> >
> > There are no direct dependencies on JDK 1.4 or 1.5 features, but I have
> not
> > verified yet.
> >
> > The patch creates a new top-level directory 'maven' in the FOP trunk
> directory.
> > See the file README-MAVEN.txt there for configuration and usage
> information.
> >
> > Once downloaded to your home directory, this patch may be applied as
> follows:
> >
> > cd ${FOP}/trunk
> > gzcat ~/patch-maven-build.diff.gz | patch -p0
> > svn add maven
> >
> > Note that only the core fop.jar artifact is built at this time. In
> particular,
> > the fop-transcoder and fop-sandbox jar artifacts are not yet built.
> >
> > This patch has been verified against repository version 992575.
> >
> > Regards,
> > Glenn
> >
> > --
> > Configure bugmail:
> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug.
> Jeremias Maerki

Reply via email to