Community
Participate
Working Groups
PDE currently assumes all META-INF/MANIFEST.MF files in the root of a project are OSGi manifests. There are scenarios in some products which a non-plug-in project has a Manifest file. When saving the cache of the workspace state, PDE currently assumes that if a Manifest file does not have an Bundle-SymbolicName that something is wrong and does not save the cache. We need to be more flexible and save caches when the user has non-OSGi Manifests in their workspace.
Discovered while testing fix for bug 206382. Found that some projects with a MANIFEST.MF and no plugin.xml file where loaded at startup @see PluginModelManager#addToTable(IPluginModelBase[]) and line: if (id == null) continue; we do not skip such projects, and these are loaded with other models. When shutting down, PDEState#shouldSaveState(IPluginModelBase[]) will return false if a single of the workspace projects has either: - id set to null - no bundle description As a consequence, if a workspace contains a single of such projects, then we won't be able to save and cache the workspace projects. Which in turn has a severe impact on startup when dealing with large workspace. I'll attach a sample MANIFEST.MF file.
Created attachment 80691 [details] [sample MANIFEST.MF]
Added performance keyword, due to startup time implications when unable to reload cached data.
Created attachment 81091 [details] proposed fix This patch should fix the problem. If a model in the workspace does not have an id, then we can assume it is not an OSGi project.
(In reply to comment #4) according to the Sun spec, as referenced in OSGI 4.1 spec, the only mandatory attribute for an OSGI manifest is the name (Constants.BUNDLE_NAME / Bundle-Name). The Bundle-SymbolicName or Bundle description do not look mandatory (but ain't not expert). The fact is that I have many workspaces where I have bundles that have a MANIFEST.MF with: - Manifest version, Name, id and so on - Manifest version and classpath attributes see: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Manifest%20Specification Ideal situation would be to be able to load (at startup) and save (at shutdown) both osgi and non-osgi bundles.
I am not sure all the required OSGi headers, but I know Bundle-SymbolicName is definitely required. This is the unique identifier for each bundle. The idea is that if the Manifest does not have a Bundle-SymbolicName, it is not trying to be an OSGi Bundle. Therefore, PDE tooling will ignore it (since it can't do much with it). When saving our cache, we will exclude it from the cache. One problem I just found was that when we read the cache, we don't create a model for the projects which don't have OSGi manifests. I imagine this should not be a problem, but it is not wise to return a different value compared to what you would see after a restart. I will have to look into this a bit more to make sure we don't break anything.
Created attachment 81206 [details] revised fix Updated the fix to return consistent information after restart. If a project has a Manifest file but is not an OSGi file, PDE will still create a model for it in the WorkspacePluginModelManager. Upon shutdown, we use the locations of all the models to calculate the hash for the directory. We then only save the information from the bundles which have BundleDescriptions (OSGi bundles). Upon startup, we calculate the hash from all the project's that contain Manifest files so we can accurately calculate the hash for the directory where we saved the cache. When we find it, we read in and create all the valid models we saved. Upon initialization of the WorkspacePluginModelManager, we include the cached models, but also create a model for any project with a Manifest for which we were not able to create a model from the cache. By doing this, when we shut down we calculate the same cache directory if nothing changes, and guarantee the same result for PluginRegistry.findModel(IProject) for a project that is not an OSGi project.
Created attachment 81209 [details] patch for 3.3 maintenance release stream Same patch as above, just targeted for 3.3.
For right now, I am only applying the fix to HEAD. I attached a patch for safe keeping in case people need it in 3.3.2. If that is the case, we can reopen the bug and apply the patch.
(In reply to comment #7) that sounds a smarter way to save workspace projects. I'll have a go and will try this fix ASAP.
