Getting rid of JIMI
Hi, I was looking into getting FOP to run with kaffe[1] recently[2][3], and decided to have another look at it today, after gettig maven to run with kaffe. I tried to generate DocBook docuemntation for another package, and the Maven sdocbook plugin insisted on fetching jimi.jar from Sun. So I'm wondering whether there is any need for JIMI any more in current FOP CVS sources, i.e. if PNG image handling is now being done within FOP internally? If that's not the case, would it be possible to use the LGPLd code from http://catcode.com/pngencoder/ and http://www.sixlegs.com/software/png/ for the job, and dropping the dependency on JIMI completely? If this is a FAQ, I'm sorry for wasting your time, I couldn't find an answer in the FAQs ... cheers, dalibor topic [1] A free software runtime for java programs, see http://www.kaffe.org [2] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04038.html [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg04023.html
Re: Getting rid of JIMI
Hi Glen, thanks for the quick reply. Glen Mazza wrote: --- Dalibor Topic <[EMAIL PROTECTED]> wrote: If that's not the case, would it be possible to use the LGPLd code from http://catcode.com/pngencoder/ and http://www.sixlegs.com/software/png/ for the job, and dropping the dependency on JIMI completely? No, (L)GPL and the Apache licenses are not compatible. While I understand that GPL2 and ASL 1.1 are not compatible, I don't see a problem with LGPL 2.1 and ASL 1.1. Could you elaborate? cheers, dalibor topic
Re: Getting rid of JIMI
Hi Jeremias, thanks for the quick response. Jeremias Maerki wrote: The ASF does see a problem. Until the FSF has clarified the relationship between "linking" and Java's import concept the ASF's policy is not to allow usage of LGPL packages. There are certain exceptions. For example, if you have a JAI-compatible image codec under the LPGL you could use it because FOP would directly link only with the JAI API, not with the codec that's made available through JAI. See also: http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing Thanks a lot for the link! That was precisely the sort of information I was looking for. A possible work-around is to establish a better plug-in concept for our image lib adapters in HEAD (not 0.20.5) so interested parties can create plug-ins outside of the ASF to use LGPL libraries. I'm not very well aware of the differences between all the different image io APIs, so please excuse me if my next question is a typical newbie question. If, for example, we had javax.imageio support working for PNG images in GNU Classpath (and Kaffe), would/could FOP automatically use that, or would it still need to use JIMI? The reasoning behind this being that PNG image support seems to be part of JDK 1.4 anyway, so it will be implemented in free runtimes eventually as well. cheers, dalibor topic
Re: Changing policy on minimum JDK requirements for HEAD
Hi Glen, Glen Mazza wrote: Here's the team's comments so far on this topic: On a somewhat related side note, most of those features asked for by the fop team from jdk 1.4 (logging, prefs, new util classes) exist in free runtimes (kaffe, gcj, sablevm, ...) already. The major blocker on running all of fop on free runtimes is the need to use non-distributable code like jimi for some features, and the state of java2d support on free runtimes (in the works, I plan to merge in agile2d into kaffe for a speedy opengl based java2d implementation, and there is work on a cairo/gtk+ based java2d implementation in GNU Classpath). Given that the free runtimes are quite widely ported, to even rather obscure platforms (arm-acorn or superh-linux [1], anyone?), and are catching up quite quickly[2], I hope the issue of 'does a vendor support java 1.4 on some platform' is going to be moot in a year or two, since you may be able to simply use [3] gcj/gij/kaffe/sablevm on your platform of choice to satisfy your customer's needs. cheers, dalibor topic [1] Kaffe has more than 50 platforms in CVS and a few more to be merged in ;) [2] http://www.kaffe.org/~robilad/loc.png ;) [3] Depending on developers actively maintaining these runtimes there, of course ;)
Re: Changing policy on minimum JDK requirements for HEAD
Michael Reiche wrote: On man, 2004-01-26 at 14:08, Chris Bowditch wrote: Anyone who has worked in a large organisation will know: it is very difficult to upgrade the OS on a server (which is a pre-requiste for later JDKs on some platforms). Large companies tend to have request forms/processes just to copy a single file onto large servers/mainframes, let alone upgrading OS/JDKs. AIX is one example. To get Java 1.4 on AIX you need at least AIX 5.1. And whats worse is that it also requires a certain level of hardware (Common Hardware Reference Platform). A lot of currently active AIX-servers do not meet this requirement, including our development server at work :-( I guess that's one of the areas where looking into what free runtimes can offer, as long as your needs are constrained to the (ever-growing) subset of 1.4 covered by them, might be interesting. Essentially, as soon as a free runtime covers all of FOP's needs, you automatically have another option, i.e. to switch to a free runtime. cheers, dalibor topic
Re: Remove image.JimiImage from HEAD?
Glen Mazza wrote: --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: Why are you so keen on removing stuff? I'd be more concerned about adding the stuff that's missing for an initial release. Just cleaning up for the next release. Jimi works fine for some people. No reason to remove this. OK, so it does work for the Java 2 platform. We'll keep it then. I haven't been following the developments very closely, so this may sound like a stupid question: does that mean that FOP HEAD now works nicely with PNGs without JIMI? Has the code from Batik been merged in, or has another solution emerged? cheers, dalibor topic
Re: Remove image.JimiImage from HEAD?
Jeremias Maerki wrote: Not a stupid question at all, but no, with FOP 0.20.5 you still need either JIMI or JAI for PNG support. But it may well be that the next FOP version will support PNG without an additional library. For now, you're stuck, though. thanks for the quick responce, Jeremias. I'm going to be a bit involved with Fedora documentation project's attempt to build up their toolchain using FOP on GNU Classpath based runtimes[1], so I'm glad to hear that there is a chance of having PNG work out of the box in the next release. My initial experiments with Kaffe & FOP a while ago have been encouraging. I am considering spending some time getting FOP to work on gcj, Kaffe and other runtimes, as I'd like to use it to generate man pages for kaffe using kaffe, among other things. I assume HEAD is the best place to start for an interested developer? cheers, dalibor topic [1] And with debian's efforts to get FOP into main.
