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: [email protected] For additional commands, e-mail: [email protected]
