Jeremias Maerki wrote:
I'm stumbling over code blocks every now and then that could/should be reused or even used from a common library.
Extensions to the original proposal: - Modularize FOP a bit better: build separate jars for the core, CLI, AWTViewer and the servlet (and move the servlet from contrib to the main src tree) - Check what can be shared with Batik. Some parts of font handling comes to mind. BIDI handling too. Unify approaches in the API perhaps.
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.
Batik has a batik-all.jar and a huge bunch of smaller jars for people who want only a part of the functionality. While I like the idea of factoring out utilities and commonly used funktionality to projects like xml-commons, this increases the potential for version clashes. An example is the trouble in Cocoon because the Batik version needed by FOP was not the same as the one used by the Cocoon serializers. Auxilary libraries need a very stable API and a very careful design. If this is met, I'm +1, otherwise -0. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
