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

Avoid writing the timestamp when creating (or at least updating...) com.springsource.sts.gradle.core.prefs and com.springsource.sts.gradle.core.import.prefs

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.M2
    • Fix Version/s: 2.9.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      Assume you have a Gradle multiproject and that it is under version control.
      Suppose this project is already an Eclipse project and all the Eclipse metadata files (.project, .classpath, .settings folder, etc.) are under version control.
      You check it out in a folder and then use the STS Gradle Import Wizard to import in a new repository.
      Suppose you UNCHECK all the following: run before, run after and create resource filters.
      You do that because you know that all the necessary data are already there, because the whole thing is under version control: so, you just want to "mount" the main project and all the subprojects into the workspace. (note: ideally, you may use the standard Import Existing Project into workspace, but you can't because the main project, which is at the root of the Gradle multiproject, is hiding the subprojects).

      After the import process has finished, even if you chose not to do anything special, you'll see some outgoing changes in the workspace:

      • .settings/com.springsource.sts.gradle.core.prefs for all the subprojects: they have outgoing changes because the import wizard changes the timestamp in the first line of the file, with the import time
      • .settings/com.springsource.sts.gradle.core.import.prefs of the main project: same problem as above, the timestamp is updated
      • .classpath of the main project: the order of the classpath entries is not predictable (I'll open a new issue for this)

      So, my request is: avoid to change the timestamp in the prefs files (is the timestamp needed at all?) when you import the projects. Or, at least, avoid to change it if no changes to the prefs file is actually needed.

        Activity

        Hide
        Kris De Volder (c) added a comment -

        The timestamp is added automatically by the API that's used for writing the file. However, it is probably a good idea to perform a check and not write the file unless some of the contents has actually changed. That way the timestamp will only change if something else also changed.

        Show
        Kris De Volder (c) added a comment - The timestamp is added automatically by the API that's used for writing the file. However, it is probably a good idea to perform a check and not write the file unless some of the contents has actually changed. That way the timestamp will only change if something else also changed.
        Hide
        Kris De Volder (c) added a comment -

        I'm debugging into this. The funny thing is that I already have some checks in place that supposed to not write the file if nothing is being changed.
        That code is working properly and my code to write the file is not being called. Nevertheless the timestamp is being changed behind my back by Eclipse
        preferences infrastructure.

        I'm not sure why exactly Eclipse is doing that.

        However, it looks like the code that is annyingly changing time stamps beind my back is only activated when Eclipse finds files inside of the special ".settings" folders. An easy way to avoid this interference from Eclipse would be to move the settings files for gradle tooling elsewhere. I'm thinking
        $

        {project}

        /.gradle-sts-settings.

        Show
        Kris De Volder (c) added a comment - I'm debugging into this. The funny thing is that I already have some checks in place that supposed to not write the file if nothing is being changed. That code is working properly and my code to write the file is not being called. Nevertheless the timestamp is being changed behind my back by Eclipse preferences infrastructure. I'm not sure why exactly Eclipse is doing that. However, it looks like the code that is annyingly changing time stamps beind my back is only activated when Eclipse finds files inside of the special ".settings" folders. An easy way to avoid this interference from Eclipse would be to move the settings files for gradle tooling elsewhere. I'm thinking $ {project} /.gradle-sts-settings.
        Hide
        Kris De Volder (c) added a comment -

        I've committed a fix. The fix now puts the gradle project related prefs files in a folder that doesn't have special meaning to Eclipse. (.gradle-sts-settings).

        A bit of 'legacy conversion' code was added to move files from the old location (if they exist) to the new location.

        Show
        Kris De Volder (c) added a comment - I've committed a fix. The fix now puts the gradle project related prefs files in a folder that doesn't have special meaning to Eclipse. (.gradle-sts-settings). A bit of 'legacy conversion' code was added to move files from the old location (if they exist) to the new location.
        Hide
        Mauro Molinari added a comment - - edited

        Great Kris, thank you! What's the fix version for this?

        On the other hand, how the conversion is going to be applied? The next version you import the project with the import wizard?

        Show
        Mauro Molinari added a comment - - edited Great Kris, thank you! What's the fix version for this? On the other hand, how the conversion is going to be applied? The next version you import the project with the import wizard?
        Hide
        Mauro Molinari added a comment -

        You say:
        >it looks like the code that is annyingly changing time stamps beind my back is only activated when Eclipse finds files inside of the special ".settings" folders

        The strange thing is that I have other prefs files in the .settings folders of the projects, but only those of gradle-sts are changed after the import process.
        Maybe the timestamp is changed as soon as you try to access those property files, even if you don't write to them?

        Yes, of course it would be hard to know if something has changed or not if you can't read the contents of those files! :-D

        Show
        Mauro Molinari added a comment - You say: >it looks like the code that is annyingly changing time stamps beind my back is only activated when Eclipse finds files inside of the special ".settings" folders The strange thing is that I have other prefs files in the .settings folders of the projects, but only those of gradle-sts are changed after the import process. Maybe the timestamp is changed as soon as you try to access those property files, even if you don't write to them? Yes, of course it would be hard to know if something has changed or not if you can't read the contents of those files! :-D
        Hide
        Kris De Volder (c) added a comment -

        Thanks for catching that I forgot to set the 'fix version' field.

        It will be in 2.9.0.M1. Also will be available from the nightly update site after the next successful nightly build of the gradle tooling here:

        http://dist.springsource.com/snapshot/TOOLS/nightly/gradle

        FYI, we seem to be having some problem with the nightly builds at the moment. I'll post a note here when its fixed and there's something you can try out if you wish (to confirm whether it fixes your problems).

        Show
        Kris De Volder (c) added a comment - Thanks for catching that I forgot to set the 'fix version' field. It will be in 2.9.0.M1. Also will be available from the nightly update site after the next successful nightly build of the gradle tooling here: http://dist.springsource.com/snapshot/TOOLS/nightly/gradle FYI, we seem to be having some problem with the nightly builds at the moment. I'll post a note here when its fixed and there's something you can try out if you wish (to confirm whether it fixes your problems).
        Hide
        Kris De Volder (c) added a comment -

        About the conversion... it will happen automatically the first time the XXX.prefs file is being read by STS.
        It will first look in the old location.
        Then in the new location.

        There are two cases:

        • If a file exist in the old but not the new location, it will be moved.
        • If a file exists in both locations the old one will be deleted.

        If you are worried this 'conversion' may cause trouble, please don't hesitate to voice concerns. I'm certainly open to changing or disable that functionality if you believe its better not to try to be smart
        about this (but it might be confusing to have the settings in both places where one of them is basically 'defunct').

        Show
        Kris De Volder (c) added a comment - About the conversion... it will happen automatically the first time the XXX.prefs file is being read by STS. It will first look in the old location. Then in the new location. There are two cases: If a file exist in the old but not the new location, it will be moved. If a file exists in both locations the old one will be deleted. If you are worried this 'conversion' may cause trouble, please don't hesitate to voice concerns. I'm certainly open to changing or disable that functionality if you believe its better not to try to be smart about this (but it might be confusing to have the settings in both places where one of them is basically 'defunct').
        Hide
        Mauro Molinari added a comment -

        No, I don't see any problem on the new solution. I was just elaborating the fact that the .settings place should have been the "right" one (I mean, I find other plugins pref files there), but if we have this problem of the timestamp changing while just reading the pref file, we can't do any different.

        Thank you Kris!

        Show
        Mauro Molinari added a comment - No, I don't see any problem on the new solution. I was just elaborating the fact that the .settings place should have been the "right" one (I mean, I find other plugins pref files there), but if we have this problem of the timestamp changing while just reading the pref file, we can't do any different. Thank you Kris!
        Hide
        Kris De Volder (c) added a comment -

        The problem is that I wrote my own code for reading and working with the prefs files that doesn't use the Eclipse APIs. The reason for it is that Eclipse is annoyingly picky... so you cannot read the prefs files unless a project is open and imported. This is a bit problematic if the prefs actually contain import prefererences.

        Unfortunately, by doing this, it seems I'm confusing eclipse when it sees the files appearing there on a refresh it ends up updating the timestamps. I think this is probably a bug in Eclipse, but the bug probably only happens because of my "unusual" way of reading and writing the prefs.

        I think it might work if I put the files in

        .settings/gradle/<blah>.prefs

        Because the eclipse code that is 'confused' and setting timestamps is specific about the length of the path being exactly 3 so putting stuff in a subfolder of .settings will probably also avoid the problem.

        You think that would be nicer?

        Show
        Kris De Volder (c) added a comment - The problem is that I wrote my own code for reading and working with the prefs files that doesn't use the Eclipse APIs. The reason for it is that Eclipse is annoyingly picky... so you cannot read the prefs files unless a project is open and imported. This is a bit problematic if the prefs actually contain import prefererences. Unfortunately, by doing this, it seems I'm confusing eclipse when it sees the files appearing there on a refresh it ends up updating the timestamps. I think this is probably a bug in Eclipse, but the bug probably only happens because of my "unusual" way of reading and writing the prefs. I think it might work if I put the files in .settings/gradle/<blah>.prefs Because the eclipse code that is 'confused' and setting timestamps is specific about the length of the path being exactly 3 so putting stuff in a subfolder of .settings will probably also avoid the problem. You think that would be nicer?
        Hide
        Mauro Molinari added a comment -

        Maybe it would be "nicer", or at least more "standard"...
        If I could choose, I would prefer your last solution, anyway do what you feel is better

        Thank you!

        Show
        Mauro Molinari added a comment - Maybe it would be "nicer", or at least more "standard"... If I could choose, I would prefer your last solution, anyway do what you feel is better Thank you!
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        just to be sure: what's the state on this? Did you decide to go for the .settings/gradle/<blah>.prefs solution? Is it already available in the latest nightly builds?

        Show
        Mauro Molinari added a comment - Hi Kris, just to be sure: what's the state on this? Did you decide to go for the .settings/gradle/<blah>.prefs solution? Is it already available in the latest nightly builds?
        Hide
        Kris De Volder (c) added a comment -

        I think I will, (assuming it works). But haven't gotten round to it yet.

        Show
        Kris De Volder (c) added a comment - I think I will, (assuming it works). But haven't gotten round to it yet.
        Hide
        Kris De Volder (c) added a comment -

        OK, I just committed a change, settings files are now under .settings/gradle/<blah>.prefs

        You'll need to wait for a succesfull nightly build, so probably tomorrow it should be on the update site.

        I haven't added any code to cleanup the .gradle-sts-settings. I figure it isn't worth it since no version was ever really officially released yet that uses that location. So you'll have to delete or move those files manually.

        Show
        Kris De Volder (c) added a comment - OK, I just committed a change, settings files are now under .settings/gradle/<blah>.prefs You'll need to wait for a succesfull nightly build, so probably tomorrow it should be on the update site. I haven't added any code to cleanup the .gradle-sts-settings. I figure it isn't worth it since no version was ever really officially released yet that uses that location. So you'll have to delete or move those files manually.
        Hide
        Mauro Molinari added a comment -

        Thank you Kris!

        Show
        Mauro Molinari added a comment - Thank you Kris!

          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: