Community
Participate
Working Groups
Currently, the system.bundle is merely an alias to org.eclipse.osgi bundle. This is correct when the target platform is Equinox based. In case the target platform is not based on Equinox, the system.bundle alias is different bundle (usually:). So, if someone is developing against different platform, it becomes a bit messy, because, org.eclipse.osgi is no more the system.bundle The bigger problem is that there is no way to specify and the PDE to find out, which bundle of the target platform is the system one. The only idea I have for now is to look for Eclipse-SystemBundle header (or some other header).
As Danail points out there are two issues: 1) The resolver PDE uses needs the ability to alias the system.bundle to another bundle other than org.eclipse.osgi. 2) PDE needs a way to figure out which bundle in the target is the system.bundle so it can use the correct system.bundle alias. For the first issue the resolver could be enhanced to pass the system.bundle alias as a platform property. Currently the resolver uses an internal framework method to obtain org.eclipse.osgi as its alias (org.eclipse.osgi.framework.internal.core.Constants#getInternalSymbolicName()). This always returns org.eclipse.osgi. We could require this information be passed as a platform property instead to the State.setPlatformProperties method. For the second issue I'm not sure what the best approach is. The spec does not give any guidance on the system.bundle manifest or file format. The system.bundle is not even required to be a jar with a proper manifest. Most implementations seem to use a jar file but I have seen some that do not even contain a proper bundle manifest file. Perhaps we can get by with requiring a the system.bundle to be a jar file with a proper bundle manifest for PDE tooling. If that is acceptable then I would suggest that the Eclipse-SystemBundle: true header be used to indicate the jar file is the system.bundle for PDE tooling. Then PDE would search the target for this header and use that bundle's symbolic name as the system.bundle alias. If multiple are found what should PDE do? If org.eclipse.osgi is one then prefer that one I guess :) otherwise just pick the first one. There is also an issue of java profiles. Currently PDE uses the org.eclipse.osgi jar to provide java profiles for setting up the necessary execution environment information. Should PDE require other system.bundle's to contain the execution environment profiles?
It sound reasonable that the execution environment profiles should be located in the system bundle.
I have made some initial effort in implementing this enhancement. However, I'm not very familiar with all the aspects of the code to be changed. As we kind of agreed on how this will be handled, I changed the resolver and the PDE states to look out for different system bundle specified via Eclipse-SystemBundle header. Here are some notes I taken while working: 1) System bundle setting is exposed as API on the State object. This is not mandatory, if we add utility method which extracts the system bundle from the platform properties and use this method 2) The system.bundle name isn't substitued upon bundle adding/updating. VersionConstraint takes care of returning correct value, during resolving process. 4) MinimalState now holds the value of the system bundle. It is detected when the bundles from the target platform are added. Profiles are considered changed when bundle with Eclipse-SystemBundle header is added and not when org.eclipse.osgi bundle is added. The system bundle is passed as property to the State and it is serialized with the platform properties. Upon loading, it is restored through the same platform properties into the MinimalState This summarizes the changes I have done. However, there are things which are not very clear how will be handled: 1) How launching will be handled for multiple system bundles - there is code inside the launcher which assumes that the system bundle is org.eclipse.osgi. I haven't put much thought in the subject. 2) Building features and product configurations - there is a code which references org.eclipse.osgi bundle directly. I didn't have opportunity to dive much in the subject. What do you think? I'll attach the patches, so you can review. It would be great if you can give me some directions on how to proceed. Do you intent in including this in 3.4?
Created attachment 85263 [details] Patch for the equinox resolver
Created attachment 85264 [details] Patch for PDE core
Danail, thanks for the patches. I can help review the PDE core one while Tom will have to review the resolver patch. As long as we can get this working, I don't foresee why we can't get this in for 3.4. It might be a few days until we get back to you, I am still try to catch up with all the stuff I missed while being out for the holidays :)
Sounds like something fantastic to add in 3.4M5
Tom, could you review the equinox resolver patch when you get a chance?
Created attachment 88074 [details] equinox resolver patch I did an initial review of the equinox patch. The patch is a great step in solving this issue. I found a few issues: 1) As stated in Danail's comment 3 a new API method was added to state to get the system bundle systembolic name for the state. I would like to avoid this and require the platform properties be used instead. This patch does that. 2) We had a temporary constant in the internal Constants.OSGI_SYSTEM_BUNDLE. This should be removed and we should use the org.osgi.framework.SYSTEM_BUNDLE constant. Not strictly related to this bug but it was confusing me because some of the code used one constant and some used the other constant. 3) I think we should avoid using "system.bundle" as the platform property for specifying the system bundle symbolic name. I modified the patch to use "osgi.system.bundle". We may want to be even more specific and use osgi.system.bundle.symbolicName. The motivation is to have a specific enough property that is very unlikely that anyone has used the property before. 4) I found a bug in ImportPackageSpecificationImpl which prevented proper aliasing when the attribute bundle-symbolic-name=system.bundle I added several tests to verify that the osgi.system.bundle aliasing works for Require-Bundle, Import-Package and Fragment-Host. Danail, can you update the PDE patch to the latest in HEAD and update it to use the "osgi.system.bundle" platform property.
Created attachment 88075 [details] equinox resolver patch I added an internal constant for osgi.system.bundle. This way if we decide to change the constant it only has to be changed in one spot in the framework.
Created attachment 88229 [details] org.eclipse.pde.core.patch The patch was updated to use the new system property that Tom mentioned.
Created attachment 88230 [details] mylyn/context/zip
Created attachment 88231 [details] org.eclipse.pde.core.patch This is an updated patch... we missed a corner case where the system.bundle could be null. It would be nice to get the Prosyst guys to test this with their system bundle now... :)
I also opened bug 217022 to make it easier to see what the current system bundle is if you're adding it to things...
Danail, want to give it a go?
I'll definitely test it today or tomorrow and will post back. Thanks.
Created attachment 88623 [details] updated patch for pde.ui and pde.core Update the org.eclipse.pde.core patch with one that includes changes to org.eclipse.pde.ui. Also created a function in PluginModelManager to get the system bundle name without having to get the State, as this seems like we are relying on the underlying implementation when going directly through the state. Tom, are you ready to release the resolver changes? I think we should be ready on the PDE side.
Created attachment 88635 [details] equinox framework patch Updated patch against HEAD. I am waiting for confirmation back from Danail before releasing. I am not that comfortable releasing this close to M5. If we do not hear confirmation back in time to release for a Monday Build then I suggest slipping this to M6.
Sorry for the late answer. I tested the latest patches and didn't encounter any problems. I hope it isn't too late:)
sorry Danail, this will have to wait for M6. We'll get it in the first week after M5 is out the door :)
I opened a separate bug 218625 for the resolver changes. I will release the changes to the resolver in that bug today.
Thanks Tom. Thanks Danail for helping out with the testing. If possible, I would love a screenshot of you using a prosyst system bundle and launching with it for possible inclusion in the next N&N.
Created attachment 89505 [details] mylyn/context/zip
clearing out old review requests.
