I'm stumbling over code blocks every now and then that could/should be reused or even used from a common library. Examples of that are stream copying code, little/big endian conversions etc. This is mostly little stuff but these things wouldn't need to be in our codebase. Sometimes there's code around that could simply be written much more cleanly. I've recently changed FontFileReader which had a very strange way of loading a file using buffers. I've added a copyStream method which could easily replaced by code from Commons IO, for example. Well, ok, I've introduced a bug when I did that, but after fixing the bug the code is now a lot clearer. Also, gradually introducing more of Avalon in the redesign will lead to additional jars that we will need.
So, what I want to have opinions for is the following: How could we handle the usage of additional libraries such as Jakarta Commons packages or stuff from Avalon Excalibur? Right now, we have avalon-framework.jar in our lib directory. I still remember the somewhat negative feedback from users when we introduced that one (!) new jar file as a dependency. Ok, we've also had LogKit, but we were able to make that one optional. Excalibur is a collection of small packages which all provide little jars, one or more jar per package/sub-sub-subproject. Of course, there's also a big one, but that would mean that you'd obviously have to use a big jar from which you may well be using less than 20%. Same for Jakarta Commons. So what comes to my mind is two things: 1. Provide a big fop-complete.jar which contains among the fop classes all the utility packages with an Apache home (Commons, Avalon stuff). That's for easy use and involves repackaging of the utility jars during build. 2. Provide the same fop.jar as before but we'll have some more jars in out lib directory over time. This obviously means that the classpath will get some longer. IMO both has to be done, especially to service those who don't like a lot of jars in their classpath. I'm looking forward to your comments and ideas. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
