| Summary: | NPE when exporting a bundle with 'Deployable Plug-ins and Fragments' | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Hamid Nazari <hamid.nazari.hashemi> | ||||||||||||||
| Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | P3 | CC: | frank.benoit.ext, mail, markus.kell.r, michael.jaeger, Olivier_Thomann, thomascramera, tjwatson | ||||||||||||||
| Version: | 3.10.0 Luna | ||||||||||||||||
| Target Milestone: | Luna SR1 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows 8 | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Hamid Nazari
I can reproduce the NPE and can fix, but when I fix the code to get past the NPE then I always get an error exporting because it cannot resolve the Bundle-NativeCode dependency. I then tried the same thing on Kepler and it fails with the same resolution error: Processing inclusion from feature org.eclipse.pde.container.feature: Bundle nativeCode_1.0.0.qualifier failed to resolve.: Unsatisfied native code filter: foo.dll; processor=x86; osname=win32. Can you successfully export the bundle with no resolution errors? Will look to fix the NPE for SR1, but please provide me with a simple project to reproduce and also state the expected outcome of export. I assume a successful export producing a bundle jar is expected ;-). But I cannot seem to do that even on Kepler. I added a testcase to master with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=855ffcdb61166bd8a5f81e2ac004cfc93ccc583e I fixed the NPE with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=84a00d87aa779a3d4dedca8d4ca429efecac5df9 But as I stated, this does not allow me to export the bundle successfully unless I change the target environment to be x86 instead of x86-64. I will backport the fix once I understand more about the expected results. Created attachment 244755 [details]
A simple plugin project to reproduce the exception
Created attachment 244756 [details]
The exported plugin by Kepler SR2
Created attachment 244757 [details]
A simple plugin project to reproduce the exception
Changed the manifest to contain both osname and processor attributes for each clause
Created attachment 244758 [details]
The exported plugin by Kepler SR2
I've attached a simple plugin project to reproduce the issue in Luna. The same project exports without a problem in Kepler SR2 and I've attached the exported bundle, too. Note that this bundle has an activator that will try to load the DLL inside either for x86 or x64 arch and prints a success message. About the error you mentioned getting earlier: it is true that attaching an inexact 'osname' attribute will result in an 'Unsatisfied native code filter' during export (at least up to Kepler SR2), but using a correct osname will work this around. You got this error since you used 'win32' for osname, changing it to Windows8, for example, will fix the problem. I admit that this is also a bug and is not what OSGi specs state and interestingly enough for me Equinox resolves such bundle fine! I think eclipse export must use the same logic employed by Equinox's resolver for this matter. POM version errors since http://download.eclipse.org/eclipse/downloads/drops4/N20140702-2000//pom_updates/ in bundles/org.eclipse.osgi.compatibility.state/pom.xml bundles/org.eclipse.osgi.tests/pom.xml I am not able to export new versions of my product. Do you recommend to switch back to 4.3 because this issue will take a while to get fixed? I am a little bit surprised that a function that vital is not working in a final release... (In reply to Michael Jaeger from comment #10) > I am not able to export new versions of my product. Do you recommend to > switch back to 4.3 because this issue will take a while to get fixed? I am > a little bit surprised that a function that vital is not working in a final > release... I don't have a workaround to recommend to you for 4.4. It will be fixed for 4.4 SR1 which will be released in September [1]. The eclipse/equinox project will have test builds available earlier for you to test, but an actual release with the fix will not be done before September. Once we have a fix to test it may be possible for you to patch 4.4 yourself until we have an SR1 release. [1] http://wiki.eclipse.org/Luna/Simultaneous_Release_Plan#SR1 (In reply to Hamid Nazari from comment #8) > I've attached a simple plugin project to reproduce the issue in Luna. The > same project exports without a problem in Kepler SR2 and I've attached the > exported bundle, too. Note that this bundle has an activator that will try > to load the DLL inside either for x86 or x64 arch and prints a success > message. > > About the error you mentioned getting earlier: it is true that attaching an > inexact 'osname' attribute will result in an 'Unsatisfied native code > filter' during export (at least up to Kepler SR2), but using a correct > osname will work this around. You got this error since you used 'win32' for > osname, changing it to Windows8, for example, will fix the problem. I admit > that this is also a bug and is not what OSGi specs state and interestingly > enough for me Equinox resolves such bundle fine! > > I think eclipse export must use the same logic employed by Equinox's > resolver for this matter. Thanks. I'm using Windows 7 and I cannot get this bundle to export successfully for me with 4.3.x eclipse (Kepler). It does get the expected NPE with 4.4.0 (Luna). The fix released for the Mars I-Build does fix the NPE for me, but then the bundle still fails to export for me the same as in Kepler. Could you try this out with the latest 4.5 integration build? http://download.eclipse.org/eclipse/downloads/ backported to Luna maintenance branch with commits: Test: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=0daf037d3b387b111df9761b127b1e7c079a1919 Fix: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=e4a0d3fdc8aacb47eab2634f7c5286667b75cef0 Increment version in poms: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?h=R4_4_maintenance&id=150ea3742bcf40f0010eb205819faef861327e65 Changing the Bundle-NativeCode to use Windows7 allowed me to export. I am assuming that is how you get this to work also. Closing as fixed. It does not look like this made it in time for the M-Build today but should be in next weeks for testing. Created attachment 245010 [details]
Patched plugin
I've managed to patch the original plugin with ASM based on you fix. Replacing it with the one in 'plugins' folder of my eclipse installation fixed my issue and allowed a successful export. I'll stick with this one for the time being. I'm sharing it with anyone willing to have the fix before its included in an integration build. Note that it is an unsigned JAR and use it at your own risk.
*** Bug 435407 has been marked as a duplicate of this bug. *** *** Bug 444509 has been marked as a duplicate of this bug. *** With 4.4.1, the NPE occurs for me with the OP's attached example project, modified to require Java 7 and use osname=win32 instead of osname=Windows (which resulted in a complaint that it could not be satisfied). Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Bundle-NativeCode: library/x86/foo.dll;processor=x86;osname=win32,library/x64/foo.dll;processor=x86_64;osname=win32 Works fine in 4.3.2, throws NPE in 4.4.1. And still occurs for me in 4.4.1 with the OP's attached project unmodified. Environment: Windows 8.1. Eclipse 4.4.1 running on Java 8, with Java 8 (In reply to Andy Thomas-Cramer from comment #18) > And still occurs for me in 4.4.1 with the OP's attached project unmodified. > > Environment: Windows 8.1. Eclipse 4.4.1 running on Java 8, with Java 8 Please provide the log with the stacktrace. Created attachment 247721 [details] Log for comment#18 Attached is the full log from the start of a session to File>Export; Plug-in Development>Deployable plug-ins and fragments. Below is the last message from that log. !ENTRY org.eclipse.core.jobs 4 2 2014-10-08 09:27:45.752 !MESSAGE An internal error occurred during: "Export Plug-ins". !STACK 0 java.lang.NullPointerException at org.eclipse.osgi.internal.resolver.NativeCodeSpecificationImpl.isSatisfiedBy(NativeCodeSpecificationImpl.java:88) at org.eclipse.osgi.internal.module.ResolverImpl.isResolvable(ResolverImpl.java:285) at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles(ResolverImpl.java:639) at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:477) at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:545) at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:605) at org.eclipse.pde.internal.build.site.BuildTimeSite.getRegistry(BuildTimeSite.java:186) at org.eclipse.pde.internal.build.BuildScriptGenerator.generateFeatures(BuildScriptGenerator.java:276) at org.eclipse.pde.internal.build.BuildScriptGenerator.generate(BuildScriptGenerator.java:127) at org.eclipse.pde.internal.core.exports.FeatureExportOperation.doExport(FeatureExportOperation.java:257) at org.eclipse.pde.internal.core.exports.FeatureBasedExportOperation.run(FeatureBasedExportOperation.java:50) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) In case it matters, this is on a 64-bit machine with a 32-bit Eclipse IDE. In the log it indicates: eclipse.buildId=4.4.0.I20140606-1215 This is 4.4.0. Where did you download 4.4.1 from? Are you certain you updated successfully? I am running 4.4.1, according to the "About Eclipse" box on both my Windows and Mac installs. Details: Eclipse for RCP and RAP Developers Version: Luna Service Release 1 (4.4.1) Build id: 20140925-1800 I obtained this after the 4.4.1 release last month (probably obtained Oct. 3), from http://www.eclipse.org/downloads/ following the links for "Eclipse for RCP and RAP Developers". I don't know why the 4.4.1 release is showing that buildID in the log, but the IDE itself is showing the version and buildID above. I am currently using a 4.4.0 target platform in the 4.4.1 IDE. (In reply to Andy Thomas-Cramer from comment #23) > I am running 4.4.1, according to the "About Eclipse" box on both my Windows > and Mac installs. Details: > > Eclipse for RCP and RAP Developers > > Version: Luna Service Release 1 (4.4.1) > Build id: 20140925-1800 > > I obtained this after the 4.4.1 release last month (probably obtained Oct. > 3), from http://www.eclipse.org/downloads/ following the links for "Eclipse > for RCP and RAP Developers". > > I don't know why the 4.4.1 release is showing that buildID in the log, but > the IDE itself is showing the version and buildID above. > > I am currently using a 4.4.0 target platform in the 4.4.1 IDE. Something seems off with your installation. Can you bring up the osgi console and run the command: osgi> ss | grep osgi Or if it is not obvious how to get the OSGi console then go to Help -> About Eclipse -> Installation Details (button) -> Plug-ins (tab) Check the version of the plugins (bundles) with the Ids: org.eclipse.osgi and org.eclipse.osgi.compatibility.state I would expect the following versions: org.eclipse.osgi version 3.10.1.v20140909-1633 org.eclipse.osgi.compatibility.state version 1.0.1.v20140709-1414 From Help>About; Installation Details button; Plug-ins tab (versions copied by hand): * org.eclipse.osgi: 3.10.0.v201406061445 * org.eclipse.osgi.compatibility.state: 1.0.0.v20140403-1907 These are not the versions you said should be expected. Let me try this in a clean, newly-downloaded IDE, without adding any additional plug-ins. @Thomas Watson, you nailed it. It was the 4.4.1 build, but I had used "Help>Install New Software" to install extensions from the e4 updates at http://download.eclipse.org/e4/updates/0.16. These are in incubation state. The two below installed older versions of at least the plug-ins you asked about. * Eclipse 4 - 3.x bridge * Eclipse 4 - Model Spy My comment#17 is invalid. This defect no longer occurs in 4.4.1 for me either, given an install without those extensions. My lesson for the day is to try it in a clean install before complaining. Thank you for being very perceptive and helpful. (In reply to Andy Thomas-Cramer from comment #26) > @Thomas Watson, you nailed it. > > It was the 4.4.1 build, but I had used "Help>Install New Software" to > install extensions from the e4 updates at > http://download.eclipse.org/e4/updates/0.16. These are in incubation state. > > The two below installed older versions of at least the plug-ins you asked > about. > * Eclipse 4 - 3.x bridge > * Eclipse 4 - Model Spy I don't like the sounds of this at all. It seems really strange that installing some extensions from e4 update site would downgrade equinox. Perhaps open a bug against e4 incubator on that? > > My comment#17 is invalid. This defect no longer occurs in 4.4.1 for me > either, given an install without those extensions. My lesson for the day is > to try it in a clean install before complaining. > > Thank you for being very perceptive and helpful. No problems. Glad we got to the bottom of it. >I don't like the sounds of this at all. It seems really strange that installing some extensions from e4 update site would downgrade equinox. Perhaps open a bug against e4 incubator on that? Added Bug 446932 - Some e4 updates tools installed in 4.4.1 IDE downgrade parts of it to 4.4.0 (edit) |