Something to discuss about the next Batik release

[je...@apache.org]

(PMC chair hat on....)

Folks,

I realize that Batik will soon want to do a new release. There's an
issue I wanted to bring up. Batik delivers the pdf-transcoder.jar with
its distribution. Until now this was always a CVS snapshot. There was no
tagging (FOP) CVS or involvement by the FOP team in such a release. This
is obviously a suboptimal situation.

With the new oversight rules demanded by the Board, a release within the
XML Graphics project needs to be sanctioned by the PMC. This is to
ensure that there are no legal and other delicate problems in a release.
This process also makes sure that there's an logged connection between
the (sub)project making a release and the ASF (or one of its officers,
in this case the PMC chair). See also:
http://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers

What does this mean now? You know that I have the idea to separate
certain components in the FOP (and Batik) codebases into a separate
repository/area which is writable by both teams. I've given this some
thought lately, and now that we have a Subversion repository it's
probably time to get this started. 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.

That is not to say that this has to happen before Batik does its next
release. What I would like to see, however, is that the Batik team
informs the FOP team (via this list) when they are getting near the
release so the FOP team can make sure that everything is ready for a
release. FOP will need to have its codebase tagged before Batik does a
release and Batik will use the FOP tag to create the Batik release.

Any comments or questions?

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

Re: Something to discuss about the next Batik release

[Thomas DeWeese <Th...@Kodak.com>]

Jeremias Maerki wrote:

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

    Yes, and no as more and more critical pieces are moved out
of Batik it will be increasingly likely that needed pieces will
not be part of the source distribution.  This probably isn't
a huge problem at this point but is something to keep an eye on.

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

     Including the jar's will help this.

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

   We could also just proxy them (empty subclasses), but your intent
was to repackage them.  My gut agrees, however I can't find much
logical support for the move.

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

    The problem is dependencies, if we leave it as a separate
top level project then we maintain the current problem of
Batik depending on the pdf-transcoder classes and the
pdf-transcoder depending on Batik.  So when you make changes
(like your rendering hint change) you will often need to
build the batik jar copy to the pdf-transcoder project build
the pdf-transcoder project, and then copy the pdf-transcoder
jar back to the batik lib directory so you can run the transcoder
and test the change :(

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

    Well, I'll help to maintain them (as I have in the past).  I
also wouldn't think that it would be a major problem to ensure
that you maintain write access.




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

Re: Something to discuss about the next Batik release

[Jeremias Maerki <de...@greenmail.ch>]

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

Re: Something to discuss about the next Batik release

[Thomas DeWeese <Th...@Kodak.com>]

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

>>> 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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

Re: Something to discuss about the next Batik release

[Jeremias Maerki <de...@greenmail.ch>]

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.

> > What does this mean now? You know that I have the
> > idea to separate
> > certain components in the FOP (and Batik) codebases
> > into a separate
> > repository/area which is writable by both teams.
> > I've given this some
> > thought lately, and now that we have a Subversion
> > repository it's
> > probably time to get this started. 
> 
> I just got Subversion working on my machine yesterday,
> and downloaded the committers module.  So I am
> comfortable with SVN I guess.  Question:  what within
> XML Graphics do we currently have a Subversion
> repository for (their URLs)?  Just the XML Graphics
> website? 

Yes.

> > 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.
> > 
> 
> Make sure it includes what the PDF Transcoder
> dependencies are, 

Already done.

> also, how we will get FOP to build
> once the Transcoder classes are pulled out.

Will do.

> 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


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

Re: Something to discuss about the next Batik release

[Glen Mazza <gr...@yahoo.com>]

--- jeremias@apache.org wrote:
>
> This is to
> ensure that there are no legal and other delicate
> problems in a release.

other sensitive problems

> What does this mean now? You know that I have the
> idea to separate
> certain components in the FOP (and Batik) codebases
> into a separate
> repository/area which is writable by both teams.
> I've given this some
> thought lately, and now that we have a Subversion
> repository it's
> probably time to get this started. 

I just got Subversion working on my machine yesterday,
and downloaded the committers module.  So I am
comfortable with SVN I guess.  Question:  what within
XML Graphics do we currently have a Subversion
repository for (their URLs)?  Just the XML Graphics
website? 

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

Make sure it includes what the PDF Transcoder
dependencies are, also, how we will get FOP to build
once the Transcoder classes are pulled out.

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

Thanks,
Glen


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