Jeremias Maerki wrote:
On 19.02.2005 19:12:16 Glen Mazza wrote:
--- [EMAIL PROTECTED] wrote:
This is to ensure that there are no legal and other delicate
problems in a release.
other sensitive problems
Right.
Am I supposed to be able to read something between the
lines here? I agree with Jeremias's statement I just
feel like I missed something in this exchange...
I'm going to do most of the grunt work if this is approved
and once we've agreed on a plan (although help is welcome
as usual). I'll write up my ideas for a plan in the Wiki
shortly.
I'll help with the Batik things (more on that later)
although I don't think they will be much work as most of our
stuff has fairly well structured dependencies.
also, how we will get FOP to build
once the Transcoder classes are pulled out.
Will do.
This is the biggest issue for me, currently it's easy for
people to get started building Batik (grab a nightly tarball
or "cvs co") and if you have a JDK you are good to go. FOP
is currently similar (I don't know if you have nightly source
dumps). This is a _really_ nice feature.
What I don't want to have happen is that building either
of the projects involves a "chain of pain", to build this I
need X, to build X I need Y... (this is really common for
graphics tools in Linux land).
To that end is it possible to "link" directories into
other repositories, so that both Batik and FOP can directly
reference the axgc tree (if you do a co of batik you would get
the needed pieces of axgc - or even the whole thing).
The other major issue with the restructuring is repackaging.
Do you anticipate moving classes into new packages (org.apache.axgc)?
This would be quite disruptive (I'm not worried much about the
stuff down in ext/awt/image, but the stuff in util is pretty public).
If you want to move FOP completely to SVN at this
time, that would be OK with me also. Or, FOP can
still be on CVS while the transcoder portion is
"subverted".
See draft plan: http://wiki.apache.org/xmlgraphics/XmlGraphicsCommonComponents
My only major comment on this is that I don't see
the need for the batik-transcoders top level project.
Once the PDF dependencies are cleanly pulled out into the
commons is there any reason not to move the transcoders
(PDF/PS) into the Batik transcoders package?
I'm not trying to "steal" your code but is the code really
of interest to FOP? I've always considered it a favor that
FOP hosted it for Batik (because building/testing would be
such a mess the other way around). Perhaps there is a dependency
I am unaware of in FOP (I suppose even if there is you could
just use them from Batik since you already include it).
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
