xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Improving the build and adjusting to changed dependencies
Date Tue, 18 Jan 2011 08:01:25 GMT
Thomas, Cameron, thanks for your feedback!

On 17.01.2011 21:52:28 Cameron McCormack wrote:
> I agree with much of what Thomas says.
> Jeremias Märki:
> > > 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. ;-)
> Thomas DeWeese:
> >         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.
> Yeah, I think for a Java developer not to have ant installed would be
> atypical.  I don’t think it is too much to ask for them to have it (or
> to get it) these days.

C/C++ devs on Unix also have to have "make" installed, just to give
another example.

> Also I don’t know if it’s possible to have a JDK without an XML parser
> in it any more.  So if crimson could go away, that’d be great.  Actually
> I’m not sure why we can’t just use the bundled Xerces…

Maybe Ant 1.6.5 is so old that it doesn't support JAXP, yet. But I
haven't checked. But yes, since we're moving to Java 1.5, there is
always an XML parser. So that also ask the question if the direct
dependency on Xerces is still a good idea. But that's for another day.

So, I gather you're not opposed to remove Ant, Thomas?

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

That is the idea. I like double-clicking JARs, too.

> I think the batik-squiggle.jar is the only one that will do something
> useful if you double click on it (i.e. without passing it any command
> line arguments).  That one and the other application jars do make it a
> bit easier to run the applications, so I agree we should keep them or
> something like them.  Without them, the user needs to set up the
> classpath correctly and know what the main class name is.  (Plus they
> also house the resources for the application.)
> I think as long as it is no more difficult for a user to run Squiggle,
> or the rasterizer, or the ttf2svg tool, then I am fine with whatever
> approach is taken here.

It will surely take some testing, especially on MacOSX (since I don't
have that). But for the user, I don't expect anything to change. What I
would like to achieve is to make life easier for us maintaining these
app JARs.

> What is the approach typically taken in other Java projects?  Do they
> tend to always rely on shell scripts and batch files for launching the
> application?

FOP has been using shell scripts for ages and that usually works ok.
Older Windows batch files had some ugly limitations that didn't allow to
gather all JARs from a directory. We've been able to get rid of that
which makes things easier. Most Apache projects I know use a combination
of a Windows batch and a Unix shell script for starting. A few Java
projects I know are using native wrapper applications but that's not
wide-spread. See:

IMO, executable JAR files are good for double-clicking, but for
command-line usage, I actually prefer shell scripts, because they can
more easily pickup environment variables. Example:

> ./fop.sh -fo test.fo -pdf out.pdf
> $JAVA_HOME/bin/java -jar build/fop.jar -fo test.fo -pdf out.pdf

Both lines do the same but the shell script is less to deal with in this

> BTW, when I write my own applications that use Batik, it always annoys
> me a little that I have to add all of the jars in lib/ to my classpath
> (or to work out exactly which ones I need).  Is there any way to make
> this simpler?

The Unix script can be simplified if things like Cygwin compatibility
are not important. Both scripts scan a directory and add all JARs to the

Or you wait until I commit my command-line tools for Batik which
contains an AppStarterUtil class that handles the dynamic class path
setup inside the JVM. Then you're back to easily doing "java -jar
myjar.jar". With AppStarterUtil, you create a very small starter class
like this:

public class MainDynamic {
    public static void main(String[] args) {
        AppStarterUtil.startApp(MainDynamic.class, args);

This assumes there is a "Main" class in the same package (i.e.
"MainDynamic" minus "Dynamic"). The original Main class remains
untouched. You'd have to adjust AppStarterUtil only minimally for
non-Batik applications.

> > > 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.
> Agreed.  Although I know the way the policy files are generated in the
> build file is kind of convoluted.

That's why I brought it up. We'll have to do some careful testing there.
But if we can get rid of the manual Class-Path entries that's already an
improvement. So the security policies can be a step two.

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

Probably not as much trouble as simply a lot of work without much hard

> What is the OpenJDK issue?  That it doesn’t include the com.sun codecs?


> > > 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...
> Yes, thanks Jeremias!  Those daily gump messages do get me down, so if
> you are able to find the time to resolve the codec issue that would make
> me happy. :-)

I'll try hard.

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