Community
Participate
Working Groups
The OSGi spec mandates that you have more than one library for the same environment then you should include all of the libraries for that environment in the same Bundle-NativeCode entry. We should do general validation for the Bundle-NativeCode header... in PDE we have a policy of there's no developer left behind :)
attaching context
Created attachment 77039 [details] mylyn/context/zip
We should look into migrating eclipse over to using the Bundle-NativeCode header. The current way eclipse ships native code in bundles is not standard OSGi which means these types of bundles cannot run on other OSGi Frameworks unless they (the other Framework) also implement our native code lookup algorithm. In order to do this migration PDE will need this enhancement to help the developers. Also note that we do not want to migrate Eclipse bundles to use the Bundle-NativeCode header until bug 165964 is fixed so that native code matching is a resolve-time check instead of install-time. This is similar to how the Eclipse-PlatformFilter is handled at resolve-time.
removing bugday keyword, updating depends
It would be nice to have Bundle-NativeCode validation in M5. See bug 201700. It would be good to flag a warning/error when Bundle-NativeCode refers to a file that does not exist in the bundle.
I can take a look at this while I am doing validation for Bundle-ActivationPolicy. The two things we need to validate are: 1. libraries specified in the headers actually exist. 2. We don't have duplicate environments specified in the header. Instead the user should have all the libraries needed for the environment list in one element. Let me know if I missed anything.
How will you validate point 2? Are you just going to make sure that multiple clauses don't have exactly the same set of attributes? The following are the valid attributes that can be part of a clause: processor osname osversion language selection-filter You should probably flag warnings if the clause has an unrecognized attribute. You could also do the same filter validation on the selection-filter attribute that you do on the Eclipse-PlatformFilter to make sure the filter is valid.
> How will you validate point 2? Are you just going to make sure that multiple > clauses don't have exactly the same set of attributes? That was my plan. How does the runtime validate that case? We really should be doing it the same way.
The runtime does not actually care if multiple clauses match the same environment. Lets use an example: Bundle-NativeCode: somenative01.dll; processor=x86; osname=win32, somenative02.dll; processor=x86; osname=win32 This example has two clauses, one for somenative01.dll and one for somenative02.dll. Both define the same processor and osname attributes. In this case the framework does not give a warning at all. Instead, if multiple clauses match the environment then it picks the first one that matches in the list. In this case the native somenative01.dll would be selected and somenative02.dll would be ignored. This is likely not what the developer intended. At the tooling level I think the best thing for you to do is to provide a warning if multiple clauses have the exact same attribute keys/values. If that is detected then suggest that the native paths be combined into one clause.
tagging bugday
*** Bug 297101 has been marked as a duplicate of this bug. ***
