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: Something to discuss about the next Batik release
Date Sat, 19 Feb 2005 21:19:37 GMT

On 19.02.2005 21:43:28 Thomas DeWeese wrote:
> Jeremias Maerki wrote:
> > On 19.02.2005 19:12:16 Glen Mazza wrote:
> > 
> >>--- jeremias@apache.org 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...

No, no. It's just my English that was improved. :-)

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

Thanks! I hoped for that.

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

I think that shouldn't be problem if we have snapshots of the necessary
JARs in FOP's and Batik's lib directory. For example, you have
pdf-transcoder.jar in Batik's lib directory. This would be no different.
Right?

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

Yeah, I'm afraid of that, too. That's why I advocate the above. For
those who really want to start hacking they'll surely have nothing
against additionally downloading batik-transcoders and axgc.

But if someone has a better idea....

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

A kind of symlink? No, I'm afraid not. Not with SVN anyway.

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

Good point. We don't have to move everything. We can copy and deprecate
the old classes. After a year or 2 or 3 releases we can remove them.

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

That's debatable. I'm thinking about write permissions. I don't know if
all FOP people will want to give up write access to theses classes. I
wouldn't want to. I put them as top-level so we can have clear
partitioning:

axgc: write permissions for batik, fop (user) groups and possibly a axgc
group if the need arises.
batik: write permissions for batik
batik-transcoders: write permissions for batik and fop
fop: write permissions for fop

Of course, with SVN we can set the write permissions per directly within
the Batik codebase, but that gets complicated once you start branching
and tagging. But see below...

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

It's of interest to me. You would have to make me a Batik committer. :-)
I don't know who else would want to help maintain them. Keiron has the
knowledge and did so (he wrote the first one after all) but he's
obviously inactive.

Really, giving responsibility for the PDF and PS transcoders over to
Batik would be ok for me as long as I retain write access. I just didn't
think as far. Might not be such a bad idea after all...

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


Mime
View raw message