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
        Kris De Volder (c) added a comment -

        That is odd. I have not seen this. It should use the persisted values each time.

        Now... I don't fully know the criteria for the persistence to happen, because I'm using values automatically persisted by Eclipse to initialize on next startup.

        I.e. my code is only in charge of the initialization, not the persisting itself.

        Are there any suspicious messages in the error log?

        I'll play around a little myself with closing/opening Eclipse and see if I can reproduce.

        Show
        Kris De Volder (c) added a comment - That is odd. I have not seen this. It should use the persisted values each time. Now... I don't fully know the criteria for the persistence to happen, because I'm using values automatically persisted by Eclipse to initialize on next startup. I.e. my code is only in charge of the initialization, not the persisting itself. Are there any suspicious messages in the error log? I'll play around a little myself with closing/opening Eclipse and see if I can reproduce.
        Hide
        Kris De Volder (c) added a comment -

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

        That is interesting. I've also seen this, but it happened when the gradle tooling isn't installed. I.e. I have seen: this when the gradle plugins aren't there. In that case we are getting a 'generic' classpath container initializer from JDT instead of our own.

        Maybe what is happening is something based on the order in which plugins get loaded.... could be the classpath containers are being initialized somehow before the gradle plugins have been properly loaded by Eclipse.

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

        You did wait to close eclipse until after the refresh was completed... right? (I would guess so, just checking

        Show
        Kris De Volder (c) added a comment - >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)". That is interesting. I've also seen this, but it happened when the gradle tooling isn't installed. I.e. I have seen: this when the gradle plugins aren't there. In that case we are getting a 'generic' classpath container initializer from JDT instead of our own. Maybe what is happening is something based on the order in which plugins get loaded.... could be the classpath containers are being initialized somehow before the gradle plugins have been properly loaded by Eclipse. Question: You said: > Real case example: I just started and closed Eclipse repeatedly for 4 times now, always on the same workspace, and: You did wait to close eclipse until after the refresh was completed... right? (I would guess so, just checking
        Hide
        Kris De Volder (c) added a comment -

        I've been playing around with this, closing opening STS with a bunch of Gradle projects in the workspace. Even tried doing refresh dependencies just before closing STS.

        So far I haven't been able to reproduce this. It is working fine for me.

        The fact that you are seeing "com.springsource.sts.gradle.classpathcontainer" instead of a more descriptive string seems like a hint it may have something to do with OSGI and plugin loading. But I have never seen this label for a Gradle classpath container unless the plugins where simply not installed.

        Still, my best guess for now is that, maybe in your setup the loading of the Gradle plugin containing the container initializer contribution is delayed for some reason. And by the time it runs, the persisted state for the container state from JDT is no longer avaible because a generic container was initially used in its place.

        One thing worth a try, if you keep seeing this problem, is try to run STS with a -clean option to clean out OSGI state... Just to see if that makes any difference.

        For now I won't do anything about this but if it keeps bugging you, I may consider implementing my own persisting logic instead of borrowing the persisted container state from JDT. That should be more reliable even if plugin loading is delayed for whatever reason.

        Show
        Kris De Volder (c) added a comment - I've been playing around with this, closing opening STS with a bunch of Gradle projects in the workspace. Even tried doing refresh dependencies just before closing STS. So far I haven't been able to reproduce this. It is working fine for me. The fact that you are seeing "com.springsource.sts.gradle.classpathcontainer" instead of a more descriptive string seems like a hint it may have something to do with OSGI and plugin loading. But I have never seen this label for a Gradle classpath container unless the plugins where simply not installed. Still, my best guess for now is that, maybe in your setup the loading of the Gradle plugin containing the container initializer contribution is delayed for some reason. And by the time it runs, the persisted state for the container state from JDT is no longer avaible because a generic container was initially used in its place. One thing worth a try, if you keep seeing this problem, is try to run STS with a -clean option to clean out OSGI state... Just to see if that makes any difference. For now I won't do anything about this but if it keeps bugging you, I may consider implementing my own persisting logic instead of borrowing the persisted container state from JDT. That should be more reliable even if plugin loading is delayed for whatever reason.
        Hide
        Mauro Molinari added a comment - - edited

        > You did wait to close eclipse until after the refresh was completed... right? (I would guess so, just checking

        Yes, of course: I closed Eclipse after the refresh was completed.

        I will have a look at the logs next time I see this problem and I'll also try the -clean command line argument (I'm on holiday right now).

        Maybe the loading order of plugins is determined by the fact that I have a lot of Eclipse plugin installed?

        Show
        Mauro Molinari added a comment - - edited > You did wait to close eclipse until after the refresh was completed... right? (I would guess so, just checking Yes, of course: I closed Eclipse after the refresh was completed. I will have a look at the logs next time I see this problem and I'll also try the -clean command line argument (I'm on holiday right now). Maybe the loading order of plugins is determined by the fact that I have a lot of Eclipse plugin installed?
        Hide
        Kris De Volder (c) added a comment -

        > Maybe the loading order of plugins is determined by the fact that I have a lot of Eclipse plugin installed?

        The fact that you have more plugins installed could definitely have an effect on plugin loading. I essentially only instal STS + greclipse + gradle plugins.

        Show
        Kris De Volder (c) added a comment - > Maybe the loading order of plugins is determined by the fact that I have a lot of Eclipse plugin installed? The fact that you have more plugins installed could definitely have an effect on plugin loading. I essentially only instal STS + greclipse + gradle plugins.
        Hide
        Mauro Molinari added a comment -

        If you wish, I may prepare an Eclipse bundle for you with all the plugins I'm using, so that you can download it and test.
        If so, please tell me your operating system (possibily Win32, Win64 or Linux x86_64/GTK 2... I can't work on other systems).

        Show
        Mauro Molinari added a comment - If you wish, I may prepare an Eclipse bundle for you with all the plugins I'm using, so that you can download it and test. If so, please tell me your operating system (possibily Win32, Win64 or Linux x86_64/GTK 2... I can't work on other systems).
        Hide
        Kris De Volder (c) added a comment -

        That's alright. Just give the -clean option a try. I'd just want to rule out that its somehow caused by a corrupted osgi/p2. If that's not the cause I think I just need to byte the bullet and implement the persistence logic properly myself, instead of borrowing some internal JDT API for doing this.

        If I implement it myself I should have better control over when/what gets persisted and it won't be as brittle in terms of plugin loading order or what not.

        Show
        Kris De Volder (c) added a comment - That's alright. Just give the -clean option a try. I'd just want to rule out that its somehow caused by a corrupted osgi/p2. If that's not the cause I think I just need to byte the bullet and implement the persistence logic properly myself, instead of borrowing some internal JDT API for doing this. If I implement it myself I should have better control over when/what gets persisted and it won't be as brittle in terms of plugin loading order or what not.
        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: