Community
Participate
Working Groups
Build Identifier: 20100617-1415 When a workspace bundle implements an Eclipse Extension Point (plugin.xml) exported by a bundle in the Target Platform, Eclipse obtains a Windows File Lock on the bundle in target platform as part of the build step. There appears to be no-way to release this lock other than closing Eclipse or using an Unlocker program. These locks cause issues in our development environment where we rebuild our target platform from a central repository. This behavior is only observed on windows, however I believe that to be because file locking is less strict on *nix platforms. The Locks appear to be obtained as part of the "Plug-in Manifest Builder" and sometimes the "Extension Point Schema Builder" as disabling both these builders prevents the locks being obtained. In most cases (including the attached reproduction) just disabling the "Plug-in Manifest Builder" is sufficient. These File Locks persist when the Projects implementing the Extension Point are closed and when the target platform is deactivated or deleted in the Eclipse Preferences. There appears to be no way to remove these locks other than closing Eclipse. Reproducible: Always Steps to Reproduce: 1. Create a bundle that exposes an Extension Point. This should be a JAR rather than a project or folder. (ExportExtensionPoint.jar servers this purpose in the reproduction, The ExportExtensionPoint eclipse project is the source of this). 2. Create a clean eclipse workspace with no projects in it 3. Add the bundle containing the extension point to the target platform of this workspace. 4. Create or import a Plugin project with an extension implementing the extension point (The UseSimpleExtensionPoint eclipse project serves this purpose in the reproduction) 5. Ensure the "Plug-in Manifest Builder" is enabled on this Plugin Project. 6. Trigger a Clean Build 7. Use http://ccollomb.free.fr/unlocker/ or a similar tool to inspect the bundle from step 1 for file locks, it will show that it's locked by eclipse.
Created attachment 179592 [details] Reproduction of this Issue
Confirmed using PDE code from HEAD on linux. If the plug-in manifest builder has run, there is a lock opened on the bundle in the target. I couldn't find anything in the builder code that would lock the file. I expect that buried somewhere in the builder we open the jar to get the schema file. The schema file would be used to verify the contents of plug-in.xml. I'll do some more digging.
The file is opened in SchemaUtil.getInputStream(URL). Darin thinks there may be a known issue with url.openStream(). Olivier, do you happen to know anything about it? We do use open stream in many places in the platform.
Fixed in HEAD. Added two addtions: 1) When opening the url connection, if it is a jar file connection setUseCaches is set to false. This results in the file being closed when the stream is no longer being used. It also avoids connection issues that others have had. 2) If the connection is a jar file connection, the jar file is obtained an explicitly closed. In my test cases (1) was enough to close the file, but since the behaviour can change based on the JRE being used, it is better to have the additional check. I used code from JDT (JavaElement) for reference. See Schema, SchemaUtil and SchemaTraversePerfTest
Thanks for the quick resolution, would it be possible to back port this fix to a 3.6 service pack? This is causing significant pain for our windows based developers and we'd like to take advantage of it without waiting for 3.7.
Reopening to consider for 3.6.2. I'm on the fence whether this is something we want to backport. It's not a trivial fix, but it should be safe.
I have committed the code to the maintenance branch. Ankur, please verify.
ping Ankur, Please verify this when going through the 3.6.2 test pass.
Verified in M20110112-0800 3.6.2. is not holding file locks
