Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2352

Gradle dependencies refreshed whenever Eclipse starts

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.1.RELEASE, 3.6.4.RELEASE
    • Fix Version/s: 2.9.0.M2, 3.7.0.RELEASE
    • Component/s: GRADLE
    • Labels:
      None

      Description

      Whenever Eclipse starts, it happens very very often (but not always!) that the STS-Gradle integration refreshes the dependencies for at least some of the ~20 projects I have in the workspace.
      This is time consuming and IMHO useless: after a clean Eclipse shut-down, on the next start STS shouldn't refresh the dependencies, unless I tell it to do.

      While the Gradle build is in progress, I notice that, for those projects, the library containing the Gradle external dependencies is called "com.springsource.sts.gradle.classpathcontainer" instead of "Gradle Dependencies (persisted)". When the build completes, then the library name turns to "Gradle Dependencies".

      So, it seems like STS is not always persisting the Gradle Dependencies library configuration. Which is the criteria for this to occur?

      Real case example: I just started and closed Eclipse repeatedly for 4 times now, always on the same workspace, and:

      • the first three times, STS refreshed the dependencies of some of the projects at startup
      • the fourth time STS did not refresh the dependencies of any project

        Activity

        Hide
        Kris De Volder (c) added a comment -

        DSL support and the 'disable underlining' was removed from gradle tooling. Gradle tooling no longer has any dependencies on Greclipse, which was done in anticipation of the fact that Greclipse is/was no longer going to be supported.

        The persisted container you are seeing which is different from Gradle Dependencies was probably a DSL support container.

        Eclipse has saved its state in the workspace, probably a long time ago, when the DSL feature was still a part of Gradle tooling.

        When eclipse found this container ID is unknown and not contributed by any plugins you have currently installed, but nevertheless found some persisted state... it kindly created a 'generic' container and filled it with the persisted entries.

        That is my guess at least.

        Show
        Kris De Volder (c) added a comment - DSL support and the 'disable underlining' was removed from gradle tooling. Gradle tooling no longer has any dependencies on Greclipse, which was done in anticipation of the fact that Greclipse is/was no longer going to be supported. The persisted container you are seeing which is different from Gradle Dependencies was probably a DSL support container. Eclipse has saved its state in the workspace, probably a long time ago, when the DSL feature was still a part of Gradle tooling. When eclipse found this container ID is unknown and not contributed by any plugins you have currently installed, but nevertheless found some persisted state... it kindly created a 'generic' container and filled it with the persisted entries. That is my guess at least.
        Hide
        Mauro Molinari added a comment -

        I think you're correct. However, probably an "upgrade path" that cleanly removes that "obsolete" container from the classpath when upgrading the Gradle tooling plugin (or at least a warning message) would be better for the user. Otherwise, projects could be severely broken and it's not immediate to understand what has happened.

        Show
        Mauro Molinari added a comment - I think you're correct. However, probably an "upgrade path" that cleanly removes that "obsolete" container from the classpath when upgrading the Gradle tooling plugin (or at least a warning message) would be better for the user. Otherwise, projects could be severely broken and it's not immediate to understand what has happened.
        Hide
        Kris De Volder (c) added a comment -

        I see what you mean and its a valid point. But...

        I don't think I have time to implement this cleanup and old-project-scanning code. Done that kind of thing in the past and it invariably turns into a bit of a nasty piece of code that only serves a useful purpose for a short time, and then it just becomes something that just clutters up the code base and needlessly scans the workspace for 'old projects' at regular times (.e.g startup. project, creation etc).

        Also... in most/many use cases, I think, just running 'Refresh All' will cleanup the old containers when the 'cleanEclipse' task is executed.

        Anyhow.. I think you are right, in principle we'd want to 'be nice' and clean these up for the user somehow, but I'm not sure its really worth the effort.

        Show
        Kris De Volder (c) added a comment - I see what you mean and its a valid point. But... I don't think I have time to implement this cleanup and old-project-scanning code. Done that kind of thing in the past and it invariably turns into a bit of a nasty piece of code that only serves a useful purpose for a short time, and then it just becomes something that just clutters up the code base and needlessly scans the workspace for 'old projects' at regular times (.e.g startup. project, creation etc). Also... in most/many use cases, I think, just running 'Refresh All' will cleanup the old containers when the 'cleanEclipse' task is executed. Anyhow.. I think you are right, in principle we'd want to 'be nice' and clean these up for the user somehow, but I'm not sure its really worth the effort.
        Hide
        Mauro Molinari added a comment -

        I'm not sure I tried "Refresh All", but I'm certain "Refresh dependencies" does not fix this.
        Anyway, I understand your point of view, considering Pivotal won't invest more on these tools.
        Thanks for your support.

        Show
        Mauro Molinari added a comment - I'm not sure I tried "Refresh All", but I'm certain "Refresh dependencies" does not fix this. Anyway, I understand your point of view, considering Pivotal won't invest more on these tools. Thanks for your support.
        Hide
        Kris De Volder (c) added a comment -

        Refresh dependencies won't do it no. That just refreshes the contents of the "Gradle Dependencies" container.

        Refresh All, performs the same actions as if you deleted project from workspace and re-imported the project (more or less, but without actually deleting it). This will normally clear the eclipse metadata and rebuild it, but it depends a little on how your project is setup. (I.e. whether you have a project setup which executes 'cleanEclipse' task as part of the import).

        Show
        Kris De Volder (c) added a comment - Refresh dependencies won't do it no. That just refreshes the contents of the "Gradle Dependencies" container. Refresh All, performs the same actions as if you deleted project from workspace and re-imported the project (more or less, but without actually deleting it). This will normally clear the eclipse metadata and rebuild it, but it depends a little on how your project is setup. (I.e. whether you have a project setup which executes 'cleanEclipse' task as part of the import).

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Mauro Molinari
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: