Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1. put org.mozilla.xpcom into your eclipse plugins directory (http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/org.mozilla.xpcom_1.8.1.3-20070320.jar) 2. Create a new plugin, lets call it X 3. Add org.mozilla.xpcom to this plugin X 4. Import of org.mozilla.* should now be possible but it is not 5. Go and import the org.mozilla.xpcom as a binary project (via the plugins view) 6. Now classes found in org.mozilla.xpcom can be used. Why can't PDE pick up the classes ? More information:
Could this be linked to the use of : DynamicImport-Package: org.mozilla.xpcom in http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt/META-INF/MANIFEST.MF?revision=1.31&view=markup ?
Tom, this is working as designed, right?
When you drop it into the plugins directory, are you doing a restart? Also note that if you change the target platform then you need to do a 'refresh' as otherwise PDE doesn't pick up on the changes. I wonder if that's what is happening here. Alex.
This is happenning because org.mozilla.xpcom has an inner jar MozillaInterfaces.jar which contains the org.mozilla.* packages. When this bundle is a jar'ed bundle in your target PDE (or JDT) cannot handle the inner jar for classpaths. There is a JDT or PDE bug already open about this. This bug should be dup'ed to that bug.
sorry to have bothered you, Tom. The Dynamic-ImportPackage reference in comment 1 was a red herring. *** This bug has been marked as a duplicate of bug 135012 ***
Why is this jar different than any other nested jar ? e.g. I have many plugins that have nested jars in it to have access to e.g. hibernate, log4j, etc.
Do you export packages from the nested jars? The issue is PDE/JDT does not handle placing inner jars from jar'ed bundles onto the classpath of clients trying to use Import-Package or Require-Bundle to access the classes. Notice that in the eclipse sdk the bundles which have nested jars are shipped as "directory" bundles. This is to work around this tooling bug. If your bundle only uses the classes from the inner jar (ummm) internally (i.e. does not specify Export-Package for any of its content) then it is fine for the bundle to be jar'ed. This is because clients should never have access to the inner jar. Once you try to expose the inner jar to clients for compilation purposes then your bundle will have to be a "directory" or "exploded" bundle instead of a jar'ed bundle to work around this tooling bug.
yes in my own bundles i simply include the jar on bundle-classpath and export the packages. Just like e.g. org.apache.ant does it. I guess xpcom should do the same and it would work?
re comment 7... This is not a tooling "bug". AFAIK there are no java compilers that will go into nested JARs to discover classes. Yes, JDT/PDE could work around this limitation and extract the nested JARs etc. Contributions for this caching infrastructure would likely be welcomed. > If your bundle only uses the classes from the inner jar (ummm) internally > (i.e. does not specify Export-Package for any of its content) then it is fine > for the bundle to be jar'ed. That is not entierly true. Say there is a class A in the exported packages and some class B in some internal JAR. If A subclasses B then someone referencing A (e.g., to extend it) will have to see B at compile time.
I'm confused, if this is not a bug why does the bundle work at runtime ? Why is every other kind of nested jar fully functional ? What is special about this xpcom bundle (except that it doesn't export packages, but that would still not be enough for a compiler to read it) ?
(In reply to comment #10) > I'm confused, if this is not a bug why does the bundle work at runtime ? Let me clarify comment 7. I'm stating this is definitely *not* a runtime bug. The tooling does not know how to handle inner jars, which are jar'ed in another jar, for compilation purposes. As Jeff points out this is true for any build system that we know of JDT, javac, maven, ant etc. Call it a tooling bug or a restriction, I think the end user does not care. > > Why is every other kind of nested jar fully functional ? > > What is special about this xpcom bundle (except that it doesn't export > packages, but that would still not be enough for a compiler to read it) ? > Actually, it is the opposite. The xpcom bundle *is* exporting packages from the inner jar, which is jar'ed in another jar. Currently the build tools do not know how to use inner jars packaged in another jar for compilation. Therefore the packages exported by the xpcom bundle cannot be found at compilation time.
aaah...so if one would unzip it then it is expected to work ? (in other words unpack="true" in feature.xml is relevant)
ok - this is solved and it's just me being blind. unzip the plugin into a directory with the same name (sans .jar) and it work (as expected). I just (again) got caught by the fact that an updatesite .jar is zipped and then in feature.xml it is stated if it should be unpacked or not...
(In reply to comment #12) > aaah...so if one would unzip it then it is expected to work ? > > (in other words unpack="true" in feature.xml is relevant) > Yup, this is currently what others do in the same situation. Although a better alternative is to insert the bundle manifest directly into the MozillaInterfaces.jar and use it directly as a bundle instead of packaging it into another bundle as a inner jar. This is what the orbit project does for most of the 3rd party code used in eclipse. See: http://wiki.eclipse.org/Adding_Bundles_to_Orbit#Adding_a_library_for_the_first_time
