Community
Participate
Working Groups
[I'm not sure if this is the correct place to report this; please move the report to Orbit or wherever it belongs if this isn't a BIRT bug] org.apache.batik.pdf contains classes from other Apache projects: Avalon: org/apache/avalon/framework/ commons-io: org/apache/commons/io/ commons-logging: org/apache/commons/logging/ Some of these classes are incomplete. For example, IOUtils just contains a small fraction of all available commons-io classes. My own project uses IOUtils and now I get build errors if I include BIRT via the POJO runtime. I can't solve this short of deleting those classes because I have no control over the order in my classpath when the app runs in a web container. Please don't merge several OSS projects into one. Use the proper Orbit bundles instead.
This is related to bug 344560 but I can't use that solution since I'm not consuming the bundles via OSGi. Please delete those classes from the bundle. For a quick workaround, I'd like to patch the bundle myself but I can't figure out how it is built. Is it in the orbit git repo at git://dev.eclipse.org/org.eclipse.orbit/org.eclipse.orbit.git? I switched to the v1_6 branch as per the README but the directory org.apache.batik.pdf only contains these files: ./plugin.properties ./META-INF ./META-INF/MANIFEST.MF ./about_files ./about_files/NOTICE-FOP ./about.html ./build.properties Where are the .java/.class files??
You can try to replace the orbit batik 1.6 with the original one from Apache to see if it works.
Move to Orbit project
I've done a more thorough analysis. The JAR in question (org.apache.batik.pdf_1.6.0.v201105071520.jar) contains classes from other Apache projects. It seems that it was created from the original batik-1.6-src/lib/pdf-transcoder.jar which has *some* resemblance to what you get when you compile FOP. But it's not a 1:1 copy of the classes from FOP, either. It seems someone already modified it and added the additional classes which I want to get rid of. I've attached my current solution. I don't like it, either. Would it be possible to create a new Orbit release with a version of 1.6.1 or 1.6.0-1 for this file so users can distinguish between the broken original and the new version which should include additional dependencies to commons-io and logging. Not sure about Avalon, though. Maybe the best solution would be to create a new JAR org.apache.batik.pdf.avalon to go along with the original. That way, I could cook the dependencies when I create Maven artifacts out of the Orbit bundles.
Created attachment 198949 [details] Small project which cleans the JAR Needs ant and Maven 2 or 3 in the path. To build, run "ant" To install the patched JAR in your Maven repository, run "ant install"
(In reply to comment #1) > This is related to bug 344560 but I can't use that solution since I'm not > consuming the bundles via OSGi. > Just to back up, at bit ... if you are not consuming the bundles via OSGi, why use the Orbit provided versions at all? I'm sure you have a reason, but thought I'd ask. The purpose of Orbit is to provide "third party" libraries that are tweaked specifically to be used with OSGi ... so, I am not sure we can "support" using them in a non OSGi environment ... if I understand your comment.
(In reply to comment #6) > (In reply to comment #1) > > This is related to bug 344560 but I can't use that solution since I'm not > > consuming the bundles via OSGi. > > > > if you are not consuming the bundles via OSGi, why > use the Orbit provided versions at all? I'm committer of the Dash project and working on a tool to make Eclipse bundles available for builds with Maven. In this case, I converted the BIRT bundles and tried to build a web app which runs the reports. My app already uses commons-io and I got build errors because of the classpath order (org.apache.batik.pdf comes first). I prefer to solve problems near the source. In this case, I probably won't get Batik to release a fix for 1.6, so I'm asking if Orbit can clean up the mess they created. From what I've figured out so far, a clean solution would be to delete those classes and add a dependency to the original projects which both are already in Orbit. I don't know much about how OSGi works but I hope that this solution means no change for anyone. From an API point of view, it should be safe. If you refuse, I'll create a tool which can strip classes from bundles as they are converted for Maven. This should also work but there are some drawbacks: - it doesn't solve the original problem - to allow to load the JAR, I have to strip the signatures from it - People will be confused why the JAR in Maven is different from the one in Orbit
> > I prefer to solve problems near the source. In this case, I probably won't get > Batik to release a fix for 1.6, so I'm asking if Orbit can clean up the mess > they created. > Wait, what? How did Orbit create this? I would have assumed we just "repackaged" what Batik provided. Is that not the case? And, apologies in advance, if this is all obvious to most ... but would appreciate an explanation if you are saying Orbit caused this.
Assigning to Anthony, as the primary contact.
(In reply to comment #8) > > > > I prefer to solve problems near the source. In this case, I probably won't get > > Batik to release a fix for 1.6, so I'm asking if Orbit can clean up the mess > > they created. > > > > Wait, what? How did Orbit create this? I would have assumed we just > "repackaged" what Batik provided. Is that not the case? And, apologies in > advance, if this is all obvious to most ... but would appreciate an explanation > if you are saying Orbit caused this. I think I said "Apache created a mess" but my English grammar might fail me. longer version: FOP contains some code which you can find batik-1.6/lib/pdf-transcoder.jar but I couldn't figure out how to recreate this file from the FOP sources. My guess is that someone hacked a quick "solution" by manually creating a JAR which makes all compile errors in Batik 1.6 go away.
> > I think I said "Apache created a mess" but my English grammar might fail me. > Ah, yes ... I see that now, re-reading, I read with wrong interpretation ... your grammar is good enough :) I'll let Anthony weigh in and see if there's improvements he'd feel comfortable with. (I agree, it's a mess ... but ... not sure if we in Orbit can clean up others messes ... as nice as that'd be).
Hi, What is the status of this issue? From maven world we can use the shde plugin to remove this and create a *clean* version of this jar. Moreover, I can't understand why some maven dependencies are relocated to birt-runtime, this feels so wrong to me. this means just that you will then have twice some dependencies since GAV willnot be the same. Please do NOT relocate package, this is not how maven works. I ca
I can help if you'd like to have a nice and clean maven project for birt-runtime, just let me know. Thanks, tony.
Has this ever been solved? We're running into the same issue...
I still see those classes present (in Orbit and in the maven central artifact) I guess we could rebuild this package on the orbit-recipes side (exclude the avalon, apache.commons classes), and remove the existing one.
*** Bug 388514 has been marked as a duplicate of this bug. ***
