J.Pietschmann wrote: > Victor Mote wrote: > [interesting stuff] > > Package 1 2 3a 3b 4 > > tools | | | x | | | > Should be 4 (apps) module, I think. > > > util | x | | | | | > Uh, I never liked that. > > > Here is my +1. > +0 > > > Now in the table above, the "common" package does not exist, > but represents > > five classes that I would like to move to complete the process > of isolating > > column 1. Those classes are: > > apps/FOPException > +1 > > apps/FOUserAgent > ???
AFAIK, this is really configuration options. > > apps/FOFileHandler > > apps/InputHandler > Should stay in apps See below for discussion. > > pdf/PDFEncryptionParams > Why should this go into a "commons"? I agree that "commons" isn't the right concept. This is really configuration stuff, which generally needs to be available to all of the modules. > > apps/FOFileHandler and apps/InputHandler could logically go > into the FO Tree > > package. > I don't think so. They are abstractions for the Processor input and > don't have anything to do with the FO tree. My preference would really be to put them in a "parse" package. We have kind of lumped parsing in with FO Tree building as a practical matter, hence my comment. Since we have the Structure Renderers, we really have parsing without FO Tree building. One possibility would be to create an apps.common (or whatever) package to throw this stuff into. That way the build process could distinguish them, but would still be picked up in apps (this would solve Glen's concern about FOException as well). Conclusion: We have three active committers right now, one positive, one negative, one lukewarm, so I will abandon the enforcement idea. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
