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

Provide an option to import Gradle projects 'as is'

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • 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
        kdvolder Kris De Volder added a comment -

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

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

        Great, thank you!

        Show
        mauromol Mauro Molinari added a comment - Great, thank you!
        Hide
        mauromol 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
        mauromol 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
        kdvolder Kris De Volder 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
        kdvolder Kris De Volder 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).
        Hide
        mlippert Martin Lippert added a comment -

        Since we no longer pushing this project forward and recommend to use the Buidship project at Eclipse instead, I am closing this issue as won't fix.
        If you would like to add comments and/or re-open the issue, please file a new issue at https://github.com/spring-projects/eclipse-integration-gradle

        Show
        mlippert Martin Lippert added a comment - Since we no longer pushing this project forward and recommend to use the Buidship project at Eclipse instead, I am closing this issue as won't fix. If you would like to add comments and/or re-open the issue, please file a new issue at https://github.com/spring-projects/eclipse-integration-gradle

          People

          • Assignee:
            kdvolder Kris De Volder
            Reporter:
            kdvolder Kris De Volder
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: