Community
Participate
Working Groups
3.1M7 When PDE asks StateHelper to return all the packages visible to a particular bundle, the result includes all the system packages when the jre profile is set on the state. This problematic for PDE and JDT because the 100+ system packages are associated with the osgi plugin. So when PDE creates access rules for JDT to set on osgi.jar, every one of these system packages will have an associated access rule. These rules are totally unnecessary on osgi.jar since said JAR does not contain any of these packages. The only way PDE could help with system packages is if PDE had access over the JRE container, which we don't. Therefore, when PDE asks for visible packages, please exclude system packages.
Created attachment 21243 [details] Possible fix Wassim, please test this out.
I just verified that PDE now receives 39 exported packages for the org.eclipse.osgi plugin starting with org.osgi.framework and ending with org.eclipse.osgi.internal.resolver. System packages are history.
Keep in mind that in 3.2 we hope to have control over the JRE container as well so these packages will be interesting in the future.
This will be tricky jeff, since the JRE container is owned by JDT and they would like to remain agnostic of anything Eclipse-y.
that's why its a 3.2 item...
We can consider adding a getSystemPackages to State. Can PDE somehow extend the JRE container (proper term?) to filter only the packages from getSystemPackages. At a minimum it seems we could ask the JDT to add an option the the JRE container to filter a set of packages. I may be way off since I am not that familiar with JDT. Again this would not happen in 3.1.
>At a minimum it seems we could ask the JDT to add an option the the JRE >container to filter a set of packages. JDT does have such a mechanism, but it requires the user to manually add all these jre access rules into the .classpath file. The user will then have to maintain it. This is certainly far from the luxurious transparent support that PDE provides for its container. We would certainly have to come up with a creative solution in 3.2 that maintains the generic nature of JDT and yet allow PDE to have some control over the JRE container.
lets do both! remove the system packages from the normal result and add getSystemPakcages. That way PDE gets what they need and other users can reconstruct the full picture.
marking for RC1 ...
Fixed in HEAD. Added the method State#getSystemPackages for future use by PDE.
One idea might be for the plugin projects to not use the JRE container anymore and have the PDE add the JRE jars with the right access restrictions as part of the PDE container.
