Bug 44573

Indeed, that dependency graph is out of date and needs to be updated.  At the very least, the docs should be updated to point this out.

(In reply to comment #1)
> Indeed, that dependency graph is out of date and needs to be updated.

I read through the mailing lists [1] [2] and took a look at the Jar list and, as of revision 755596, here is a list of missing dependencies and a partial proposal:
 * batik-bridge.jar --> batik-anim.jar;
 * batik-anim.jar --> batik-svg-dom.jar;
 * batik-codec.jar --> ??? [1];
 * xml-apis.jar --> xalan-2.6.0.jar;
 * xalan-2.6.0.jar (stand-alone).

I updated the report title to reflect several Jars missing (previously only batik-codec.jar) so the several missing Jar files becomes a single action.

By the way: I guess this was already asked but... How was the graphic authored? By hand or was some tool in particular used to generate it?


> At the very least, the docs should be updated to point this out.

This was already done in revision 658507 (by Cameron). However, a documentation publish operation is needed to make this effective (commit occurred 2008-03-21, while the latest online documentation dates from 2008-01-09).


[1] http://www.nabble.com/Jar-dependency-graph-td17002989.html#a17002989
[2] http://www.nabble.com/minimal-classes-needed-to-use-JSVGCanvas-in-applet-td18477825.html

(In reply to comment #2)
> I read through the mailing lists [1] [2] and took a look at the Jar list and,
> as of revision 755596, here is a list of missing dependencies and a partial
> proposal:
>  * batik-bridge.jar --> batik-anim.jar;
>  * batik-anim.jar --> batik-svg-dom.jar;
>  * batik-codec.jar --> ??? [1];
>  * xml-apis.jar --> xalan-2.6.0.jar;
>  * xalan-2.6.0.jar (stand-alone).

Thanks!  Both batik-svggen.jar and batik-transcoder.jar depend on batik-codec.jar implicitly through the SPI.  batik-codec.jar doesn't depend on anything, I believe.

> I updated the report title to reflect several Jars missing (previously only
> batik-codec.jar) so the several missing Jar files becomes a single action.
> 
> By the way: I guess this was already asked but... How was the graphic authored?
> By hand or was some tool in particular used to generate it?

I don't know who generated it, or whether it was generated by hand or with a tool.  In case you haven't seen it, the source is here:

  http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/documentation-sources/resources/images/jarDependImg.source.svg

It might be easier to just create a new one.

> > At the very least, the docs should be updated to point this out.
> 
> This was already done in revision 658507 (by Cameron). However, a documentation
> publish operation is needed to make this effective (commit occurred 2008-03-21,
> while the latest online documentation dates from 2008-01-09).

I just did a publish now; it should take no longer than an hour to appear on xmlgraphics.apache.org.

(In reply to comment #3)

(me)
> > How was the graphic authored?

(Cameron)
> I don't know who generated it, or whether it was generated by hand or with a
> tool.  In case you haven't seen it, the source is here:

Seems that Thomas generated it (in revision 201133). Do you recall if you used some tool for the job or if it was hand authored, Thomas?

(In reply to comment #4)
> Seems that Thomas generated it (in revision 201133). Do you recall if you used
> some tool for the job or if it was hand authored, Thomas?

As no feedback was received, I propose using Inkscape. It may be necessary creating an additional file to hold a plain SVG export from Inkscape, as I'm not sure if the rasterizer will be behave well with all the extra (and/or invalid?) attributes added by Inkscape to support editing. A few tests are required to, if possible, avoid that extra step.

Created attachment 23667 [details]
Jar dependency analysis report using JarAnalyzer 1.2

(In reply to comment #5)
> As no feedback was received, I propose using Inkscape. It may be necessary
> creating an additional file to hold a plain SVG export from Inkscape, as I'm
> not sure if the rasterizer will be behave well with all the extra (and/or
> invalid?) attributes added by Inkscape to support editing. A few tests are
> required to, if possible, avoid that extra step.

Still haven't got any spare cycles to get my hand onto this... :-|  Is anyone interested into picking this up? ;-)

Today I bumped into JarAnalyzer [1], a dependency analyzer, and ran version 1.2 against the trunk version (revision 774981) of Batik Jars. The attachment shows the raw result, although I confess I didn't spend the desired amount of time comparing the result with the previous assumptions: I intend to do this whenever I get the chance to get back to this and, in the meantime, this may be useful for anyone taking a look at this. :-)

[1] http://www.kirkk.com/main/Main/JarAnalyzer