Community
Participate
Working Groups
in i05111600 on second and subsequent starts the update.configurator, when building the PlatformConfiguration ends up reparsing all/some/many plugin.xmls. In general this can be avoided since you have timestamps etc that you can use for comparison. the offending code seems to be in SiteEntry.detectUnpackedPlugin if (dirTimestamp <= pluginsChangeStamp && pluginFile.lastModified() <= pluginsChangeStamp) return; PluginEntry entry = pluginParser.parse(pluginFile); There may be similar behaviour in detectPackedPlugin(). Note you may want to conditionalize much/all of this testing based on the osgi.checkConfiguration property. If that is false (or non-existant) then you do not need to check the configuration. In scenarios where people are tweaking the install/configuration (this is relatively rare) they should put -clean or set osgi.checkConfiguration=true to tell Eclipse to check.
I think the problem is caused by old code that was trying to compute the timestamp on each plugin, which seems unnecessary. I will investigate.
The current code in detect(Un)packedPlugin is wrong, because it checks the timestamp. I think the check should be removed, as all the detected plugins will be used later. In addition, to avoid calling detectPlugins(), I will remove the timestamp check on each plugin directory because: - when we first start, without a platform.xml, everything gets computed anyway - I do remember checking that adding/removing a file from a folder changes the timestamp on the folder (Jeff: what does not work on all file systems is editting a file in place may or may not change the timestamp on the parent folder -- this is not needed here) As such, the configurator only cares if plugins were added or removed, so that it updates its list. To do this, it is enough to check the timestamp of the "plugins" and "features" directories and compare with previous timestamps.
Pascal has confirmed that the parent dir getLastModified() value does NOT change on FAT32 when you add a child to the dir. On NTFS it does change.
Unfortunately Pascal is right on this one. I just verified it. There are two quick solutions: detect we run on fat32 or other system that behaves that way, or, better, keep the old code but don't parse the plugins, just check the timestamps on the plugins dir. For this, we need to get rid of the the old code was parsing the plugin (partial parsing). This parsing was done to make sure we only look at plugins. I think it is fair to look at all the directories or jars in the plugins dir.
suggest you put the plugin dir timestamp checking in place. Then as a further optimization we can (prehaps at a later date) do different behaviour based on the type of the filesystem being scanned. Not sure how/if you can tell that from Java (java.io.FileSystem knows but that is a protected object I believe). What about only doing that checking if osgi.checkConfiguration=true? In either case (true or false) you would have to check for NEW contents in the "plugins" dir. I belive that the framework should handle deletion of previously installed plugins. Not sure if you are interested in deletion of things that you have seen but for whatever reason decided not to install.
I have released code in HEAD (and plan to have in the I build today) for not parsing plugins, but just take the timestamp on each file/folder located in the "plugins" directory. So, almost the same as before, but without parsing. As you said, for a better optimization, we can use some JNI code to detect the file system type (at least on windows).
