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
        Mauro Molinari added a comment -

        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.

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

          People

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

            Dates

            • Created:
              Updated: