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
At 02:11 PM 12/1/02, you wrote:
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)
gee, last I checked, the AWTViewer is fewer than a dozen classes,
and
J.Pietschmann wrote:
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)
+1 We need a bit of COP here. What about a little brainstorm on
decomposing FOP
Ralph LaChance wrote:
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)
gee, last I checked, the AWTViewer is fewer than a dozen classes,
and I'd
Jeremias Maerki wrote:
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
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
