You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "J.Pietschmann" <j3...@yahoo.de> on 2003/04/23 01:28:28 UTC
Migration to commons-cli & avalonization
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
Re: Migration to commons-cli & avalonization
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 23.04.2003 19:55:47 Glen Mazza wrote:
> Joerg/Jeremias wrote:
>
> <Q>
> > 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.
>
> </Q>
>
> I didn't see it in the code either. But for
> external/embedded FOP use, commons-logging may not be
> all that bad, Struts has embraced it to avoid "But I
> wanna use [whatever logger] logger..."-type complaints
> from its users:
>
> http://marc.theaimsgroup.com/?l=struts-user&m=102090805604782&w=2
That's true. commons-logging is not bad. That's not what we say. Since
we're going to "avalonize" FOP we're also going to do logging in Avalon
style. That in turn means we want to avoid any additional logging
mechanism if possible.
> <Q>
> > 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.
> </Q>
>
> But wouldn't that make the CLI command for Fop to be
> "Main" and not "Fop"? (Things might get messy were
> other Java apps to follow with this convention!)
Why? You always have the fully qualified classname when you use that
class: org.apache.fop[.cli].Main. "fop" is still in the name, but Main
properly indicates that we're talking about a startable class.
> For classes to remove, perhaps we should get rid of
> the seldom-accessed Version class in the apps package;
> I think the Version should be kept as an attribute of
> the FOP/Main class. (If desired, I can submit a patch
> for this.)
That doesn't change anything. You just move the code. Now, it's plain
visible where the version number can be found. Maybe we can read the
version number from the JAR manifest but I don't see a need to change
that.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Migration to commons-cli & avalonization
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 23.04.2003 19:35:12 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I'd rather have an org.apache.fop.Main. Shorter and says it all.
>
> Cocoon and Ant follow this pattern.
> Batik has a bunch of stuff in org.apache.batik.apps.*.Main
> Xalan has org.apache.xalan.xslt.Process
> Xerces doesn't have a dedicated CLI
> Saxon has com.icl.saxon.StyleSheet
> Tomcat uses an incredibly complicated bootstrap process.
> Well, that are the approaches of other projects.
>
> I'd rather thought of org.apache.fop.cli.Main or something.
fine.
> We
> have our main CLI as well as the font utilities, the hyphenation
> serialization utility and potentially a bunch of other auxillary
> applications.
> We could put the auxillary stuff under
> a) org.apache.fop.cli.FontConverter
> org.apache.fop.cli.HyphenationSerializer
> b) org.apache.fop.FontConverter
> org.apache.fop.HyphenationSerializer
> c) org.apache.fop.apps.FontConverter
> org.apache.fop.apps.HyphenationSerializer
> d) org.apache.fop.cli.font.Main
> org.apache.fop.cli.hyphenation.Main
> e) org.apache.fop.cli.fontconverter.Main
> org.apache.fop.cli.hyphser.Main
> f) org.apache.fop.fonts.apps.PFMReader
> org.apache.fop.layout.hyphenation.HyphenationTree
> g) some other random combination.
> I'd favor either a or d. Variant e is awkward.
I like a). d) and e) are ok, too, but I don't really see the difference.
> > 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.
> Great!
:-)
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Migration to commons-cli & avalonization
Posted by Oleg Tkachenko <ol...@multiconn.com>.
J.Pietschmann wrote:
> I'd rather thought of org.apache.fop.cli.Main or something. We
> have our main CLI as well as the font utilities, the hyphenation
> serialization utility and potentially a bunch of other auxillary
> applications.
> We could put the auxillary stuff under
> a) org.apache.fop.cli.FontConverter
> org.apache.fop.cli.HyphenationSerializer
> b) org.apache.fop.FontConverter
> org.apache.fop.HyphenationSerializer
> c) org.apache.fop.apps.FontConverter
> org.apache.fop.apps.HyphenationSerializer
> d) org.apache.fop.cli.font.Main
> org.apache.fop.cli.hyphenation.Main
> e) org.apache.fop.cli.fontconverter.Main
> org.apache.fop.cli.hyphser.Main
> f) org.apache.fop.fonts.apps.PFMReader
> org.apache.fop.layout.hyphenation.HyphenationTree
> g) some other random combination.
> I'd favor either a or d. Variant e is awkward.
I also like e and org.apache.fop.cli.Main.
--
Oleg Tkachenko
http://www.tkachenko.com/blog
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Migration to commons-cli & avalonization
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> I'd rather have an org.apache.fop.Main. Shorter and says it all.
Cocoon and Ant follow this pattern.
Batik has a bunch of stuff in org.apache.batik.apps.*.Main
Xalan has org.apache.xalan.xslt.Process
Xerces doesn't have a dedicated CLI
Saxon has com.icl.saxon.StyleSheet
Tomcat uses an incredibly complicated bootstrap process.
Well, that are the approaches of other projects.
I'd rather thought of org.apache.fop.cli.Main or something. We
have our main CLI as well as the font utilities, the hyphenation
serialization utility and potentially a bunch of other auxillary
applications.
We could put the auxillary stuff under
a) org.apache.fop.cli.FontConverter
org.apache.fop.cli.HyphenationSerializer
b) org.apache.fop.FontConverter
org.apache.fop.HyphenationSerializer
c) org.apache.fop.apps.FontConverter
org.apache.fop.apps.HyphenationSerializer
d) org.apache.fop.cli.font.Main
org.apache.fop.cli.hyphenation.Main
e) org.apache.fop.cli.fontconverter.Main
org.apache.fop.cli.hyphser.Main
f) org.apache.fop.fonts.apps.PFMReader
org.apache.fop.layout.hyphenation.HyphenationTree
g) some other random combination.
I'd favor either a or d. Variant e is awkward.
> 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.
Great!
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Migration to commons-cli & avalonization
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
Re: Migration to commons-cli & avalonization
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Clay Leeds wrote:
> My take on this is that "I want to have my cake and eat it too." In
> other words, if we're going to implement something like this (and I've
> certainly been eager to have more control from the command line since
> that's how I tend to use FOP) would it be possible (and/or a bad idea)
> to retain the current command line interface, and have this commons-cli
> be optional?
There wouldn't much change in the command line parameters.
The change involves mainly replacing our home grown command
line parser with a library, and perhaps some cosmetical
package shuffling and/or using a new internal API.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Migration to commons-cli & avalonization
Posted by Clay Leeds <cl...@medata.com>.
Howdy devs,
My take on this is that "I want to have my cake and eat it too." In
other words, if we're going to implement something like this (and I've
certainly been eager to have more control from the command line since
that's how I tend to use FOP) would it be possible (and/or a bad idea)
to retain the current command line interface, and have this commons-cli
be optional?
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.
--
Clay Leeds - cleeds@medata.com
Web Developer - Medata, Inc. - http://www.medata.com
PGP Public Key: https://mail.medata.com/pgp/cleeds.asc
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org