You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Peter West <pe...@hp.com> on 2006/04/13 14:58:04 UTC
Re: Release coordination in XML Graphics (was: [VOTE] Release
Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote:
> 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.
>
Ok, but I'm hazy about the pathways here. What *is* the pathway for svg
rendering to, say, pdf in fop?
> 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.
>
Optionally?
> 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).
Same problem here. It may come to that if I need the Graphics2D some
time soon.
>
> 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 work with NetBeans; i.e. a thin veneer over the build files. I think
of the build files as canonical.
If I understand you correctly, Batik's dependency on FOP is addressed by
moving the transcoders holus-bolus into Batik. Meanwhile, all of the PDF
and PS rendering (upon which the transcoders depend), and the font
configuration, goes into Commons. That leaves both Batik and FOP
dependent on Commons. The Graphics2D implementations also go to Commons,
where any dependencies of either FOP or Batik on them are resolved.
What use does Batik make of the Graphics2D implementations? I thought
they were created for Batik.
Both Batik and FOP will still have the dependencies on Commons, whether
Batik depends on the Graphics2D implementations or not. That means that
changes to Commons have the potential to break both FOP and Batik trunk
builds. For those builds on both sides, then, there will need to be
Commons versioning information.
> I suggest we move this whole coordination issue over to the
> general@xmlgraphics 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 general@xmlgraphics.apache.org.
> > >
> > > > 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
---------------------------------------------------------------------
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: Graphics2D implementations (was: Release coordination in XML Graphics)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 13.04.2006 17:11:37 Peter West wrote:
> On Thu, 2006-04-13 at 16:37 +0200, Jeremias Maerki wrote:
> > On 13.04.2006 16:19:08 Peter West wrote:
> > <snip/>
> > > > The Transcoders use the Graphics2D implementations to render the basic
> > > > graphic elements. Special elements like links, text and more can
> > > > optionally handled using special "bridge" classes (SVG/Batik-specific).
> > > >
> > > Text which uses either the base14 or embedded fonts seems to be
> > > rendering without invoking the bridge classes. In general, text should
> > > be able to be rendered through Graphics2D. For the base14 fonts, some
> > > extra work is required, but for fonts which are being embedded, the
> > > bridge should not be required, should it? In fact, for base14, it is
> > > only the co-ordination with the font configuration that's required,
> > > isn't it?
> >
> > Not quite. All text from Batik is normally painted by internally
> > converting it to shapes. This is done using the fonts that are available
> > to the Java2D subsystem and has nothing to do with font configuration
> > provided by FOP.
> >
> > Only when we register a bridge class for text painting can we select
> > simple-enough text elements that we can paint using native operators.
> > Only in this case will base 14 fonts (or configured fonts - the
> > PDFTextPainter doesn't really care) be used. That's when our own font
> > system kicks in.
> >
>
> Let's back up a step. That's text from Batik.
Right. Should have said that.
> But is Batik needed to render text in a PDFGraphics2D?
No, it shouldn't be like that. See below.
> Can FOP render text as well as graphics without involving Batik?
Yes, actually I forgot a little detail before: PDFGraphics2D implements
the two drawString() variants and uses native text commands there. These
methods are never called by Batik, but other applications might use them.
This is actually one of the reasons I factored out the TextHandler
interface in the PSGrahics2D in Commons. So that I didn't take the font
subsystem dependecy over, yet. Especially, since FOrayFont will
come into play at some point. Factoring out text painting makes the
transition easier while still keeping all doors open and it concentrates
all text handling in a shorter class.
The PDFTextPainter currently simply delegate the actual text painting to
the drawString() methods, while PSTextPainter now uses the TextHandler
interface (which doesn't exist for PDF, yet).
There's certainly room for improvement in this area and it is all
work-in-progress but for most purposes everything works fine ATM.
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: Graphics2D implementations (was: Release coordination in XML
Graphics)
Posted by Peter West <pe...@hp.com>.
On Thu, 2006-04-13 at 16:37 +0200, Jeremias Maerki wrote:
> On 13.04.2006 16:19:08 Peter West wrote:
> <snip/>
> > > The Transcoders use the Graphics2D implementations to render the basic
> > > graphic elements. Special elements like links, text and more can
> > > optionally handled using special "bridge" classes (SVG/Batik-specific).
> > >
> > Text which uses either the base14 or embedded fonts seems to be
> > rendering without invoking the bridge classes. In general, text should
> > be able to be rendered through Graphics2D. For the base14 fonts, some
> > extra work is required, but for fonts which are being embedded, the
> > bridge should not be required, should it? In fact, for base14, it is
> > only the co-ordination with the font configuration that's required,
> > isn't it?
>
> Not quite. All text from Batik is normally painted by internally
> converting it to shapes. This is done using the fonts that are available
> to the Java2D subsystem and has nothing to do with font configuration
> provided by FOP.
>
> Only when we register a bridge class for text painting can we select
> simple-enough text elements that we can paint using native operators.
> Only in this case will base 14 fonts (or configured fonts - the
> PDFTextPainter doesn't really care) be used. That's when our own font
> system kicks in.
>
Let's back up a step. That's text from Batik. But is Batik needed to
render text in a PDFGraphics2D? Can FOP render text as well as graphics
without involving Batik?
Peter
---------------------------------------------------------------------
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: Graphics2D implementations (was: Release coordination in XML Graphics)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 13.04.2006 16:19:08 Peter West wrote:
<snip/>
> > The Transcoders use the Graphics2D implementations to render the basic
> > graphic elements. Special elements like links, text and more can
> > optionally handled using special "bridge" classes (SVG/Batik-specific).
> >
> Text which uses either the base14 or embedded fonts seems to be
> rendering without invoking the bridge classes. In general, text should
> be able to be rendered through Graphics2D. For the base14 fonts, some
> extra work is required, but for fonts which are being embedded, the
> bridge should not be required, should it? In fact, for base14, it is
> only the co-ordination with the font configuration that's required,
> isn't it?
Not quite. All text from Batik is normally painted by internally
converting it to shapes. This is done using the fonts that are available
to the Java2D subsystem and has nothing to do with font configuration
provided by FOP.
Only when we register a bridge class for text painting can we select
simple-enough text elements that we can paint using native operators.
Only in this case will base 14 fonts (or configured fonts - the
PDFTextPainter doesn't really care) be used. That's when our own font
system kicks in.
<snip/>
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: Release coordination in XML Graphics (was: [VOTE] Release
Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
Posted by Peter West <pe...@hp.com>.
On Thu, 2006-04-13 at 15:25 +0200, Jeremias Maerki wrote:
> On 13.04.2006 14:58:04 Peter West wrote:
> > On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote:
> > > 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.
> > >
> > Ok, but I'm hazy about the pathways here. What *is* the pathway for svg
> > rendering to, say, pdf in fop?
>
> FOP's PDFSVGHandler:
> - sets up the SVG document
> - configures the Batik-specific bridges which are used to generate
> elements that should be handled in a more specific way than is possible
> with Graphics2D (links for examples)
> - Creates a PDFGraphics2D instance that is given as paint target to
> Batik.
> - Batik is invokes to render the SVG document
>
> Painting a barcode using Barcode4J is just slightly different but helps
> understanding the issues here:
> - The barcode extension requests a Graphics2D instance from the Renderer
> to paint on (This is just another PDFGraphics2D)
> - Barcode4J paints against the Graphics2D instance
> (no Batik-specific elements involved here)
>
> >
> > > 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.
> > >
> > Optionally?
>
> That's a personal wish. IMO, the Batik dependency should evolve into an
> optional dependency (like the MathML and Barcode extensions). I can
> remember some people asking if it is possible to scale down FOP by
> removing SVG support. My main goal is to compile FOP using IKVM into a
> .NET DLL where Batik might be a problem as the Java2D support in IKVM is
> not as advanced as it could be, yet. On the other side, making Batik an
> optional dependency (as opposed to mandatory) simply enforces cleaner
> design.
>
> > > 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).
> >
> > Same problem here. It may come to that if I need the Graphics2D some
> > time soon.
> >
> > >
> > > 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 work with NetBeans; i.e. a thin veneer over the build files. I think
> > of the build files as canonical.
> >
> > If I understand you correctly, Batik's dependency on FOP is addressed by
> > moving the transcoders holus-bolus into Batik.
>
> Yes.
>
> > Meanwhile, all of the PDF
> > and PS rendering (upon which the transcoders depend), and the font
> > configuration, goes into Commons. That leaves both Batik and FOP
> > dependent on Commons. The Graphics2D implementations also go to Commons,
> > where any dependencies of either FOP or Batik on them are resolved.
>
> Exactly.
>
> > What use does Batik make of the Graphics2D implementations? I thought
> > they were created for Batik.
>
> Not exclusively. Originally they were simply created to provide SVG
> support to PDF output in FOP.
>
That's where I had it wrong. The pathway for the barcodes makes that
clear.
> The Transcoders use the Graphics2D implementations to render the basic
> graphic elements. Special elements like links, text and more can
> optionally handled using special "bridge" classes (SVG/Batik-specific).
>
Text which uses either the base14 or embedded fonts seems to be
rendering without invoking the bridge classes. In general, text should
be able to be rendered through Graphics2D. For the base14 fonts, some
extra work is required, but for fonts which are being embedded, the
bridge should not be required, should it? In fact, for base14, it is
only the co-ordination with the font configuration that's required,
isn't it?
> FOP can use the Graphics2D implementations without the Batik
> specialities to render things like MathML, barcodes, charts or whatever.
>
> Furthermore, the Graphics2D implementations (or more specifically the
> Document*Graphics2D subclasses) can be used to create stand-alone PDF
> and EPS documents by simply painting to a Graphics2D instance. See:
> http://svn.apache.org/viewcvs.cgi/xmlgraphics/commons/trunk/examples/java/java2d/ps/EPSExample1.java?view=markup
>
> Folio could use this approach for PDF production. You've decided to go
> the Java2D route, right? Another example: I've done a small proof-of-concept
> implementation of a JPS (Java Printing System) backend to produce PDF.
> This enables any Java application printing using JPS to produce PDF
> files. Cool, ey? :-)
Peter
---------------------------------------------------------------------
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: Release coordination in XML Graphics (was: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
Posted by Manuel Mall <ma...@apache.org>.
On Thursday 13 April 2006 21:25, Jeremias Maerki wrote:
> On 13.04.2006 14:58:04 Peter West wrote:
> > On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote:
<snip/>
> > That means that
> > changes to Commons have the potential to break both FOP and Batik
> > trunk builds. For those builds on both sides, then, there will need
> > to be Commons versioning information.
>
> That's true. As soon as both projects use Commons, we will have to
> be careful about changes. If we really need some kind of versioning
> info remains to be seen. One tool that helps us here is Gump. I
> wonder what the others think.
>
Not sure I really understand what the problem is or if the problem is
any different to any other project that publishes an API. Once you have
published an API (a contract) and you have customers using that API one
must be very careful about backwards compatibility and changes to the
contract. Any published API "suffers" from that constraint and nothing
special here about xmlgraphics-commons.
So the decision if it is worth the "pain" of having to maintain a
published API vs the gain in re-useability and loss of duplication by
having a commons project was resolved when the PMC voted in favour of
establishing this project.
Regarding versioning, IMO, every published JAR should contain sensible
versioning information. Regarding version dependency management outside
of formal releases yes that is an issue especially if one assumes that
there is a tight coupling between FOP and Commons development, e.g. FOP
trunk may require a non release (but non trunk) version of Commons to
work. That could possibly be handled by tagging the appropriate version
in Commons SVN (have a "floating" FOP Trunk label on the Commons SVN
tree identifying the Commons version currently recommended to be used
with FOP trunk).
> >
> > Peter
>
> Jeremias Maerki
>
Manuel
---------------------------------------------------------------------
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: Release coordination in XML Graphics (was: [VOTE] Release Apache XML Graphics Commons 1.0 and Apache FOP 0.92beta)
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 13.04.2006 14:58:04 Peter West wrote:
> On Thu, 2006-04-13 at 12:11 +0200, Jeremias Maerki wrote:
> > 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.
> >
> Ok, but I'm hazy about the pathways here. What *is* the pathway for svg
> rendering to, say, pdf in fop?
FOP's PDFSVGHandler:
- sets up the SVG document
- configures the Batik-specific bridges which are used to generate
elements that should be handled in a more specific way than is possible
with Graphics2D (links for examples)
- Creates a PDFGraphics2D instance that is given as paint target to
Batik.
- Batik is invokes to render the SVG document
Painting a barcode using Barcode4J is just slightly different but helps
understanding the issues here:
- The barcode extension requests a Graphics2D instance from the Renderer
to paint on (This is just another PDFGraphics2D)
- Barcode4J paints against the Graphics2D instance
(no Batik-specific elements involved here)
>
> > 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.
> >
> Optionally?
That's a personal wish. IMO, the Batik dependency should evolve into an
optional dependency (like the MathML and Barcode extensions). I can
remember some people asking if it is possible to scale down FOP by
removing SVG support. My main goal is to compile FOP using IKVM into a
.NET DLL where Batik might be a problem as the Java2D support in IKVM is
not as advanced as it could be, yet. On the other side, making Batik an
optional dependency (as opposed to mandatory) simply enforces cleaner
design.
> > 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).
>
> Same problem here. It may come to that if I need the Graphics2D some
> time soon.
>
> >
> > 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 work with NetBeans; i.e. a thin veneer over the build files. I think
> of the build files as canonical.
>
> If I understand you correctly, Batik's dependency on FOP is addressed by
> moving the transcoders holus-bolus into Batik.
Yes.
> Meanwhile, all of the PDF
> and PS rendering (upon which the transcoders depend), and the font
> configuration, goes into Commons. That leaves both Batik and FOP
> dependent on Commons. The Graphics2D implementations also go to Commons,
> where any dependencies of either FOP or Batik on them are resolved.
Exactly.
> What use does Batik make of the Graphics2D implementations? I thought
> they were created for Batik.
Not exclusively. Originally they were simply created to provide SVG
support to PDF output in FOP.
The Transcoders use the Graphics2D implementations to render the basic
graphic elements. Special elements like links, text and more can
optionally handled using special "bridge" classes (SVG/Batik-specific).
FOP can use the Graphics2D implementations without the Batik
specialities to render things like MathML, barcodes, charts or whatever.
Furthermore, the Graphics2D implementations (or more specifically the
Document*Graphics2D subclasses) can be used to create stand-alone PDF
and EPS documents by simply painting to a Graphics2D instance. See:
http://svn.apache.org/viewcvs.cgi/xmlgraphics/commons/trunk/examples/java/java2d/ps/EPSExample1.java?view=markup
Folio could use this approach for PDF production. You've decided to go
the Java2D route, right? Another example: I've done a small proof-of-concept
implementation of a JPS (Java Printing System) backend to produce PDF.
This enables any Java application printing using JPS to produce PDF
files. Cool, ey? :-)
> Both Batik and FOP will still have the dependencies on Commons, whether
> Batik depends on the Graphics2D implementations or not.
It will.
> That means that
> changes to Commons have the potential to break both FOP and Batik trunk
> builds. For those builds on both sides, then, there will need to be
> Commons versioning information.
That's true. As soon as both projects use Commons, we will have to
be careful about changes. If we really need some kind of versioning info
remains to be seen. One tool that helps us here is Gump. I wonder what
the others think.
> > I suggest we move this whole coordination issue over to the
> > general@xmlgraphics 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 general@xmlgraphics.apache.org.
> > > >
> > > > > 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
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