Mailing-List: contact batik-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xmlgraphics.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 18 Jan 2011 09:52:28 +1300
From: Cameron McCormack <cam@mcc.id.au>
To: batik-dev@xmlgraphics.apache.org
Message-ID: <20110117205228.GB14050@wok.mcc.id.au>
Mail-Followup-To: batik-dev@xmlgraphics.apache.org
References: <20110117141826.5325.60BA733C@jeremias-maerki.ch>
 <OF8604E4A2.79DC8736-ON8525781B.004D1A68-8525781B.004DF2BC@knotes.kodak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <OF8604E4A2.79DC8736-ON8525781B.004D1A68-8525781B.004DF2BC@knotes.kodak.com>
Organization: Mozilla Corporation
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: Improving the build and adjusting to changed dependencies

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.

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…

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

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?

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?

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

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

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

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

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