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
    • Fix Version/s: 2.9.0.M2
    • 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
        Mauro Molinari added a comment -

        Hi Kris,
        yesterday and today I did some further tests:

        • yesterday I started Eclipse and STS started to refresh the dependencies of some projects
        • I waited for all the processes of refreshing, rebuilding, etc. to finish
        • then I closed Eclpise and tried to start it with -clean but I encountered the bug at https://bugs.eclipse.org/bugs/show_bug.cgi?id=365722
        • today I followed the advice described there: eclipse -clean actually deletes the folder in configuration/org.eclipse.osgi, so I deleted it manually
        • then, I started eclipse without -clean
        • unfortunately, once again STS started to refresh the dependencies of some projects

        I have some further info though:

        • first of all, if I look at the Project Explorer, as I said previously some projects have a library called "com.springsource.sts.gradle.classpathcontainer" instead of "Gradle Dependencies (persisted)"
        • for the same projects, the Package Explorer, instead, does NOT show any library (apart from the "JRE System Library")
        • but the strangest thing is that STS started to refresh the dependencies of one of the projects (call it "P1") that DID have "Gradle Dependencies (persisted)" library in it!!

        So I would have expected STS didn't refresh the dependencies for it in any case...

        However, there's one thing I haven't fully understood yet: when STS launches the Gradle API to refresh one project dependencies, does it actually refresh the dependencies for ALL the projects in the same Gradle multiproject?

        Show
        Mauro Molinari added a comment - Hi Kris, yesterday and today I did some further tests: yesterday I started Eclipse and STS started to refresh the dependencies of some projects I waited for all the processes of refreshing, rebuilding, etc. to finish then I closed Eclpise and tried to start it with -clean but I encountered the bug at https://bugs.eclipse.org/bugs/show_bug.cgi?id=365722 today I followed the advice described there: eclipse -clean actually deletes the folder in configuration/org.eclipse.osgi, so I deleted it manually then, I started eclipse without -clean unfortunately, once again STS started to refresh the dependencies of some projects I have some further info though: first of all, if I look at the Project Explorer, as I said previously some projects have a library called "com.springsource.sts.gradle.classpathcontainer" instead of "Gradle Dependencies (persisted)" for the same projects, the Package Explorer, instead, does NOT show any library (apart from the "JRE System Library") but the strangest thing is that STS started to refresh the dependencies of one of the projects (call it "P1") that DID have "Gradle Dependencies (persisted)" library in it!! So I would have expected STS didn't refresh the dependencies for it in any case... However, there's one thing I haven't fully understood yet: when STS launches the Gradle API to refresh one project dependencies, does it actually refresh the dependencies for ALL the projects in the same Gradle multiproject?
        Hide
        Kris De Volder (c) added a comment -

        > unfortunately, once again STS started to refresh the dependencies of some projects

        It was a long shot anyway. I as thinking it may have been some OSGI state got messed up that interferes with the plugin loading. Was worth a try.

        > for the same projects, the Package Explorer, instead, does NOT show any library (apart from the "JRE System Library")

        I have noticed this kind of thing also. If you happen to open a project before the container has been initiallized the package explorer won't show it. I think this is just an odd UI glitch in the package explorer view. Nothing to be concerned about. I think it simply doesn't bother displaying empty containers.
        Once the container is initialized. I found I have to 'refresh' the package explorer by right click on the project node (for example) and select 'Refresh'.

        > However, there's one thing I haven't fully understood yet: when STS launches the Gradle API to refresh one project dependencies, does it actually refresh the dependencies for ALL the projects in the same Gradle multiproject?

        Yes, and no. The underlying models that are used to populate the classpath containers are refreshed as a group, but the contents of each individual container is refreshed individually by JDT.

        This is because JDT manages the classpath containers and when to initialize them etc. So they get called when JDT decides it needs them, and I don't have much control over that.

        But the underlying Gradle model are very expensive to build and when you build the model for a multi-project you are actually building the models of all the projects in the multi-project. So whenever needing to build the model of a project say X, I also pro-actively insert all the related project models into project->model cache.

        This in itself will not cause the related project's classpath to update however.

        Nevertheless, I think it is possible that refreshing one project will trigger the update of a related projects contents as well. That is because if a project say 'core' is refreshed then JDT will probably also decide to refresh the classpaths for projects that depend on 'core'.

        But, these secondary refreshes should be 'cheap' and shouldn't result in an additional gradle model build, because the related models will already have been pre-cached.

        Some extra info since my last post: I have also recently seen refreshes happen on startup that I think shouldn't happen, but so far I still can't reliably reproduce it. I.e. I have actually seen it happen once when opening an old workspace I hadn't used in a while but can't find a reliably method to reproduce that behavior in a 'controlled' and 'fresh workspace' environment.

        Anyway, I'll work a bit today on replacing the internal JDT api I used for getting persisted values to something custom implemented. Hopefully that will make things work more reliably. I'll let you know when there's something for you to try.

        Show
        Kris De Volder (c) added a comment - > unfortunately, once again STS started to refresh the dependencies of some projects It was a long shot anyway. I as thinking it may have been some OSGI state got messed up that interferes with the plugin loading. Was worth a try. > for the same projects, the Package Explorer, instead, does NOT show any library (apart from the "JRE System Library") I have noticed this kind of thing also. If you happen to open a project before the container has been initiallized the package explorer won't show it. I think this is just an odd UI glitch in the package explorer view. Nothing to be concerned about. I think it simply doesn't bother displaying empty containers. Once the container is initialized. I found I have to 'refresh' the package explorer by right click on the project node (for example) and select 'Refresh'. > However, there's one thing I haven't fully understood yet: when STS launches the Gradle API to refresh one project dependencies, does it actually refresh the dependencies for ALL the projects in the same Gradle multiproject? Yes, and no. The underlying models that are used to populate the classpath containers are refreshed as a group, but the contents of each individual container is refreshed individually by JDT. This is because JDT manages the classpath containers and when to initialize them etc. So they get called when JDT decides it needs them, and I don't have much control over that. But the underlying Gradle model are very expensive to build and when you build the model for a multi-project you are actually building the models of all the projects in the multi-project. So whenever needing to build the model of a project say X, I also pro-actively insert all the related project models into project->model cache. This in itself will not cause the related project's classpath to update however. Nevertheless, I think it is possible that refreshing one project will trigger the update of a related projects contents as well. That is because if a project say 'core' is refreshed then JDT will probably also decide to refresh the classpaths for projects that depend on 'core'. But, these secondary refreshes should be 'cheap' and shouldn't result in an additional gradle model build, because the related models will already have been pre-cached. Some extra info since my last post: I have also recently seen refreshes happen on startup that I think shouldn't happen, but so far I still can't reliably reproduce it. I.e. I have actually seen it happen once when opening an old workspace I hadn't used in a while but can't find a reliably method to reproduce that behavior in a 'controlled' and 'fresh workspace' environment. Anyway, I'll work a bit today on replacing the internal JDT api I used for getting persisted values to something custom implemented. Hopefully that will make things work more reliably. I'll let you know when there's something for you to try.
        Hide
        Kris De Volder (c) added a comment -

        I've completely re-implemented the persistence support for Gradle's classpath containers.

        It should be available right now from the update site
        http://dist.springsource.com/snapshot/TOOLS/nightly/gradle/

        In some ways this should be more reliable (it just reads a particular file that nobody else is messing with except me, so the file should be there regardless of when my plugins get loaded.

        In other ways it could be more unstable since I had implement a bunch of stuff to save/load these infos from scratch. (It seems to work ok for me, but kindly give it a try

        If you run it on commandline you'll also see some debug-loggin output from my save participant (search for lines starting with "GradleSaveParticipant".

        I'll turn this off shortly, but left it on for now as it may help in case of problems.

        Show
        Kris De Volder (c) added a comment - I've completely re-implemented the persistence support for Gradle's classpath containers. It should be available right now from the update site http://dist.springsource.com/snapshot/TOOLS/nightly/gradle/ In some ways this should be more reliable (it just reads a particular file that nobody else is messing with except me, so the file should be there regardless of when my plugins get loaded. In other ways it could be more unstable since I had implement a bunch of stuff to save/load these infos from scratch. (It seems to work ok for me, but kindly give it a try If you run it on commandline you'll also see some debug-loggin output from my save participant (search for lines starting with "GradleSaveParticipant". I'll turn this off shortly, but left it on for now as it may help in case of problems.
        Hide
        Mauro Molinari added a comment -

        Hi Kris!
        I installed STS Gradle integration 2.9.0.201201110123-SNAPSHOT. Then I started my workspace three times:

        • the first time it refreshed my dependencies, because I think it had to convert the old persisted library to the new persistence format
        • the second and the third time the dependencies were not refreshed at startup!

        This is great news, because previously it happened 99% of the times. I will test this for some more days and let you know.

        BTW: when is STS Gradle integration 2.9.0 going to be released as stable? There are a lot of great improvements in it, so I look forward to adopting it in our production team.

        Show
        Mauro Molinari added a comment - Hi Kris! I installed STS Gradle integration 2.9.0.201201110123-SNAPSHOT. Then I started my workspace three times: the first time it refreshed my dependencies, because I think it had to convert the old persisted library to the new persistence format the second and the third time the dependencies were not refreshed at startup! This is great news, because previously it happened 99% of the times. I will test this for some more days and let you know. BTW: when is STS Gradle integration 2.9.0 going to be released as stable? There are a lot of great improvements in it, so I look forward to adopting it in our production team.
        Hide
        Kris De Volder (c) added a comment -

        Great. I'll close issue for now.

        I'm still a bit suspicious of all the new code I wrote for this. So please do let me know when there are any signs of things breaking with this latest snapshot.

        2.9.0.M2 is schedule for Jan 23
        2.9.0.final is scheduled around the beginning of march.

        Don't take that as promise that things will actually be released on those days. Delays are not unheard of

        Show
        Kris De Volder (c) added a comment - Great. I'll close issue for now. I'm still a bit suspicious of all the new code I wrote for this. So please do let me know when there are any signs of things breaking with this latest snapshot. 2.9.0.M2 is schedule for Jan 23 2.9.0.final is scheduled around the beginning of march. Don't take that as promise that things will actually be released on those days. Delays are not unheard of

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: