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: Something to discuss about the next Batik release
Date Sun, 20 Feb 2005 21:35:04 GMT
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

View raw message