Page History

...

The idea now is to create a common area where the parts of common interest between the two subprojects are jointly developed and maintained. XML Graphics Commons will deliver a set of well-defined libraries of which some might provide some supporting tools (such as the TTFReader and the PFMReader, but which will eventually vanish when they are not needed anymore). Other potentially reusable software like utilities for build support, ant tasks, plugins for IDEs, test frameworks and data files might also qualify for finding a home in XML Graphics Commons.

Benefits

• Clear dependencies
• More structured codebase
• Easier for newbies to contribute to certain parts (They are afraid now of the big blob of code)
• New (and now easily visible) use cases for certain components (examples: JPS services to allow Java applications to print to PDF and PS through Printables, PDF lib can be used independetly of FOP, etc.)
• Faciliating collaboration with "competing" projects like FOray and DefoeFolio, i.e. work together on undisputed parts of an XSL-FO processor.
  

The plan

...

Common repository

For the joint operations we need a common repository. Since we are supposed to move now have migrated both subprojects to Subversion sooner or later we may just as well go for Subversion for the common repository, especially now that we've already got an SVN repo for the XML Graphics site.

Decisions: Batik and FOP will soon migrate to SVN which will make the reorganization easier and preserves the full history.

we are in a good starting position for this.

Parts affected in FOP

directly:

...

• PDF library (org.apache.fop.pdf, by PDF transcoder)
• PS generation code (org.apache.fop.ps, by PS transcoder)
• font support (org.apache.fop.fonts, by PDF lib, PDF and PS transcoders)

• Wiki Markup
  IO helpers (org.apache.fop.util, by PDF and PS transcoders) \[1\]

• Image adapters (org.apache.fop.image, by PDF and PS transcoders)
• Basic FOP exceptions (org.apache.fop.apps)
• RTF library (org.apache.fop.render.rtf.rtflib, based on user feedback, generally usable)
  

_\[1\] Some of these classes could be candidates to go into Jakarta Commons IO._

External dependencies:

• Wiki Markup
  Avalon Framework (for the configuration subpackage only) \[2\]

• Wiki Markup
  Jakarta Commons Logging \[3\]

• Jakarta Commons IO
  

\[2\] There's enough opposition here that warrants a reevaluation. We'll try to do without this.

\[3\] During the move it should be tried to remove this dependency, i.e. no logging at all in the basic shared components.

Parts affected in Batik

The transcoders depend on several packages inside Batik. Obviously, we can't create a clean hierarchy without dependencies on Batik, at least for the PDF and PS transcoders. But we should do that for the parts where this is possible (PDF lib, fonts, images etc.).

...

• ParsedURL (org.apache.batik.util, could be used by FOP, too. Benefits: RFC2397 data: URLs, automatic gzip decompression (SVGZ))
• image codecs (org.apache.batik.ext.awt.image.codec)
• Base64 encoder and decoder (org.apache.batik.util)
• SVGGraphics2D
• ...
  

Organization and naming

Naming the individual parts

...

(axgc = Apache XML Graphics Commons)

• xmlgraphics-commons-pdf (PDF library)
• xmlgraphics-commons-ps (PostScript generation and manipulation/post-processing code)
• xmlgraphics-commons-fonts (Font library)
• xmlgraphics-commons-codecs (Image codecs)
• xmlgraphics-commons-image-adapter (Image library adapters and analyzers)
• xmlgraphics-commons-utils (IO classes, Exception classes, ParsedURL)
• xmlgraphics-commons-java2d (Graphics2D implementation for PDF and PS, base for the Transcoders)
• xmlgraphics-commons-rtf (RTF library)
  

...

Layout in SVN

Proposal 1: (discarded)

http://svn.apache.org/repos/asf/xmlgraphics
  +-- commons
        +-- branches
        +-- tags
        +-- trunk
             +-- axgc-codecssrc
             +-- axgc-fonts
             +-- axgc-image-adapters
             +-- axgc-pdf
 java (all shared components under this directory)
            +-- axgc-ps
             +-- axgc-utilsorg.apache.xmlgraphics
  +-- batik
        +-- branches
        +-- tags
        +-- trunk
  +-- batik-transcoderscodecs
        +-- branches
        +-- tags
        +-- trunk
  +-- fopfonts
        +-- branches
        +-- tags
        +-- trunk
  +-- site

Notes:

