xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Improving the build and adjusting to changed dependencies
Date Mon, 17 Jan 2011 13:18:27 GMT
Working towards preparing the color branch for a merge into trunk I
noticed how much code duplication there is in the Ant build and how many
hard-coded JAR names are in manifest Class-Path entries or security
policy files. Also, the code to create the Maven artifacts seems to be
very similar to the code to create the regular JARs. I think that can
easily be merged by the use of Ant's macrodef feature.

Batik currently has an Ant 1.6.5 in lib\build. I would suggest that this
be removed in favor of an Ant installed on the developer's machine. We
don't have any negative experience on this in FOP that I can remember.
I'm always building with my local Ant installation rather than the
build.bat from Batik anyway. And the crimson.jar in lib\build is by now
an ancient relic. ;-)

I've written some code that gets rid of the need for the Class-Path
entry in the various application JARs by using some class loader magic.
I've done something similar for FOP and that seems to work. I don't
really like the hard-coded JAR names in "Class-Path". The class loader
"magic" also allows to replace (or add) certain JARs without a rebuild.
I don't know, yet, if that will also work with the Mac-specific build

I'm not sure, yet, how best to handle the policy files. There's quite
some moving and copying going on there. I found it difficult to find all
the places where I can find references to the various JAR names of all
used dependencies. Maybe some XML+XSLT (i.e. more code generation) would
make things easier here.

Finally, I would also like to look into the image codec issue. With XGC
added as new dependency it would make sense to do a final sync between
the codecs in Batik and XGC and then remove the ones in Batik. During
that task I could see if I can resolve the OpenJDK issue without losing
sight of the finer issues with PNG. But since the color branch work is
already on my own time I won't promise anything on this just yet.

If any of you have any thoughts on the above, I'd love to hear them.

Jeremias Maerki

To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org

View raw message