On Wed, 2006-04-12 at 14:07 +0200, Jeremias Maerki wrote: > On 12.04.2006 13:55:44 Peter West wrote: > <snip/> > > Is there other than accidental co-ordination between commons, batik and > > fop? > > "Accidental"? ATM, no coordination is required for releasing Commons as > Batik doesn't use it, yet. The plan for XML Graphics Commons on the Wiki > is still valid and provides the base for work on Commons. FOP 0.92 will > still use Batik 1.6 as we can redistribute only released JAR files. No > snapshot JARs as in the past. Coordination as necessary between > subprojects in XML Graphics happens on [EMAIL PROTECTED] > > > What guidance will there be for users in co-ordinating versions of > > the three? > > I don't understand the question, sorry. >
I had drawn the conclusion, falsely it appears, that co-ordination of the three elements was in the offing. Hence the discussion of the stability of trunk code in fop, batik and commons. I don't see how you plan to work the extraction without such co-ordination. It is an aim that the batik guys be able to commit to the transcoders. That impacts on fop. There is a question on the wiki about builds. Individual builds or one über-build? Buzzing around at the back of that question is the larger one of co-ordinating the trees. The wiki mentions that the transcoders can be used in the batik context (and others) independently of fop. However, don't the transcoders get involved in the round-trip when embedded svg elements are rendered by fop to pdf or ps? I don't know, but if so, there's a nice chain of dependency from fop -> batik -> fop', where fop may not currently equal fop'. The current split of fop and commons has nothing to do with batik, it seems. I was working on the assumption that the creation of commons implied the three-way compatibility of trunk elements. "...a Batik release didn't involve a FOP release until now which is something that must change." At some time in the future. I'm working on a project that uses 0.20.5, batik 1.6 and, now, the fop and batik trunk code. It looks as though I may have to unwind the batik trunk code. It seems to me that the builds of the three trees must at least utilise common build file import elements. Building fop is going to depend upon the availability of particular trunk snapshots of commons and batik. Otherwise, how do you co-ordinate development on the batik and fop and commons trunks? There are users who want release versions only, and there are users who are building from the trunk, including, but not restricted to, the developers. For the latter users, the build process must be able to determine whether the tree of primary focus has access to compatible source trees or jars for the other trees. That seems to imply that each tree maintains a range of compatible versions. Changing fop, say, may then mean updating the build files for commons and batik to reflect the fact that dependencies somewhere have just changed. That, in turn, seems to imply that the build files for all trees are maintained in commons. Peter
