Community
Participate
Working Groups
The org.apache.batik.pdf bundle exports a number of unexpected packages: org.apache.commons.io, org.apache.commons.io.output, org.apache.commons.logging, org.apache.commons.logging.impl Since the package does not contain all classes that are part of the org.apache.commons.io library this causes this exception in the Mylyn Gerrit connector: java.lang.NoClassDefFoundError: org/apache/commons/io/FilenameUtils at org.eclipse.mylyn.internal.reviews.ui.operations.ReviewCompareEditorInput$ByteArrayInput.getType(ReviewCompareEditorInput.java:67) at org.eclipse.compare.internal.CompareUIPlugin.getTypes(CompareUIPlugin.java:985) [..] The Gerrit connector that has a package import in its manifest: Import-Package: org.apache.commons.io osgi> packages org.apache.commons.io org.apache.commons.io; version="0.0.0"<org.apache.batik.pdf_1.6.0.v201011041432 [218]> org.eclipse.gmf.runtime.draw2d.ui.render.awt_1.4.1.v20101119-2230 [321] imports org.eclipse.mylyn.gerrit.ui_0.7.0.I20110202-0132 [463] imports Can the org.apache.commons.* package exports be removed from org.apache.batik.pdf?
I'd send an email to orbit-dev too. Who owns this?
Anthony, do you have any thoughts on this?
(In reply to comment #0) > The org.apache.batik.pdf bundle exports a number of unexpected packages: > > org.apache.commons.io, > org.apache.commons.io.output, > org.apache.commons.logging, > org.apache.commons.logging.impl > > Since the package does not contain all classes that are part of the > org.apache.commons.io library this causes this exception in the Mylyn Gerrit > connector: Huge ouch. I assume this is the org.apache.batik.pdf version 1.6.0 bundle? As far as I can recall, the Batik SVG toolkit as it comes from apache includes some "other" apache common code. In Batik 1.7 in orbit we tried to not repackage these common libraries, but that does not help you with Batik 1.6. Unfortunately, I am not sure what the answer is. These batik 1.6 bundles have worked well for 5 years and modifying them is not going to work. What we should be doing is moving to Batik 1.7, but that effort has been a failure thus far since Batik 1.7 has API breakages.
The org.eclipse.birt.chart_2.6.1.v20100709-7f9T7DFQCnv8nz0gRMa6NG1 feature seems to include org.apache.batik 1.6. I have the following plug-ins on disk: org.apache.batik.bridge_1.6.0.v201011041432.jar org.apache.batik.pdf_1.6.0.v201011041432.jar org.apache.batik.css_1.6.0.v201011041432.jar org.apache.batik.svggen_1.6.0.v201011041432.jar org.apache.batik.dom_1.6.0.v201011041432.jar org.apache.batik.transcoder_1.6.0.v201011041432.jar org.apache.batik.dom.svg_1.6.0.v201011041432.jar org.apache.batik.util_1.6.0.v201011041432.jar org.apache.batik.ext.awt_1.6.0.v201011041432.jar org.apache.batik.util.gui_1.6.0.v201011041432.jar org.apache.batik.parser_1.6.0.v201011041432.jar org.apache.batik.xml_1.6.0.v201011041432.jar Looking at Birt 4.0 they still include that same version of Batik. Xiaoying, any plans to move to 1.7?
There are no plans to adopt Batik 1.7 in Indigo by Eclipse Modeling (GMF). We need to stick on Batik 1.6.
> > ... These batik 1.6 bundles have > worked well for 5 years and modifying them is not going to work. > Why not? If it is wrong the way it is, and we are breaking other, new participants, something has to be done. Perhaps this case would be helped by importing what's exported (for these known, troublesome packages). See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html This scheme allows packages/classes to "pass through" a bundle, if provided by someone else. (depending on load order, etc.) Steffen, can you test that "locally" to see if it helps? Other suggestions welcome.
Dupping to 344560 as it appears it has a practical solution in comments. *** This bug has been marked as a duplicate of bug 344560 ***
