xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: XML Graphics Commons: last call
Date Tue, 09 Aug 2005 12:07:47 GMT

On 09.08.2005 13:12:18 Thomas DeWeese wrote:
> Hi all,
> > On 08.08.2005 22:31:09 J.Pietschmann wrote:
> >>2. Seeing Avalon as dependency makes me uneasy. I'd prefer
> >>commons code to be refactored to not using Avalon and to
> >>provide raw functionality only.
>     So I am a bit concerned about the addition of three new
> external dependencies for Batik.  I realize that some of it is
> already there but hidden in the PDF transcoder.
> Jeremias Maerki wrote:
> > Everybody always complains about that little library. What's the problem?
> > We're not going to do Avalonization anymore. But the configuration
> > subpackage in A-F is a perfect (!) little tool and a LOT smaller than
> > Jakarta Commons Configuration. 
>     What are we configuring?

Fonts and optional PDF-fine-tuning, mostly. Not everything that could
also be configured in FOP 0.20.5 is already implemented in the trunk.



PDF- and AbstractPSTrancoder implement the Avalon Configurable interface
to receive the configuration for fonts and PDF ATM:
(For PS this is only prepared but not implemented, yet)

The following Wiki page shows how this is currently used:

> > If anything, those who have a problem
> > with A-F should propose a viable alternative (I haven't seen one, yet)
> > or work with the Excalibur guys to extract the configuration subpackage
> > into a stand-alone lib.
>     Since I have no idea what the library is and/or what you
> plan to use it for I can't really provide alternatives.

Avalon Framework [1] defined a special programming model promoting
Inversion of Control and Separation of Concerns. We had plans to use
these patterns in FOP but it never really came to that. Now that the
Avalon project has been closed (mostly due to community wars),
maintenance of A-F has moved to Excalibur and Cocoon is currently moving
slowly away from Avalon to OSGi, this is no issue anymore.

But A-F contains a configuration subpackage [2] which is very small,
very easy to use and provides exactly what is necessary to load a
configuration tree from an XML file and to access values in a type-safe
and fail-safe manner while not having to deal with the deficiencies of a
DOM. I've also used it exactly for that in Barcode4J (my open source
barcode library) with great success.

[1] http://excalibur.apache.org/framework/index.html
[2] http://excalibur.apache.org/apidocs/org/apache/avalon/framework/configuration/package-summary.html

>     I'm also not thrilled with adding lots of logging dependencies. 
> Logging makes sense for 'non-interactive' contexts but is not really
> what you want for most interactive contexts.

AFAICS there is exactly one dependency on Commons Logging. Avalon
Logging is not used anymore.

I don't see how logging disturbs operation in interactive contexts. Do
you prefer logging by System.out? Or can you do without logging? I
learned that I can't. Logging is a very powerful means while debugging
(dev- and deployment-time).

> ---
> Other comments:
>     You should probably add 'SVGGraphics2D' to the java2D tree,
> and possible components coming from Batik.

Done. Remember, it's a Wiki! And we get change logs on
commits@xmlgraphics.apache.org. :-)

>     I'm not sure what the intent of the code structure is.  It
> looks like each of the 'parts' is intended to be an independent
> 'project' (i.e. separate source tree's).  Would it make more
> sense to just have one source tree and separate based on
> packages (this is what batik does to build it's sub jars)?

That's one possibility but people have a hard time understanding what is
in which of the batik JARs. Like FOP, Batik is a big blob of code. What
I intend with the split is to make it easier and (more importantly) less
overwhelming for newbies to start working on certain parts. FOP is scary
and so is Batik. Experience shows that despite a clean package structure,
people still don't find their way. I don't say that my proposal will
definitely solve that problem but I suspect it might help. At any rate,
this is an aspect that we need to take very seriously. Batik (even more
than FOP) needs to attract new contributors. What happens if you and/or
Cameron suddenly go inactive? There's no one left. Project dies. (Sorry,
my PMC hat shows here)

Is that plausible?

>     The current system seems like a lot of extra build nonsense
> since each jar has to be built in turn so it can be used to
> compile the next project, right?

Not necessarily. I don't think a separate build for each package is
necessary. I think it's simply helpful to more clearly show to
interested people what the individual parts are. This also favors a
cleaner design which is an additional benefit. I think Victor Mote could
tell you a good tale how he alone already profited from dividing FOray
(a FOP fork) into digestable chunks. 

>     Also you keep mentioning 'pattern' classes which might not be able
> to be transfered (depends on GVT tree), I think you probably mean the
> 'gradient' classes which should be able to be moved (we will try to
> move the pattern stuff but it isn't a slam dunk).

Could be. I probably messed that up.

Thanks for the feedback.

Jeremias Maerki

Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message