xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Migration to commons-cli & avalonization
Date Wed, 23 Apr 2003 09:25:32 GMT

On 23.04.2003 01:28:28 J.Pietschmann wrote:
> 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?

Not anymore AFAIK. The dependancy is still there in build.xml and
project.xml but not in code.

> - 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?


I'd rather have an org.apache.fop.Main. Shorter and says it all.

> 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.

The latter please. Separation of concerns. We can probably do some
Configuration object merging (or use a lifecycle extension) to
accomplish that. I'll try to figure that out.

> Related topic: I added some spec regarding the expected behaviour
> of the various resolvers to the Wiki, without any feedback. Any
> takers?

Just didn't get to it. Sorry.

> 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.

That shouldn't be a big problem. There's a ProxyGenerator (in ECM) for
using the new Component-less components in the old environment. Just
forget the Component marker interface and use Servicable. It'll work out.

I had my Barcode stuff to look after recently and will be away from
tomorrow until 2003-04-30. I want to set up the Avalon container
(Fortress if nobody has a better idea) right after that.

If you want to work on the CLI now maybe you and Glen Mazza could team
together. He seems interested in participating.

Jeremias Maerki

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

View raw message