Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation

[Erich Schubert]

Hello Mathieu,
The annoying part is that even the Batik documentation still contains
the old package name:
https://xmlgraphics.apache.org/batik/using/dom-api.html

It is well possible that many of the dependencies do not use this
class. I'm not sure if there might be indirect dependencies that rely
on one of these direct dependencies to pull in Batik... they could
still use that class; although many will not build a SVG document on
their own. Loading a document from a file should not be a problem, I
believe this class is only needed to be able to manipulate the SVG
documents e.g. for animation and interaction.

According to
find -type f -name *.jar -print | while read l; do unzip -c $l |
grep -q SVGDOMImplementation  echo $l; done
the only packages I have installed that use this class are Batik, FOP and ELKI.
It may well be that the other reverse dependencies do not use this class.
Scilab for example seems to use GenericDOMImplementation, which was
not moved to a different package.

I suggest to add these for the unstable upload:
Breaks: elki (= 0.6.5)
Breaks: libfop-java ( 2.0)
+ add a notice to the README that the class has moved, since this is
not well documented.

I will take care of uploading a new ELKI package (probably end of the
month, or beginning of september).
It will have a version number of at least 0.7.0~20150817-1, which is
 0.6.5, so above breaks is okay.
I assume that libfop-java 1:2.0+dfsg-1 in experimental is expecting
the new Batik version.

Regards,
Erich

On Sun, Aug 16, 2015 at 1:33 PM, Mathieu Malaterre ma...@debian.org wrote:
 Erich,

 Thanks for the report about batik API compat. Could you be a little more
 verbose on what was needed to fix ELKI ? I see that that

 import org.apache.batik.dom.svg.SVGDOMImplementation;

 is still used in the ELKI (from sid).

 I am trying to understand if this is possible to upload 1.8 to sid with a
 debian-specific fix, then progressively upgrade dependencies to match
 upstream (removing reference to SVGDOMImplementation).

 Thanks much,

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation

[Mathieu Malaterre]

On Sun, Aug 16, 2015 at 1:53 PM, Erich Schubert er...@debian.org wrote:

 Hi,
 ELKI now tries to load the class dynamically, from different packages. I
 don't know if this is the proper way to get the DOM implementation, but it
 was the only one I got working.

 It is not yet fixed in the Debian package. We're in the process of
 preparing the next release.

 Maybe a simple compatibility hack would be to include two copies of the
 class, in both the old and the new location, but that bears the danger of
 people continuing to use the old location...

 I wish there was a well-documented solution.



For reference:

http://stackoverflow.com/a/30250306/136285
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#794214: org.apache.batik.dom.svg.SVGDOMImplementation

[Mathieu Malaterre]

Erich,

Thanks for the report about batik API compat. Could you be a little more
verbose on what was needed to fix ELKI ? I see that that

import org.apache.batik.dom.svg.SVGDOMImplementation;

is still used in the ELKI (from sid).

I am trying to understand if this is possible to upload 1.8 to sid with a
debian-specific fix, then progressively upgrade dependencies to match
upstream (removing reference to SVGDOMImplementation).

Thanks much,
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.