Uploaded image for project: 'Spring Tool Suite'
  1. Spring Tool Suite
  2. STS-2175

Avoid changing the <classpathenty>s in .classpath of the main project (if not requested) when importing a Gradle multiproject

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Complete
    • 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: see STS-2174
      .settings/com.springsource.sts.gradle.core.import.prefs of the main project: see STS-2174
      .classpath of the main project: the order of the classpath entries related to the subprojects is not predictable

      I mean, repeating the project import over time shows that the <classpathentry>s in the .classpath file are changed every time: the content is the same, but the order of the different entries can change.

      Why the import wizard changes that file if I unchecked the execution of all the Eclipse Gradle plugin tasks? I would expect the wizard to just "mount" the projects, without touching the .classpath of the main project. This would be the best way to solve this problem, because if the .classpath is there (and is under version control), I assume I want it to be like that.

      If changing is unavoidable, at least please make the import wizard generate those <classpathentry>s in a predictable order: they may reflect the order in which dependencies are declared in the Gradle build script or, at least, some other sorting criteria (alphabetical on the subprojects name, for instance).

        Activity

        Hide
        kdvolder Kris De Volder added a comment -

        I'm just thinking, which default setting will work to make life easier for the largest percentage of user?

        My guess would be that largest number of users wouldn't be conscious or care about the order when writing the build script. And these users would be best served by having the entries sorted by the tooling.

        Anyhow, I tend to defer to the opinion of users on choices like this. So since you are the only user who I have an opinion for I'd probably follow your advice here. Though it would be reasuring to have more than one user's opion

        Anyhow, I'll leave it for a couple of days before implementing this.

        I'll reopen this issue now to remember there's something left to do.

        Show
        kdvolder Kris De Volder added a comment - I'm just thinking, which default setting will work to make life easier for the largest percentage of user? My guess would be that largest number of users wouldn't be conscious or care about the order when writing the build script. And these users would be best served by having the entries sorted by the tooling. Anyhow, I tend to defer to the opinion of users on choices like this. So since you are the only user who I have an opinion for I'd probably follow your advice here. Though it would be reasuring to have more than one user's opion Anyhow, I'll leave it for a couple of days before implementing this. I'll reopen this issue now to remember there's something left to do.
        Hide
        kdvolder Kris De Volder added a comment -

        TODO: make sorting / not sorting user configurable

        Show
        kdvolder Kris De Volder added a comment - TODO: make sorting / not sorting user configurable
        Hide
        d.cavestro Davide Cavestro added a comment -

        My guess would be that largest number of users wouldn't be conscious or care about the order when writing the build script. And these users would be best served by having the entries sorted by the tooling.

        PREMISE: I'm a co-worker of Mauro's (in fact we avoid voting each other bugs) so don't take my opinion for statistic purposes.
        That said, maybe it could be a reasonable choice implementing the entries sorted by the tooling as a default/first choice way, provided that the IDE remembers last user choice, so when the developer choose to preserve the gradle script original sorting, then it becomes the default choice for that environment.
        Just my two cents
        thank you for your promptness

        Cheers
        Davide

        Show
        d.cavestro Davide Cavestro added a comment - My guess would be that largest number of users wouldn't be conscious or care about the order when writing the build script. And these users would be best served by having the entries sorted by the tooling. PREMISE: I'm a co-worker of Mauro's (in fact we avoid voting each other bugs) so don't take my opinion for statistic purposes. That said, maybe it could be a reasonable choice implementing the entries sorted by the tooling as a default/first choice way, provided that the IDE remembers last user choice, so when the developer choose to preserve the gradle script original sorting, then it becomes the default choice for that environment. Just my two cents thank you for your promptness Cheers Davide
        Hide
        kdvolder Kris De Volder added a comment -

        Yes, I would imagine that we store sorting preference in the root project's settings. So the settings could be stored in SVN/CVS and shared between users... and will all apply to all projects in a given build.

        Show
        kdvolder Kris De Volder added a comment - Yes, I would imagine that we store sorting preference in the root project's settings. So the settings could be stored in SVN/CVS and shared between users... and will all apply to all projects in a given build.
        Hide
        kdvolder Kris De Volder added a comment -

        Committed a fix with regression test.

        There is now a project property page accesible by right click on a Gradle project. This allows setting whether entries should be sorted or maintain the order as returned by the build script.

        This preference is stored in the root project .settings so it is shared for all projects in the same hierarchy.

        Show
        kdvolder Kris De Volder added a comment - Committed a fix with regression test. There is now a project property page accesible by right click on a Gradle project. This allows setting whether entries should be sorted or maintain the order as returned by the build script. This preference is stored in the root project .settings so it is shared for all projects in the same hierarchy.

          People

          • Assignee:
            kdvolder Kris De Volder
            Reporter:
            mauromol Mauro Molinari
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: