xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Migration to commons-cli & avalonization
Date Tue, 22 Apr 2003 23:28:28 GMT
Hi devs,
I've taken an extended look at commons-cli. Well, the package
is not realy a full CLI but a commandline-to-options parser,
which is still pretty useful.
The good news:
- Definition of options, associated help texts and some
   dependencies between options is much easier.
- It would be really easy to get renderer specific configuration
   options from the renderer, if this is seen as a good idea.
The bad news:
- Commons-cli depends on commons-logging. Ouch! Commons-logging
   has an Avalon-logging adapter, good, but will this really not
   interfere with the attempt at FOP avalonization?
- Constructing all the objects may have an impact on the CLI
   startup time.

The remaining question: what else beside fop.apps.CommandLineStarter
and fop.apps.CommandLineOptions should go out of the window?
We could have a FOP class with a static main, calling the commons
CLI parser, creating the abstraction for the specified input (direct
or through XSLT), create the specified renderer and delegate renderer
specific option parsing to the renderer. This creates CLI specific
code in the renderers, which might cause opposition by embedders.
Possible solutions:
- Subclassing the specific renderer classes in order to add
   option processing
- Use a separate class, provided by the specific renderer packages,
   which do option processing and create a configured ready-to-run
   renderer object.

Related topic: I added some spec regarding the expected behaviour
of the various resolvers to the Wiki, without any feedback. Any
takers?
Also, I don't quite understand how FOP avalonization should be
attempted. In particular, I don't understand what consequences
the deprecation of Avalon Component and the introduction of
Servicable has wrt. Cocoon compatibility.

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org


Mime
View raw message