STS 2.5.2 locks JARs under WEB-INF/lib

[Silvana]

Hi,

we installed some features of the STS 2.5.2 to an Eclipse Helios SR1 for usage in the development of web projects.

The problem is that the STS locks the JARs under WEB-INF/lib. We activated the "non locking classloaders" option, and we also deactivated the AOP Reference Model Builder, but nothing helped.

Could you help us solving this problem?

Thanks in advance,
Silvana

[Kris De Volder]

Are you using Grails / Groovy tooling? If so, there is known issue with jar locking and someone is working on fixing it.

https://issuetracker.springsource.com/browse/STS-1017

If not, perhaps you should provide more information on exactly what you are doing. Many people are working on pieces of STS tooling and you really haven't provided enough information to know who might be able to help you.

[Silvana]

Sorry for not providing enough details about the problem constellation.

We augmented an Eclipse Helios SR1 amongst others with the following STS 2.5.2 features:
- Spring IDE Core and Spring IDE Core Developer Resources
- Spring IDE AOP Extension and Spring IDE AOP Developer Resources
- Spring IDE Security Extension and Spring IDE Security Developer Resources
- Spring IDE Web Flow Extension and Spring IDE Web Flow Extension Developer Resources
- SpringSource Tools Suite tc Server Tools

Furthermore we installed the Groovy Eclipse Plugin in version 2.1.1.xx-20101215-2100-e36.

Our project is a multi-module Maven2 project, wherein only one module has a Groovy nature. This module is dedicated for remote deployment and testing only.

The problem presents itself as whenever a developer performs a Maven clean build on the web-module the build breaks, since JARs get locked under WEB-INF/lib. As a consequence during "mvn clean" deleted sources/resources get removed from the deployment assembly. If now any resource in the web-project is modified, a NPE on Spring Project Builder is thrown.

Please notify me, if I still left anything unclear.

Regards
Silvana

[Kris De Volder]

Thanks, for more info. Mainly, I wanted to know if the Groovy Eclipse plugin is installed. It is, so it could be connected to the bug I pointed you to. The problem is caused by the Groovy compiler.

To confirm this is the same bug... you could try the following

- make sure no groovy files are open in any editor (when files are open in the editor the Groovy compiler is called upon to produce problem markers)
- turn of auto build

You could also try ununistalling the Groovy eclipse plugin and verify if this causes the problem to go away.

Be warned that as soon as any Groovy compilation gets invoked the problem may reappear (i.e. jars may get locked). This wouldn't usually be problem, unless you are on windows and trying to delete them.

The root of the problem is actually not caused by us, but is caused by URLClassLoader. You can read about it here if you are interested.

http://management-platform.blogspot....iles-open.html

This is actually a big problem for people on Windows systems. The problem essentially is that URLClassLoader doesn't really provide API for asking it close its jars.

It isn't usually a problem for commandline tools, because they run and exit, releasing all locks. But in an IDE, which keeps running it is a big problem.

Andy (our compiler Guru working on Groovy Eclipse) is trying some very freaky things to work around this problem and fix this issue. But unfortunately there is not much that can be done if you are hitting this problem now.

Once the problem is fixed in Groovy Eclipse the situation may improve for you.

But... since we (Groovy and Grails) may not be the only ones using URLClassLoaders (they are quiet widely used by many Java tools) I can't really say whether Groovy was in fact that one that locked your jars.

This is why it may be good to check if your problem is indeed caused by Greclipse, or some other component.

I'm sorry I couldn't be more helpful. I've provided you with as much information as I know about what I guess could be your problem.

Kris

[Andy Clement]

With the latest groovy-eclipse dev builds (from http://dist.codehaus.org/groovy/dist...snapshot/e3.6/ ) there is another way to determine if groovy compilation is to blame. If you close a groovy project it will now try to release all the locks it has. If you close your groovy project and see that the files are no longer locked, it is the issue we know about: https://issuetracker.springsource.com/browse/STS-1017

cheers
Andy
---
Andy Clement
SpringSource Tool Suite Team