GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-994

Groovy Nature Locks Jar Files in Project

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.1Release
    • Fix Version/s: None
    • Component/s: Project Settings
    • Labels:
      None
    • Environment:
      Windows 7 64 bit
      Eclipse 3.6 Helios 32 bit (or 64 bit)
      Java 1.6.0_22
      Groovy Eclipse Feature 2.1.1.xx-20101215
    • Number of attachments :
      0

      Description

      We've been struggling with an issue where jar files that are part of a software project we're working on become locked by the Eclipse.exe process (or Javaw.exe process if you have Eclipse configured to fork, rather than using the JNI libraries). We would expect the jar files to be locking when a new java process is spawned during a process run (e.g. if we launched Tomcat), but would not expect them to be locked by the IDE process.

      This causes issues for things like when we try to get new jars from our source control tool or if we wanted to delete the project. Since the Eclipse.exe process has them locked, the files can't be overwritten. (Yes, we're in Windows ;()

      We've been able to track this down to happening when the Java Product has the Groovy Nature enabled (Project | Configure | Convert to Groovy Project).

      I see that a person had a similar issue a while back that was fixed with 2.0.0 of the plug-in. Do you think that a similar issue might have snuck back in in the 2.1 releases? I'm a callow user of the tools, but from what I can tell, the issue referenced here was the use of a URLClassloader class.

      If this is familiar to anyone, we'd appreciate any insight or help.

      http://jira.codehaus.org/browse/GRECLIPSE-13?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs

      Windows 7 64 bit
      Eclipse 3.6 Helios 32 bit (or 64 bit)
      Java 1.6.0_22
      Groovy Eclipse Feature 2.1.1.xx-20101215

        Activity

        Hide
        Andy Clement added a comment -

        > 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.

        Show
        Andy Clement added a comment - > 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.
        Hide
        Mauro Molinari added a comment -

        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)

        Show
        Mauro Molinari added a comment - 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)
        Hide
        Andy Clement added a comment -

        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.

        Show
        Andy Clement added a comment - 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.
        Hide
        rupert thurner added a comment -
        Show
        rupert thurner added a comment - fyi, windows should allow to open files with the flag FILE_SHARE_DELETE, which then allows the file to be deleted even when the handle is open: https://groups.google.com/forum/#!searchin/msysgit/FILE_SHARE_DELETE/msysgit/Iu0-uyX3dlQ/nl5WK6jjs2YJ http://blogs.msdn.com/b/oldnewthing/archive/2004/06/07/150047.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
        Hide
        Tom Dunstan added a comment -

        This is still a big pain on Windows. Using Eclipse 4.4 with Groovy-Eclipse 2.9.0.xx-201407142235-e44-RELEASE and using the 2.1 compiler still locks jar files, even with -Dgreclipse.nonlocking=true. Even closing the project that the jar file is referenced from doesn't unlock it - nothing short of restarting eclipse works.

        This makes updating jars in dependent projects a nightmare. My edit-debug cycle looks like:

        • edit Project A
        • publish Project A jars
        • stop various servers running inside eclipse (Project B)
        • restart eclipse
        • while restarting, update copy of Project A jar that eclipse was referencing in Project B
        • Once eclipse has restarted, re-start Project B servers etc
        • test

        It should be:

        • edit Project A
        • publish Project A jars
        • update copy of Project A jar that eclipse was referencing in Project B
        • refresh Project B
        • test
        Show
        Tom Dunstan added a comment - This is still a big pain on Windows. Using Eclipse 4.4 with Groovy-Eclipse 2.9.0.xx-201407142235-e44-RELEASE and using the 2.1 compiler still locks jar files, even with -Dgreclipse.nonlocking=true. Even closing the project that the jar file is referenced from doesn't unlock it - nothing short of restarting eclipse works. This makes updating jars in dependent projects a nightmare. My edit-debug cycle looks like: edit Project A publish Project A jars stop various servers running inside eclipse (Project B) restart eclipse while restarting, update copy of Project A jar that eclipse was referencing in Project B Once eclipse has restarted, re-start Project B servers etc test It should be: edit Project A publish Project A jars update copy of Project A jar that eclipse was referencing in Project B refresh Project B test

          People

          • Assignee:
            Unassigned
            Reporter:
            Mac Noland
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: