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?

org.apache.fop.apps.Fop

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


Mime
View raw message