[dhannum]

Hi, everyone. I’m using MyEclipse (4.0 milestone 3). It appears that MyEclipse is too quick to lock files. Here is my situation:

I have an ant script that creates a build directory at the top level of the project. This directory contains everything that will go in the WAR, including JARs. However, if I ever refresh my project when that build directory exists, MyEclipse quickly locks every JAR in the build directory tree (along with every one in the web/WEB-INF/lib directory). Once that happens, I can no longer do a clean build from my ant script, because the clean build deletes the entire ‘build’ directory.

It doesn’t matter if I kick off ant from inside the IDE or outside, or if I close the project before attempting to build. MyEclipse (or technically, it’s javaw.exe process) has the files locked and only killing the IDE will let me do a build again. I understand this may be an artifact of running MyEclipse on Windows, but it’s no less inconvenient. Also, if I remove the MyEclipse features from within Eclipse, the problem goes away, so it’s something you guys are doing.

It’s as if MyEclipse is locking every JAR it finds without regard to whether this jar is really needed for the build.

Thanks for any help you can give
Dan

[Riyad Kalla]

Dan,
The locking mechanism is a read-lock by tghe Eclipse platform for any JAR in your *build path*, neither Eclipse or MyEclipse will willy-nilly lock files in your project for no reason. If your build dir is off the root of your project, then it should not (is not?) locking these files. However if you are trying to remove files from the WebRoot/WEB-INF/lib directoriy , those most likely will be locked by Eclipse for autocomplete indexing.

What si the structure of your project? If you navigate to Project Properties >MyEclipse-Web, what do you ahve set there?

[dhannum]

I agree that there is no reason for MyEclipse to lock the jars, so something must be referencing them. My project structure is as follows:

<root of project>
—–>web
———->WEB-INF
—————>lib
—–>src
—–>build
———->web
—————>WEB-INF
——————–>lib

There are jars under web/WEB-INF/lib, as you’d expect, and MyEclipse finds them automatically and puts them in the build path. At first, the ‘build’ directory tree does not exist. Then, we kick off an ant build (from the IDE or cmdline) and the build directory is created. It contains it’s own parallel web/WEB-INF/lib tree. Everything is fine in Eclipse until we refresh, at which time we cannot delete the build directory from the cmdline or from Windows Explorer because the jars in the build/web/WEB-INF/lib directory is locked. It appears that all of them are. A look at ProcessExplorer shows that the javaw process has both build/web/WEB-INF/lib/anything.jar and web/WEB-INF/lib/anything.jar locked. If I check the build path after the refresh, I still see that the only jars listed are the ones in web/WEB-INF/lib

If I go to Project Properties>MyEclipse-Web, it says that my Web Root folder is ‘web’ and that my Web Context Root is ‘/<name of project>’. I have not made any changes to this screen.

[dhannum]

In fact even if I try to delete the ‘build’ directory from within the project (from Package Explorer), it fails: “Problems encountered deleting resources”. The UI doesn’t give any useful information (the details box is empty), but the log contains the following stack trace and an entry for every jar file in build/web/WEB-INF/lib

!MESSAGE Problems encountered while deleting resources.
!STACK 1
Java Model Exception: Core Exception [code 4] Problems encountered while deleting resources.
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:50)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:718)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3760)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3717)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:95)
at org.eclipse.jdt.internal.corext.refactoring.reorg.DeleteChangeCreator$1.perform(DeleteChangeCreator.java:68)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:232)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1739)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:280)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.access$1(UIPerformChangeOperation.java:1)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$1.run(UIPerformChangeOperation.java:63)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
at org.eclipse.core.runtime.Platform.run(Platform.java:783)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$2.run(UIPerformChangeOperation.java:81)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3057)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2716)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:153)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:303)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:293)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinish(RefactoringWizard.java:547)
at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:153)
at org.eclipse.jdt.internal.ui.refactoring.reorg.DeleteWizard$DeleteInputPage.performFinish(DeleteWizard.java:124)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:613)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:417)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:409)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:556)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3080)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2713)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:809)
at org.eclipse.jface.window.Window.open(Window.java:787)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:125)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:138)
at org.eclipse.jdt.internal.ui.refactoring.actions.RefactoringStarter.activate(RefactoringStarter.java:40)
at org.eclipse.jdt.internal.ui.refactoring.UserInterfaceStarter.activate(UserInterfaceStarter.java:56)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringExecutionStarter.startDeleteRefactoring(RefactoringExecutionStarter.java:208)
at org.eclipse.jdt.internal.ui.refactoring.reorg.DeleteAction.run(DeleteAction.java:84)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:222)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:198)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:996)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3080)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2713)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334)
at org.eclipse.core.launcher.Main.basicRun(Main.java:278)
at org.eclipse.core.launcher.Main.run(Main.java:973)
at org.eclipse.core.launcher.Main.main(Main.java:948)
Caused by: org.eclipse.core.internal.resources.ResourceException: Problems encountered while deleting resources.
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:677)
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:704)
at org.eclipse.jdt.internal.corext.refactoring.changes.DeleteFolderChange.doDelete(DeleteFolderChange.java:87)
at org.eclipse.jdt.internal.corext.refactoring.changes.AbstractDeleteChange.perform(AbstractDeleteChange.java:37)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange$1.run(DynamicValidationStateChange.java:92)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:718)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3760)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:3717)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:95)
at org.eclipse.jdt.internal.corext.refactoring.reorg.DeleteChangeCreator$1.perform(DeleteChangeCreator.java:68)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:279)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:232)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1739)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:280)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.access$1(UIPerformChangeOperation.java:1)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$1.run(UIPerformChangeOperation.java:63)
at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044)
at org.eclipse.core.runtime.Platform.run(Platform.java:783)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation$2.run(UIPerformChangeOperation.java:81)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3057)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2716)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:153)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:303)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.run(RefactoringWizardDialog2.java:293)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.internalPerformFinish(RefactoringWizard.java:547)
at org.eclipse.ltk.ui.refactoring.UserInputWizardPage.performFinish(UserInputWizardPage.java:153)
at org.eclipse.jdt.internal.ui.refactoring.reorg.DeleteWizard$DeleteInputPage.performFinish(DeleteWizard.java:124)
at org.eclipse.ltk.ui.refactoring.RefactoringWizard.performFinish(RefactoringWizard.java:613)
at org.eclipse.ltk.internal.ui.refactoring.RefactoringWizardDialog2.okPressed(RefactoringWizardDialog2.java:417)
at org.eclipse.jface.dialogs.Dialog.buttonPressed(Dialog.java:409)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:556)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3080)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2713)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:809)
at org.eclipse.jface.window.Window.open(Window.java:787)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation$1.run(RefactoringWizardOpenOperation.java:125)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
at org.eclipse.ltk.ui.refactoring.RefactoringWizardOpenOperation.run(RefactoringWizardOpenOperation.java:138)
at org.eclipse.jdt.internal.ui.refactoring.actions.RefactoringStarter.activate(RefactoringStarter.java:40)
at org.eclipse.jdt.internal.ui.refactoring.UserInterfaceStarter.activate(UserInterfaceStarter.java:56)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringExecutionStarter.startDeleteRefactoring(RefactoringExecutionStarter.java:208)
at org.eclipse.jdt.internal.ui.refactoring.reorg.DeleteAction.run(DeleteAction.java:84)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:222)
at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:198)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:996)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:538)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:488)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:400)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3080)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2713)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:367)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334)
at org.eclipse.core.launcher.Main.basicRun(Main.java:278)
at org.eclipse.core.launcher.Main.run(Main.java:973)
at org.eclipse.core.launcher.Main.main(Main.java:948)

