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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
