Groovy Nature Locks Jar Files in Project

Hi, this is a known current problem. The work on this issue is being done under https://issuetracker.springsource.com/browse/STS-1017 against STS (STS is just where the problem was hit, it is indeed a groovy-eclipse problem). With the latest groovy-eclipse you can confirm you are hitting the problem we know about by closing the project - if you close it and the locks are released, it is the same issue.

Yes, it is due to URLClassLoader, and it is due to the groovy compiler supporting ast transforms.

Thanks Andy! Looks to be exactly the issue we're running up to. We'll look forward to getting the fix when ready.

I'm trying something out in the latest dev build. If you install it and then set this system property when starting eclipse (can be set in the .ini file or after 'vmargs' with '-vmargs -Dgreclipse.nonlocking=true') then it will attempt to use a nonlocking classloader.

greclipse.nonlocking=true

Please give it a try.

Say, this is embarrassing, but do you have the direct link to the nightly build? For some reason, I can't seem to track it down. (User error I'm sure.)

No problem, snapshots are here at our eclipse snapshot update site (for eclipse 3.6):
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

Thanks Andy. Looks like this is behaving as we'd expect. No locking files!!!!

Thanks so much for your prompt feedback and helping us track down the issue. There are hundreds of us here, but I’ll have a few try the nightly build. Then wait for the next release before we have the masses upgrade.

Thanks again.

Thanks for trying it out. The next release is not far off (days, maybe week or two at most).

With enough positive feedback I might make it the default on Windows (or at least promote the system property to a UI configuration option).

OK to close this bug now?

Yep, I think we're good to go! Thanks for your help with this.

Hi,
today I was able to identify the source of my problem (JARs in the classpath locked) by adding the Groovy nature on one of my test projects! So here I am.

Reading your comments I would expect this problem to be fixed, however I'm using Groovy Eclipse 2.5.1 and I'm still having JARs locked. This is especially annoying when you need to delete a JAR in WebContent/WEB-INF/lib and you can't because that JAR is in the classpath and hence it is locked by Groovy Eclipse. We have an application where JARs are in a Subversion repository: every time a JAR is deleted from the remote repository, updating the local working copy is a pain because of this problem.

Using -Dgreclipse.nonlocking=true does work, however I knew about it only once I have come here. I would expect the use of non-locking classloaders to be the default setting or, at least, I would expect to find an option "Use nonlocking classloaders", just like there's one for STS in the Spring page of the project preferences (already checked in my case, so it was hard to determine that Groovy Eclipse was the actual source of my problems).

However, I also think that having so many "Use nonlocking classloaders" (unchecked by default) can be confusing and uncomfortable. Is there any good reason to keep locks on the classpath JARs, considering the side effects it causes?

Thanks!

> Is there any good reason to keep locks on the classpath JARs, considering the side effects it causes?

Performance can be potentially be awful with this mode active. The current implementation of the non locking support that we are using doesn't do very much caching, so choosing to switch to non-locking mode will potentially slow down everything involving access of those jars, which is usually type lookups during compilation.

I agree we need some UI to tweak this setting, rather than a system property.

There must be another way to go... why can't you cache without locking the JARs?

Given the side effects it produces, locking JARs in this way causes a severe usability problem under Windows.

> why can't you cache without locking the JARs?

We used a third party bit of software to quickly provide some solution to this. Yes, of course caching could be done, but we'd have to get familiar with this bit of code we picked up and implement it - we haven't got space in our schedule to do this work right now.

Is at least -Dgreclipse.nonlocking=true supposed to work with GRECLIPSE 2.5.2.xx-20110929-1800-e37? Because I still have locks on JARs even if I'm specifying it... (I made sure it was passed as a system property by connecting to my Eclipse instance using JVisualVM)

non locking should work in that 2.5.2 release. If the property is picked up you should hopefully see this:

property set: greclipse.nonlocking: will try to avoid locking jars

in your logs (might have to start with -consolelog or look in .metadata/.log)

if you have a failing scenario you can share with me (a project), please attach it.