[Riyad Kalla]

This is very strange indeed… if you switch to your navigator view and look at your build directory, are there any dot files in there? I wonder if some are getting copied in there and changing (on the fly) the webroot…

[dhannum]

Nope, no dot files. The build directory has a web directory that is a copy of the main web directory, except that it contains class files as well (basically, it’s the exact structure of the war). Build also contains an output directory with some build artifacts and the resulting WAR that was generated.

Could ME be getting confused by the presence of a web.xml, etc. in the build directory.

I also upgraded to 4.0 Official and it still does this

[Riyad Kalla]

Could ME be getting confused by the presence of a web.xml, etc. in the build directory.

No it shouldn’t be, many of our users make use of a build pattern much like the one you are describing. I want to rule out ANY weirdness possibility, this will require some leg work, but I would appreciate it if you could do this:

1) Redownload Eclipse 3.1.1 SDK and unzip it to a new location
2) Run it, creating a NEW workspace. Close it.
3) Redownload MyEclipse 4.0.2 and install it against the new unzipped Eclipse install
4) Fire it up, pull your project out of source control, try and run your ant script… refresh the project, still same problem?

Be sure to do the refresh after the build completes.

[dhannum]

(your website forced me to re-login after I hit the submit button, and lost my post. Grrrrr)

Anyway, I did what you asked, using a new workspace and new install of Eclipse and MyEclipse. The problem still appears both with my old project imported and with a brand new MyEclipse Web Project created. I did learn a few things though.

1. If I turn off automatic building, the locks aren’t taken by the refresh, but by the build process.

2. That build process is compiling and validating my jsp in the build directory. This is unnecessary since they are copies of jsp’s outside the build directory, but it got me thinking. If I mark the build directory as ‘derived’ the jsp’s aren’t compiled and the locks are not taken.

3. Problem is, the ‘derived’ tag isn’t smart enough to survive the deletion of the build directory that happens on every clean build, so I still have to re-mark it.

Any idea why the build process (and possibly the jsp compilation, though not proven) might do this?

Thanks for you help on this

[Scott Anderson]

3. Problem is, the ‘derived’ tag isn’t smart enough to survive the deletion of the build directory that happens on every clean build, so I still have to re-mark it.

Any idea why the build process (and possibly the jsp compilation, though not proven) might do this?

Thanks for doing the investigation. The locks are likely occuring due to compiling the JSPs once they’re created in the build directory as part of the project validation process. That would explain what you’re seeing. Unfortunately, the javac process will always lock jars while it’s using them so what we need to do is find a way to tell the project not to validate the JSPs. It sounds like a solution would simply be to either create a directory above ‘build’ and mark it derived or slightly modify the build script so it deletes everything under build, but not the directory itself. Then, you can continue to mark ‘build’ as derived. In either case you could then add the directory to .cvsignore so that it wouldn’t be source code controlled, if you’d like.

[dhannum]

I still don’t see why the JSP compilation process doesn’t use the standard build path jars and uses the ones in ‘build’ instead. Should that be classified as a bug?

In the short term, I can get by with leaving an empty ‘build’ directory there and adjust build script. It does have the advantage of avoiding slow JSP compiles on the build directory. Locks or not, JSP compilation is slooow.

[Riyad Kalla]

Should that be classified as a bug?

We are still evaluating it but on the outskirts it sure seems like it.

[Riyad Kalla]

Dan,
I want to let you know that this bug was fixed internally and will be available in our 4.1 release. Additionally as part of this fix the developer on the problem managed to optimize project compilation considerable for complex projects. So good news all around.

[Author]

Posts