I see that you resolved the problem by copying qdox.jar from
/usr/share/java to lib/build before the build process. I installed the
resulting package fop_1.0.dfsg2-2 and ran it on a few test files. The
result was OK.
It would be good if alternative builds of fop would run a number of
our junit tests. The fop team should look into this to formulate a
recommendation.
Simon
On Sat, Aug 27, 2011 at 08:50:37PM +0200, Simon Pepping wrote:
> It is an interesting observation that fop can be compiled with
> qdox-1.12 in the lib/build directory, but not in the CLASSPATH
> variable. It even works with FOP's own jar files:
>
> CLASSPATH=lib/build/qdox-1.6.3.jar ant clean resourcegen
>
> in fop-1.0 fails, while
>
> ant clean resourcegen
>
> succeeds. The same error can be provoked in fop's development version.
> This problem is not a problem of qdox version, but of the way ant
> deals with the CLASSPATH variable, and the way qdox reacts to that.
> Somehow it does not have the effect of simply placing those jars in
> front of the classpath constructed in the build script.
>
> I cannot tell you how you should set your CLASSPATH variable for a
> variant build environment. It all depends on your requirements. If you
> wish to build fop with fop's build script but with jar files in the
> system, you might best edit the classpath variables in the build
> script: libs-build-classpath, libs-tools-build-classpath,
> libs-run-classpath. A quick scan of the build script suggests that
> almost all classpaths are constructed using these variables, plus the
> build directories created by earlier stages of the build. Exceptions
> are javadocs, which also uses ${java.class.path}, and findbugs, which
> uses ${libs-findbugs}.
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
