xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Improving the build and adjusting to changed dependencies
Date Mon, 17 Jan 2011 14:11:23 GMT
Hi Jeremias,

Jeremias Maerki <dev@jeremias-maerki.ch> wrote on 01/17/2011 08:18:27 AM:

> 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. ;-)
 
        Personally I'm fond of a more or less standalone dev tree (we do 
have a dependency on
the JDK), but I recognize that this is not the typical approach taken 
these days.

> 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
> target.

        My main requirement here is that you be able to double click on 
the various 'application' 
jars and have them run.  So as long as the classloader stuff works with 
that it sounds fine.

> 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.

        This is where I start to get concerned.  Unlike FOP there is a 
strong possability that Batik
may be used to surf "the web".  This means that security needs to be taken 
extremely seriously. 
So anything that touches the current security framework needs lots of 
review.

> 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. 

        This has always been the stated goal that has just been more 
trouble than it has been
worth in the past.  I suspect that is now changing (especially given the 
developing issues in the
Java community process area).

> But since the color branch work is already on my own time I won't 
> promise anything on this just yet.

        Thanks a lot, for looking at this stuff...
Thomas DeWeese | CDG Advanced Development | 
Eastman Kodak Company | 343 State Street | Rochester, NY 14650-0128 | 
Thomas.DeWeese@Kodak.com | 585 724-0294 | 
www.kodak.com 

Mime
View raw message