Community
Participate
Working Groups
Build Identifier: Build id: 20100917-0705 On http://wiki.eclipse.org/Adaptor_Hooks there is a description for "Bundle File Factory Hook" which allows bundle source containers other than directories and JARs. We use that feature and it is working like a charm. Now we started to integrate p2 for self-provisioning updates. We let buckminster build a standard p2.site in which the container format is changed to a custom type (still having file extension "jar" which may be dirty but eases a lot and did not do any harm until now). p2 site is being re-processed (fixing md5 sums, etc.). Now there is a (as it seems unnecessary) problem: p2 does not take into account the available bundle file factory hooks. This causes the installation routine of p2.director / p2.installer to crash when it comes to the "configure" phase. Funny thing is: p2 already has the manifest of every bundle from the repository (contents.jar/xml). It installs all plugins/bundles correctly by copying them to the "plugins" folder. Then when it comes to generate the configuration data (simpleconfigurators bundles.info) then all bundles are often handled as plain "jars" (utilizing ZipFile or JarFile or "jar:" URL) *just to simply get the manifest*; even more often only the symbolicName or the bundle version is being needed. All these infos are already available in frameworkadmin BundleInfo. (Which is given as a parameter to all these routines) And still: If it would not be available it could be read from the bundle by using the registered osgi bundle file factory hooks. My current workaround is: I debugged the p2.installer run. Stopped on every point, where manifest infos were needed. Changed the code to use the already present BundleInfo manifest string (sometimes it was neccessary to parse the manifest String to a Map). Result: Installation is successfully completed, although the container format is not readable as a JAR. I am currently collecting the changes, that I needed to make. I believe it affected only one class in "org.eclipse.equinox.frameworkadmin.equinox" and one class in "org.eclipse.equinox.simpleconfigurator.manipulator". Will add the infos as a comment when ready. Reproducible: Always Steps to Reproduce: 1. create a bundle file factory hook for proprietary container format 2. create update site with eclipse rcp product 3. convert bundles to proprietary container format 4. reprocess p2 metadata repository to be valid 5. install product as standalone version
Created attachment 203890 [details] patches on frameworkadmin.equinox to avoid exceptions on proprietary bundle containers patches are marked with XXX comments
Created attachment 203891 [details] patches on simpleconfigurator.manipulator to avoid exceptions on proprietary bundle containers patches (marked with XXX)
In the meantime I encountered some further (or better: additional) problems on using p2 for non-JAR bundle containers. The inital p2 installation of non-jar bundles is working for me with the attached patches. (Although I am still hoping for a solution which saves me from patching eclipse bundles). But when *updating* such an installation with some new non-jar-bundles, SimpleConfiguratorManipulator still has problems with creating the "bundles.info". And this time (within SimpleConfiguratorManipulatorImpl.updateBundles()) the manifest string is empty in the created BundleInfo (which is inevitable as these BundleInfos seem to be created from the already existing initially parsed "bundles.info", which obviously does not contain the manifest info). I really hoped, it would be possible to instrument the StorageHook (also part of the adaptor hooks) in order to adapt the capabilities at least for the EclipseStorageHook.getManifest() method. (Which seems to be the problem currently) It's a pity that EclipseStorageHook is implemented as *final*. I tried working around by delegating from my impl of StorageHook. But doing that resulted in some ClassCastExceptions because there are some routines which do a straight cast from StorageHook to EclipseStorageHook... By the time I am getting short on ideas... Did I miss something?
Ok, I couldn't leave it that way... So i played around. As EquinoxBundlesState itself has a BundleContext it is possible to query that instance for all (already known) installed bundles which in fact allows me to get the (current, already loaded and supposedly cached) manifest. So I re-attach my extended patches to this bug. I should mention: I currently work on Helios SR1 because this is our current productive environment. ASAP I will try to get these patches working for Indigo. Maybe I am doing some major mistakes with this solution ... but ... actually it is working. But then again maybe we are currently the only ones using the Base Adaptor Hooks for non-JAR bundle containers. Any comment is appreciated. :-) Have fun!
Created attachment 204074 [details] patches on frameworkadmin.equinox to avoid exceptions on proprietary bundle containers
Created attachment 204075 [details] patches on simpleconfigurator.manipulator to avoid exceptions on proprietary bundle containers
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
