Community
Participate
Working Groups
Build Identifier: I20100608-0911 I was trying to perform a headless build of one of my products for platform win32_x86. By a mistake of mine I included a plugin which is targeted only for win32_x86_64 as you can see from its manifest header: Bundle-NativeCode: lib/some.dll;osname=win32;processor=x86_64 The build terminated due to a NullPointerException with the attached stack trace. I would have exptected a user-friendly error message pointing me to the discrepancy mentioned above. Reproducible: Always Steps to Reproduce: 1. Create a feature-based product and include a plugin with a bundle-nativecode manifest header which differs from the config to build 2. Perform a headless build
Created attachment 186896 [details] NPE Stacktrace
For Bundle-NativeCode we currently only looking at the "selection-filter" attribute. We can fix the NPE and the build would complain that the bundle did not resolve if you weren't targeting that configuration. If you wanted to have the bundle included in a product and run build only for some other other configuration, things wouldn't work without an additional selection-filter or Eclipse-PlatformFilter. More generally, can we translate the processor & osname into a ldap filter against which we can compare the normal os/arch values from our config. (Are values here ever something like "Windows" or "i386"?) I'm not sure what to do about the os version. I'm fixing the NPE but keeping the bug open to see if we can handle osname & processor directly.
Andrew, the resolver should handle the osname and processor attributes on native code for you as long as osgi.os=win32 and osgi.arch=x86_64 in the resolver state properties. We alias osgi.os and osgi.arch properties to the necessary osgi properties in the resolver to resolve the Bundle-NativeCode attributes.
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. Please reopen, if you plan to provide a fix.
