Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 334507

Summary: Create filters from Bundle-NativeCode osname & processor
Product: [Eclipse Project] PDE Reporter: Oliver Vesper <oliver.vesper>
Component: BuildAssignee: pde-build-inbox <pde-build-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: minor    
Priority: P3 CC: aniefer, jeffmcaffer, tjwatson
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
NPE Stacktrace none

Description Oliver Vesper CLA 2011-01-17 05:50:59 EST 
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
Comment 1 Oliver Vesper CLA 2011-01-17 05:52:30 EST 
Created attachment 186896 [details]
NPE Stacktrace
Comment 2 Andrew Niefer CLA 2011-01-17 15:23:12 EST 
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.
Comment 3 Thomas Watson CLA 2011-01-24 11:49:50 EST 
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.
Comment 4 Lars Vogel CLA 2018-12-03 09:05:14 EST 
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.