xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: XML Graphics Commons: last call
Date Tue, 09 Aug 2005 11:12:18 GMT
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?

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

    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.

---

Other comments:

    You should probably add 'SVGGraphics2D' to the java2D tree,
and possible components coming from Batik.

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

    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?

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



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


Mime
View raw message