Glen Mazza wrote:
> My current inclination after reading Victor and your
> posts:
>
> 1.) (Still), move org.apache.fop.pdf to
> org.apache.fop.render.pdf.pdfdoc (rename it similar to
> our rtfdoc package). Get it cleaned up and perfected,
> etc., remove obsolete classes, etc. *Then* discuss
> its future componentization.
I am less familiar with the placement of the pdf-related classes than I am
with the rtf stuff. But the issue in both cases is this -- code of a generic
nature for building the output files should be kept separate from our
renderers, which use that code in a specific way. While I do have strong
preference to keep such code separate, I don't have as strong of a
preference about how it should be done. The only two options that make sense
to me (ATM) are:
1. org.apache.fop.render.pdf.render
org.aapche.fop.render.pdf.lib
2. org.apache.fop.render.pdf
org.apache.fop.lib.pdf (or something like that)
I prefer the second, partly because the first looks silly, but primarily
because "lib" or whatever we call it can then be the place where we put
stuff that has potential external use. In other words, it keeps the generic
stuff segregated from our FOP code.
> 2.) Move org.apache.fop.rtf.renderer to
> org.apache.fop.render.rtf. It doesn't matter that the
+1
> RTF renderer doesn't need an area tree, or descend
> from our AbstractRenderer.java, etc., etc.--actually,
> that may be something to celebrate. For the solid
> foundation that Victor was talking about, the
> renderers should be placed together in the same
> package--sooner or later they're probably all going to
> be implementing a common (very) high-level interface
> anyway.
>
> [Are you in sufficient agreement on this one,
> Victor...if you can take of this with Peter's latest
> patch, that would be great...]
I don't understand the part about the patch -- let's get it applied before
making your proposed change.
> 3.) Move the rest of the rtf packages under
> org.apache.fop.render.rtf. No more rtf in FOP's root.
> (This issue is more controversial than #2 above, and
> can wait.)
This is the part I don't like, but I understand the point about rtf in FOP's
root. What do you think of the "lib" idea, or even using the
already-existing "util". Or perhaps some other name. I really think we lose
a lot when the renderers and lib code get commingled.
> 5.) While FOP can happily use lots of components (svg,
> avalon, etc., the more the merrier) it should not be a
> repository itself for components. Like Batik and
If we don't spin them out to other projects, then we have to be the
repository don't we?
> Xalan, all packages and classes in FOP should be put
> into places that make architecturally the most sense
> in FOP itself--as if no one else is using the code.
> More to the point, we don't keep dumping things in the
> root out of concern that an app importing us will need
> to use a long import statement to get to our classes.
>
> Example: our svg.PDFTextPainter imports from
> "org.apache.batik.gvt.text.TextPaintInfo". When
> creating this class, Thomas DeWeese (?) did *not* say
> "Uh oh...it would be horrible for FOP's code to be
> ruined with such a long import statement...I'm going
> to break Batik's architecture and place
> TextPainterInfo in Batik's root just so FOP can have a
> shorter import statement. It is more important to me
> that FOP looks better, even if I have to turn Batik's
> design into architectural sludge."
I don't understand this at all. I don't think anyone has argued that long
import statements are an issue. I suppose that the reason the rtf stuff
ended up where it is has more to do with its history than any desire to
reduce import statement lengths.
> I think the error in thinking here was that external
> users--at least the good ones--would *want* our
> classes to be anywhere other than the best place for
> FOP itself anyway! Open-source users want SW to be
> highly used, highly successful--personally, I'll
> happily write Texas-sized import statements so long as
> it keeps Batik the most solid SVG product.
I don't remember any of this either. Who argued so?
> 6.) After a component is cleaned up and gets demand
> from someone externally, move it to XML-Commons.
> Then, have FOP reimport the new XML-Commons package.
>
> 7.) Keep going. Keep cleaning up and keep moving to
> XML-Commons, and keep re-importing into FOP. But
> nothing get moved to XML-Commons unless there is a
> legitimate demand for it first. (Don't want to send
> them 14 things, only 6 of which end up getting used.)
> This one is going to take Victor the most amount of
> self-discipline--I'm not very optimistic here--he'd
> send his son to XML-Commons if he could get away with
> it! ;-)
Actually I am very sure that I have never proposed or even desired that
anything be moved to XML-Commons, although I did muse once 6-8 months ago
that hyphenation and some of our graphics stuff would benefit by being in a
more Commons-ish place. What I have proposed was that we adjust our build
process to build each of the components separately, so that the dependencies
are addressed and documented. Although I was envisioning it for the 5 core
FOP modules that exist only in my mind, the same concept works for these
modules as well. So, for starters, suppose we had:
org.apache.fop.lib.pdf
org.apache.fop.lib.rtf
org.apache.fop.lib.graphics (??)
org.apache.fop.lib.hyphen (??)
The rule would be that each sub-package under lib must compile without any
non-lib FOP code. You can use Ant to enforce this. You can even use Ant to
place these in separate jar files for distribution. Anybody who wants to use
them as separate modules can do so. You can document them so. Then, if the
need arises, it is *very* easy to spin them into separate projects. See
http://xml.apache.org/fop/dev/rtflib.html
for a bit of the vision that I have for this kind of code.
(Glen probably has no way of knowing this, but I actually have 5 sons, and
yes, there are days when I would send one or more of them to XML-Commons if
I thought they had a decent boarding school there :-) )
Victor Mote
