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

Provide an option to import Gradle projects 'as is'

    Details

    • Type: New Feature New Feature
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.8.0.RELEASE
    • Fix Version/s: None
    • Component/s: GRADLE
    • Labels:
      None

      Description

      This comes from a discussion started in https://issuetracker.springsource.com/browse/STS-2175.

      The idea is that a user may want to import projects already fully configured with .classpath, .project etc. into STS without making any changes (except bringing them into the workspace).

      Currently it isn't possible to disable the addition of classpath container and related changes to the .classpath file.
      So even if all other options are turned off, the project's classpath will still be modified to

      • add classpath container
      • remove 'manual' library entries
      • reinitialize source folders as based on tooling API
      • add project dependencies

      Options should be provided to disable these changes (individually? or all at once).

        Activity

        Hide
        Mauro Molinari added a comment -

        My use case if that I may have shared the whole Gradle multiproject in the SCM, so if a member of the software development team will check it out, he will find it fully configured already.

        Ideally, the standard Eclipse "Import => File system => Existing project into workspace" would be enough, but it has the problem that it can't handle Gradle multiprojects correctly (especially if the master project is stored in the root of the physical structure of the multiproject).

        So, what I would need here is the following:

        • provide a checkbox to "import and do nothing" (you call it "hands off")
        • if that checkbox is NOT checked, individual checkboxes should be available to let the user choose what he/she wants the import wizard to perform; all these check boxes may be checked by default

        IMHO, the "run before", "run after" and "create resource filters" could also be moved into this group of checkboxes, because their semantic is the same (i.e.: do some processing to set up the imported Eclipse project).

        I would also add the following. The "run before" and "run after" features are great if you want to add the execution of custom tasks before and after the import. However, since the standard tasks the wizard proposes (cleanEclipse and eclipse in "before" and afterEclipseImport in "after) are probably standard actions that a user should accept most of the times (except for the "hands off" use case), they should probably be better handled by dedicated checkboxes, while leaving the edit box for "run before" and "run after" empty for the user to add only custom behaviour. Moreover, these check boxes for executing "cleanEclipse", "eclipse" and "afterEclipseImport" tasks may have a label (or at least a tooltip) that explains the user what they do to the project, rather than what tasks they will execute. In fact, from an Eclipse user point of view, it's not clear what will happen if I let the import wizard run those tasks or not, unless I go to the Gradle website and I read the documentation....

        Show
        Mauro Molinari added a comment - My use case if that I may have shared the whole Gradle multiproject in the SCM, so if a member of the software development team will check it out, he will find it fully configured already. Ideally, the standard Eclipse "Import => File system => Existing project into workspace" would be enough, but it has the problem that it can't handle Gradle multiprojects correctly (especially if the master project is stored in the root of the physical structure of the multiproject). So, what I would need here is the following: provide a checkbox to "import and do nothing" (you call it "hands off") if that checkbox is NOT checked, individual checkboxes should be available to let the user choose what he/she wants the import wizard to perform; all these check boxes may be checked by default IMHO, the "run before", "run after" and "create resource filters" could also be moved into this group of checkboxes, because their semantic is the same (i.e.: do some processing to set up the imported Eclipse project). I would also add the following. The "run before" and "run after" features are great if you want to add the execution of custom tasks before and after the import. However, since the standard tasks the wizard proposes (cleanEclipse and eclipse in "before" and afterEclipseImport in "after) are probably standard actions that a user should accept most of the times (except for the "hands off" use case), they should probably be better handled by dedicated checkboxes, while leaving the edit box for "run before" and "run after" empty for the user to add only custom behaviour. Moreover, these check boxes for executing "cleanEclipse", "eclipse" and "afterEclipseImport" tasks may have a label (or at least a tooltip) that explains the user what they do to the project, rather than what tasks they will execute. In fact, from an Eclipse user point of view, it's not clear what will happen if I let the import wizard run those tasks or not, unless I go to the Gradle website and I read the documentation....
        Hide
        Kris De Volder (c) added a comment -

        With the fixes for STS-2085 it should now be possible to turn off nearly all STS customizations to the project (all except for the addition of Gradle nature).

        Show
        Kris De Volder (c) added a comment - With the fixes for STS-2085 it should now be possible to turn off nearly all STS customizations to the project (all except for the addition of Gradle nature).
        Hide
        Mauro Molinari added a comment -

        So you mean that, if the Gradle nature is already there, no action at all is performed on the imported projects, don't you?

        Show
        Mauro Molinari added a comment - So you mean that, if the Gradle nature is already there, no action at all is performed on the imported projects, don't you?
        Hide
        Kris De Volder (c) added a comment -

        Yes, that should be the case.

        Show
        Kris De Volder (c) added a comment - Yes, that should be the case.
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        I haven't tried 2.9.0.RC1 yet, I'm still using 2.9.0.M2. Today I noticed one thing: when you import a Gradle multiproject, the Gradle DLSD support is turned on all the projects. This means that, if you import a multi-project which is under version control and with Gradle DSLD support turned off, you'll have a lot of modifications on your working copy after the import operation, because of the switch on of the DSLD support. This also means that the import operation silently adds the Groovy nature to all of your imported projects.
        So, I was wondering: is this still the case for 2.9.0.RC1? If so, I think this issue should be reopened.

        Show
        Mauro Molinari added a comment - Hi Kris, I haven't tried 2.9.0.RC1 yet, I'm still using 2.9.0.M2. Today I noticed one thing: when you import a Gradle multiproject, the Gradle DLSD support is turned on all the projects. This means that, if you import a multi-project which is under version control and with Gradle DSLD support turned off, you'll have a lot of modifications on your working copy after the import operation, because of the switch on of the DSLD support. This also means that the import operation silently adds the Groovy nature to all of your imported projects. So, I was wondering: is this still the case for 2.9.0.RC1? If so, I think this issue should be reopened.
        Hide
        Kris De Volder (c) added a comment -

        In the RC there is an option to not enable DSLD support in the import wizard.

        Show
        Kris De Volder (c) added a comment - In the RC there is an option to not enable DSLD support in the import wizard.
        Hide
        Mauro Molinari added a comment -

        Great, thank you!

        Show
        Mauro Molinari added a comment - Great, thank you!
        Hide
        Mauro Molinari added a comment -

        Hi Kris, I'm back

        I was finally able to upgrade my version of STS and now I'm on 3.1.0. So, I tested again my use case in which I need to import a Gradle multiproject "as is". The conclusion is that I still think an explicit option to import a project/multiproject "as is" would be needed, for at least two reasons:

        • it's not clear with the current UI of the import wizard how to obtain this result: for instance, should I check "enable dependency management"? I want my projects to use it, but I'd like STS to realize itself it's already enabled on them. So, should I check that box (that is: do enable dependency management) or not (that is: don't do anything, import what you find... after all, it's already enabled!)? In my last test, it seems like keeping it unchecked is the least intrusive option (i.e.: STS imports what it finds without doing anything) and I still find my projects with dependency management enabled, which is what I actually want; however, it's not so intuitive
        • partially as a consequence of the previous point, if I check any of the checkboxes (for example: enable dependency management or create resource filters), even if the corresponding operations may result in a no-op (because dependency management is already enabled or filters are already defined, for instance) the risk is to cause STS to change .settings/gradle/org.springsource.ide.eclipse.gradle.refresh.prefs and/or .settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs file contents: hence, once again, I end up with an imported project with outgoing changes (unless I add those files to the SCM ignored resources, however with big multiprojects it's annoying)

        I think it would be a lot simpler if there were a checkbox labelled "import projects as they are" (or something similar) which disables all the other checkboxes (except for the "create working set" one, which has no consequences on project contents and can be seen as a completely local preference) and makes the wizard behave as stated. Two major features would be:

        • saving this property to .settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs, so that, once this file is shared, all the team members can get this checkbox checked "by default" when importing the just checked out Gradle project/multiproject: this would be the complete solution to our use case (in which we have full Eclipse projects with Gradle nature shared in the SCM)
        • (alternative?) suggesting this checkbox as checked by default when the import wizard finds out that the projects you are going to import already contain some relevant project metadata (i.e.: Eclipse projects with Gradle nature)

        I'd appreciate your feedback on this.

        P.S.: great work has been done since version 2.8.x I was using before, thank you for your effort!

        Show
        Mauro Molinari added a comment - Hi Kris, I'm back I was finally able to upgrade my version of STS and now I'm on 3.1.0. So, I tested again my use case in which I need to import a Gradle multiproject "as is". The conclusion is that I still think an explicit option to import a project/multiproject "as is" would be needed, for at least two reasons: it's not clear with the current UI of the import wizard how to obtain this result: for instance, should I check "enable dependency management"? I want my projects to use it, but I'd like STS to realize itself it's already enabled on them. So, should I check that box (that is: do enable dependency management) or not (that is: don't do anything, import what you find... after all, it's already enabled!)? In my last test, it seems like keeping it unchecked is the least intrusive option (i.e.: STS imports what it finds without doing anything) and I still find my projects with dependency management enabled, which is what I actually want; however, it's not so intuitive partially as a consequence of the previous point, if I check any of the checkboxes (for example: enable dependency management or create resource filters), even if the corresponding operations may result in a no-op (because dependency management is already enabled or filters are already defined, for instance) the risk is to cause STS to change .settings/gradle/org.springsource.ide.eclipse.gradle.refresh.prefs and/or .settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs file contents: hence, once again, I end up with an imported project with outgoing changes (unless I add those files to the SCM ignored resources, however with big multiprojects it's annoying) I think it would be a lot simpler if there were a checkbox labelled "import projects as they are" (or something similar) which disables all the other checkboxes (except for the "create working set" one, which has no consequences on project contents and can be seen as a completely local preference) and makes the wizard behave as stated. Two major features would be: saving this property to .settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs, so that, once this file is shared, all the team members can get this checkbox checked "by default" when importing the just checked out Gradle project/multiproject: this would be the complete solution to our use case (in which we have full Eclipse projects with Gradle nature shared in the SCM) (alternative?) suggesting this checkbox as checked by default when the import wizard finds out that the projects you are going to import already contain some relevant project metadata (i.e.: Eclipse projects with Gradle nature) I'd appreciate your feedback on this. P.S.: great work has been done since version 2.8.x I was using before, thank you for your effort!
        Hide
        Kris De Volder (c) added a comment -

        Hi Mauro, thanks a lot for your feedback.

        The trouble with the gradle import wizard is that there are just so many different ways that a 'build-master' can set things up to work for their team members. I.e. some projects may choose not to share eclipse metadata at all and generate it from scratch on each import, some decide to share some of it, etc.

        To make the wizard support all the cases makes it complex (lot of checkboxes... and not always obvious to the average user which boxes they ought to check to have their particular set of projects import correctly).

        Also mainly, my wizard 'desing' if you can call it that, has mostly been made under the assumption that most of the metadata would be generated rather than shared in SCM. That's because this is what the projects I got exposed to earlier on (project like 'spring-integration' and 'spring-framework' are setup in this way.

        So you are providing a very interesting and challenging data point in that your setup is quite different

        I'm re-opening this issue. Adding some more explicit 'as is' option in the way you suggest seems useful. Maybe this option should only be allowed if project looks like it already has gradle tooling metadata (which can be checked quickly by looking for the gradle nature).

        Show
        Kris De Volder (c) added a comment - Hi Mauro, thanks a lot for your feedback. The trouble with the gradle import wizard is that there are just so many different ways that a 'build-master' can set things up to work for their team members. I.e. some projects may choose not to share eclipse metadata at all and generate it from scratch on each import, some decide to share some of it, etc. To make the wizard support all the cases makes it complex (lot of checkboxes... and not always obvious to the average user which boxes they ought to check to have their particular set of projects import correctly). Also mainly, my wizard 'desing' if you can call it that, has mostly been made under the assumption that most of the metadata would be generated rather than shared in SCM. That's because this is what the projects I got exposed to earlier on (project like 'spring-integration' and 'spring-framework' are setup in this way. So you are providing a very interesting and challenging data point in that your setup is quite different I'm re-opening this issue. Adding some more explicit 'as is' option in the way you suggest seems useful. Maybe this option should only be allowed if project looks like it already has gradle tooling metadata (which can be checked quickly by looking for the gradle nature).

          People

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

            Dates

            • Created:
              Updated:
              First Response Date: