Ok, I think I'm beginning to see the problem. Looking at the Commons
plan on the wiki it uses the term transcoder. That's not good. We're
planning to move to the PDF and PS/EPS transcoders to Batik, not to
Commons (mentioned in parantheses on the wiki page). Only the basic
Graphics2D implementations will go to Commons. That will give Batik
committers write access and full control over the Transcoders. FOP is
not interested in the Transcoders, but it is interested in the
Graphics2D implementations for handling extensions like SVG, MathML,
Barcode4J etc.
The dependency tree at the end of the migration process will look like
this:
- Commons depends on a minimal set of external libraries (probably only
Jakarta Commons IO and JAXP)
- Batik depends only on Commons, not on FOP.
- FOP depends on Commons and only optionally on Batik for SVG
functionality.
That should eliminate most dependency problems we suffer from today. The
rest is mostly talking to each other.
The big problem with this whole problem is resources. I'm doing my part
in this on my own time which is limited. I don't think the Batik
committers have lots of free time to move on quickly here. So, if you
want to help unwinding the whole thing, you're most welcome. You're
still a committer in FOP (and therefore in Commons) and you can always
request write access to the repository (yours got removed during the
switch to SVN).
Concerning your comments on the build files: I usually work with SVN
checkouts in Eclipse (FOP referencing the Batik project and not the JAR
file in the lib directory, and not using Ant to build inside the IDE).
Compatibility is verified by updating the JARs in the lib directory and
using the Ant builds from the command-line. I'm happy that way. But
that's just how I do it.
I suggest we move this whole coordination issue over to the
[EMAIL PROTECTED] mailing list. This discussion is not FOP-specific.
On 13.04.2006 11:38:27 Peter West wrote:
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
