Community
Participate
Working Groups
build I20040607-0800 - extracted a zip containing a few plugins to my eclipse host's plugins dir - ran eclipse as before - the perspective and views defined in the plugins did not show up - ss in the console shows that these plugins are unknown The plugins have explicit MANIFEST.MF files. I can provide the zip if needed.
Not sure if this is an update issue.
Nick, what is the shape of your plugin manifest? The regular one (plugin element with id, provider, class name attributes, runtime element allowed), or the new one (plugin element with no attributes, no runtime element).
Update supports bundles with manifests as long as they have the Symbolic Name (and, optionally, version) defined.
The shape of the plugin.xml's is the latter (no attributes, no runtime element). E.g. plugin com.vector.testview2 has: plugin.xml: <?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.0"?> <plugin> <extension point="org.eclipse.ui.views"> <view name="TestView2" category="com.vector.launchTest" class="com.vector.testView2.TestView2" id="com.vector.testView2"> </view> </extension> </plugin> MANIFEST.MF: Manifest-Version: 1.0 Bundle-Name: TestView2 Bundle-SymbolicName: com.vector.testView2;singleton=true Bundle-Version: 0.9.1 Bundle-ClassPath: testView2.jar Bundle-Activator: org.eclipse.core.internal.compatibility.PluginActivator Bundle-Vendor: Vector Consulting GmbH Bundle-Localization: plugin Provide-Package: com.vector.easee.edm.admin.user.extensionPoint Require-Bundle: org.eclipse.core.runtime.compatibility, org.eclipse.ui.ide, org.eclipse.ui Eclipse-AutoStart: true
Although the plugins aren't known to the runtime, they do show up in the PDE Target Platform's list of plugins. Is this as it should be?
Nick, can you attach or send me and Konrad those plugins?
PDE goes through the directories of plug-ins itself, independent of Update/Runtime, and collects all the URLs for the plug-ins and call the Core resolver on them. So Nick's observation in comment #5 is very possible.
Testing, I verified that: - regular plug-ins (no bundle manifest) added to an existing install will be picked - new style plug-ins (with a bundle manifest) are not picked - specifying -clean works around this problem
I've sent the plugins in question to Rafael, Konrad and Dorian.
Actually, I could not reproduce the problem with a simple plugin, only with the ones provided by the originator, which happen to have a feature as well. Maybe that is related?
This looks to me like a timestamp issue with plug-ins built in the past and installed by just unzipping on FAT filesystem, without updating platform.xml. Nick, are you sure explicit manifests make any difference?
It's possible the manifests are a red herring. The timestamp on the plugins are 6/4/2004 8:09AM, which is before the time I first ran this install.
Should still handle this case though. E.g. I should be able to drop a 2.1 plugin on a 3.0 install.
moving to Update. The scenario info indicates that the plugin is not even installed so it is not even getting to the runtime...
As Konrad noted, the problem is caused by timestamp of "plugins" directory not changing when manually installing the new plugins. The update configurator keeps track of the last process configuration, and on each startup it checks the timestamp on the "features" and "plugins" directories to see if anything has been added/deleted. As we just discovered, unlike the other file systems, on FAT, a parent folder's timestamp does not change when its content changes (new files, new dirs, remove file, remove dir). As such, the configurator does not see the new plugins. I'd suggest we don't fix this (at least not in 3.0) for FAT, as any fix may impact startup performance and is too late in the cycle. If FAT is still a very used file system, with a bright future :-), then we should investigate a solution. Right now, win2000 is not even on the list of supported platforms in 3.0.
I propose to README this bug.
Dorian, why is your litmus test on whether things changed based on a function of the timestamp of the plugins/ and features/ directories alone. I remember that once upon a time, the litmus test was a function of all the timestamps of all the plugins (i.e. plugin.xml) that Update finds.
Wassim, see my comment #15. The configurator checks the plugins and features directories timestamps, in each site. On all the os's (except win2000 with FAT), the parent folder timestamp changes when a new file/directory is added or removed. This also buys startup time, because it avoids going to each file and get that data (think 1000 or more plugins), hash it (timestamps are not reliable when unzipping) and store it somewhere.
But if FAT systems make a comeback, then you would be in trouble and I would be in sunny Mexico ;-)
*** Bug 67092 has been marked as a duplicate of this bug. ***
We can investigate using jni calls to get the file system type and have special code for FAT. This could add 30-50k to the RCP. Alternatively, Konrad has found that File volumes[] = File.listRoots(); for(int v=0; v< volumes.length; v++) if(new File(volumes[v], "$MFT").exists()) System.out.println(volumes[v]+" is NTFS"); else System.out.println(volumes[v]+" is not NTFS, possibly FAT"); } can detect the NTFS drives, so we could test that the os is windows and that the drive is not NTFS, in which extra bookeeping and processing can be done to detect changes. For 3.0 I will document in the README that on FAT file systems, after manually installing plugins, the user must re-start eclipse with osgi.checkConfiguration=true
Just a note: FAT is still relatively prevalent on supported platforms due to use of Norton Ghost. I am currently running into this very issue.
*** Bug 70783 has been marked as a duplicate of this bug. ***
*** Bug 74495 has been marked as a duplicate of this bug. ***
*** Bug 79365 has been marked as a duplicate of this bug. ***
Created attachment 37432 [details] Make features honor -clean and osgi.checkConfiguration
-clean and osgi.checkConfiguration work to force rescanning plugins, but they don't trigger a rescan of features. That is why the user has to manually go through the update manager UI (which triggers the scanning of the local site and discovers the feature, but by that time it's too late to automatically enable it). It is reasonable not to do extensive timestamp checking for performance reasons, but -clean and osgi.checkConfiguration should be consistent between plugins and features. The manual step of going through the update manager UI to enable a feature that was just dropped into the features directory shouldn't be necessary if the platform was launched with an argument telling it to refresh its configuration. Because this is not just an issue on FAT32 systems (See https://bugs.eclipse.org/bugs/show_bug.cgi?id=52525#c18 for example), there should be a straightforward way to reload a configuration (plugins and features).
moving back up to update component since Dorian is unlikely to do anything here :-)
Any thoughts on the patch? It would be nice to get this resolved for 3.2 so the readme can drop the complicated steps for enabling manually installed features.
It is a bit late for changes this low in the stack. Branko, can you forsee any problems with the modification above?
Applied.