• this layout has the effect that we have four major products (batik, batik-transcoders, fop and axgc), where axgc may have additional (sub-)products for each individual components (if necessary).
• batik and batik-transcoders will always be released (tagged) at the same time but they have different committer sets.
• axgc builds each component individually (axgc-pdf.jar, axgc-util.jar etc.), as well as a collective (axgc.jar). If the individual components are released or only the collective remains TBD.
• All releases are always coordinated on the project level (i.e. on level Apache XML Graphics).
  

Proposal 2: (amended by 2a)

http://svn.apache.org/repos/asf/xmlgraphics
  +-- commons
image-adapters
           +-- branches
        +-- tags
        +-- trunk
java2d (Graphics2D implementations,           +-- axgc-codecsgradient/(pattern) extensions)
             +-- axgc-fonts
             +-- axgc-image-adapters
             +-- axgc-pdf
 (PDF implementation)
           +-- axgc-ps
             +-- axgc-utils
  +-- batik
        +-- branches
ps        +-- tags
    (PS implementation)
    +-- trunk
  +-- fop
        +-- branches
        +-- tags
        +-- trunk
svg  +-- site

Notes:

• In this scenario, the PDF and PS transcoders are transferred to the Batik subproject under their repository.
• There are some from the FOP team who want to continue maintaining these parts so they need write access, thus they will need to be made Batik committers.
• this layout has the effect that we have three major products (batik, fop and axgc), where axgc may have additional (sub-)products for each individual components (if necessary).
• axgc builds each component individually (axgc-pdf.jar, axgc-util.jar etc.), as well as a collective (axgc.jar). If the individual components are released or only the collective remains TBD.
• All releases are always coordinated on the project level (i.e. on level Apache XML Graphics).
• This scenario is simpler than proposal 1 (fewer places to look for code), but the FOP team has less control over the code which makes up in important feature of FOP.
  

Proposal 2a:

2a amends proposal 2 with the following items:

• Basic Graphics2D implementations and supporting code (pattern classes) go into Commons (Batik only gets the Transcoders)
• Name change: JARs are called xmlgraphics-commons(-<part>).jar
  

http://svn.apache.org/repos/asf/xmlgraphics
  +-- commons
(SVG implementation)
           +-- branches
        +-- tags
        +-- trunkpdf
             +--  codecs
             +-- fontsps
             +-- image-adapters
               +-- java2d (Graphics2D implementations, Pattern extensions)
         rtf
         +-- pdf (PDF implementation)
                  +-- ps (PS implementation)
         utils
    +-- pdf
             +-- ps
             +-- utilsjava-1.4 (all JDK 1.4 dependant code under this directory)
  +-- batik
        +-- branches
        +-- tags
        +-- trunk
  +-- fop
        +-- branches
        +-- tags
        +-- trunk
  +-- site

Notes:

• In this scenario, the PDF and PS transcoders are transferred to the Batik subproject under their repository.
• Basic Graphics2D implementations and supporting code (gradient/(pattern) classes) go into Commons (Batik only gets the Transcoders)
• this layout has the effect that we have three major products (batik, fop and xmlgraphics-commons), where axgc may have additional (sub-)products for each individual components (if necessary).
• axgc builds some components individually (xmlgraphics-commons-pdf.jar, xmlgraphics-commons-utils.jar etc.), as well as a collective (xmlgraphics-commons.jar). A release is only done as a collective for the whole of XML Graphics Commons.
• All releases are always coordinated on the project level (i.e. on level Apache XML Graphics).
  

Notes on additional use cases for the separated components

• PDFDocumentGraphics2D and PSDocumentGraphics2D can be used to create streamed print services for JPS which would allow arbitrary Java applications to create PDF and PostScript by simply printing to JPS.
• The PDF library could be used to create PDF documents from scratch (iText is probably better suited for that).
• The PDF library could be extended to modify existing documents (same comment as above)
• The PS library code could be extended to support PostScript post-processing.
• The RTF library is reported to be used separately. There is desire for a separate JAR with only the RTF generation code.
  

work items

...

closed

• Move Batik and FOP to Subversion. (Will be done after the imminent Batik release. Vote passed.)
• Complete and discuss this plan.
  

open

• Vote on the plan.
• Clean up dependencies.
• Create basic exception classes so the dependency on org.apache.fop.apps disappears.
• Create common repository.
• Move affected parts (see above) over to their new location.
• Create build system for all components. (TBD: one for all or one for each?)
• Documentation for the new parts.