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 dont 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 dont know if its possible to have a JDK without an XML parser
> in it any more. So if crimson could go away, thatd be great. Actually
> Im not sure why we cant 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:
http://www.excelsior-usa.com/articles/java-to-exe.html
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
case.
> 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?
See:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop?view=co
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop.cmd?view=co
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
classpath.
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
benefit.
> What is the OpenJDK issue? That it doesnt include the com.sun codecs?
Yes.
> > > 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
|