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

Support a 'generate eclipse files only' mode

    Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.8.0.M1
    • Fix Version/s: 2.9.0.RC1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      Some users who have very customized build scripts may prefer to not use the classpath container and related dependency management at all.

      Instead, they may just want to rely on running the gradle eclipse task to generate eclipse configuration for their projects instead.

      A 'generate only' mode would probably only do limited modifications to the generated files, like adding a gradle nature.

      It should be possible to

      • to chose a 'generate only' option in the wizard.
      • easily refresh project configuration by invoking the task again and resynching the generated resources in the project with Eclipse workspace state.

        Activity

        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        after some thoughts I think that this new approach to the handling of Gradle projects (without the "Gradle Dependencies" classpath-container) may help in complex situations like those in STS-2186, assuming Gradle "eclipse" and "eclipse-wtp" plugins does not have bugs.
        I will do some tests and see...

        Show
        Mauro Molinari added a comment - Hi Kris, after some thoughts I think that this new approach to the handling of Gradle projects (without the "Gradle Dependencies" classpath-container) may help in complex situations like those in STS-2186 , assuming Gradle "eclipse" and "eclipse-wtp" plugins does not have bugs. I will do some tests and see...
        Hide
        Kris De Volder (c) added a comment -

        I presume that even if there are some bugs in the gradle eclise and eclipse-wtp plugins, this would still allow a 'gradle power user' to work around the bugs by applying some fixes in their build script.

        The idea behind the 'no class path container' mode is that STS will assume the build script already works without the tooling and so we will just try to use what it produces 'as is' as much as possible.

        For now, I think it is really the best solution we have without proper Gradle tooling API to support anything beyond pure java projects.

        Let me know how it works for you

        Cheers,

        Kris

        Show
        Kris De Volder (c) added a comment - I presume that even if there are some bugs in the gradle eclise and eclipse-wtp plugins, this would still allow a 'gradle power user' to work around the bugs by applying some fixes in their build script. The idea behind the 'no class path container' mode is that STS will assume the build script already works without the tooling and so we will just try to use what it produces 'as is' as much as possible. For now, I think it is really the best solution we have without proper Gradle tooling API to support anything beyond pure java projects. Let me know how it works for you Cheers, Kris
        Hide
        Mauro Molinari added a comment - - edited

        Hi Kris,
        I hope this is the right place for these considerations. If not, please tell me where I should better write them.

        I reflected a lot on this "dependency management-less" mode after you implemented it. Recently I had the opportunity to work on a multiproject which is smaller than the one for which I bombarded you with issues (), but with interesting characteristics. I even pushed myself towards the direction to completely disable STS to handle my imported Eclipse projects, to see what it would mean. I could do this because the multiproject is made up of only 3 subprojects (+ the master one) and I could use a flat layout for it. This allowed me to:

        • import projects into the workspace using the "import existing project into the workspace" wizard: this is impossible when you use the hierarchical multiproject layout
        • avoid to cope with many other annoyances the hierarchical layout imposes due to the lack of hierarchical project structure support in Eclipse

        Anyway, apart from this, I think I could make myself a better idea on what it means to work without STS handling my dependencies.

        First of all, I found a little annoyance: http://issues.gradle.org/browse/GRADLE-2293. Similar problems have been already fronted and fixed by you in STS (do you remember STS-2174?) and they come into play when the projects are shared into an SCM.

        Another "small" problem ("small" because I think it will be solved when http://issues.gradle.org/browse/GRADLE-2123 is fixed) is that dependencies of a 'war'+'eclipse-wtp' project are currently configured in a way that prevent Gradle from providing the sources of the JARs on which my Eclipse WTP project depends on. This is actually the area in which the "dependency management-less" mode was more promising for me to solve complex project setups that are described in STS-2186 and whose resolution in STS would need some work that also needs propaedeutic improvements on Gradle's counterpart, partially discussed recently by you and Szczepan Faber on http://issues.gradle.org/browse/GRADLE-1777.

        But the major problem, for which I don't think there will ever by an effective solution in "dependency management-less" mode, arises again when you are sharing your projects in a SCM repository: when you let Gradle "eclipse" and "eclipse-wtp" plugins alone to handle dependencies, they configure your Eclipse project classpath with hard references to JAR files in your local filesystem. This means that if team member A and team member B check out the same shared Eclipse project on their systems, they must issue a "Refresh dependencies" on the project after checking it out (and this is not a problem) and the result of this operation leads to two different .classpath files (and maybe others, when WTP is involved) on A's and B's local working copies. This is bad, since unwanted changes are always generated whenever a dependency refresh is issued by any team member.
        This is not the case when STS dependency management is enabled, because apart from sharing an Eclipse setup where the STS container is in the projects' build path, JARs are then resolved dynamically by STS and no hard references to the local physical location of JARs are saved in the shared project files.

        This is an extremely important plus of the "dependency management-enabled" mode and I don't think there is any easy way to fix the "dependecy management-less" mode to handle this use case in the right way, other than adopting an approach similar to the one STS is already providing with its "Gradle Dependencies" container (and hence with the "dependency management-enabled" mode).

        In a "Gradle-ideal" world, maybe one may think about the possibility to just share Gradle projects and source files and let "gradle eclipse" to generate all the necessary Eclipse project setup for you whenever you check out your project from the SCM repository, without sharing the generated Eclipse project configuration files. However, I don't think this is a viable solution, since there are a lot of other project configuration aspects (like: build path inclusion/exclusions, formatter and convention settings, other Java editor settings and in general any project-specific configuration overriding) that can (or even must) be shared among the team members and hence Eclipse project configuration data must be shared together with the Gradle project and source files (unless you accept to miss all these features).

        For now, this is the result of my experiments. I'd like to know what you think about it... and I hope I have given my contribution to retain you from evaluating the drop of the "dependency management-enabled" mode in STS

        Mauro.

        Show
        Mauro Molinari added a comment - - edited Hi Kris, I hope this is the right place for these considerations. If not, please tell me where I should better write them. I reflected a lot on this "dependency management-less" mode after you implemented it. Recently I had the opportunity to work on a multiproject which is smaller than the one for which I bombarded you with issues ( ), but with interesting characteristics. I even pushed myself towards the direction to completely disable STS to handle my imported Eclipse projects, to see what it would mean. I could do this because the multiproject is made up of only 3 subprojects (+ the master one) and I could use a flat layout for it. This allowed me to: import projects into the workspace using the "import existing project into the workspace" wizard: this is impossible when you use the hierarchical multiproject layout avoid to cope with many other annoyances the hierarchical layout imposes due to the lack of hierarchical project structure support in Eclipse Anyway, apart from this, I think I could make myself a better idea on what it means to work without STS handling my dependencies. First of all, I found a little annoyance: http://issues.gradle.org/browse/GRADLE-2293 . Similar problems have been already fronted and fixed by you in STS (do you remember STS-2174 ?) and they come into play when the projects are shared into an SCM. Another "small" problem ("small" because I think it will be solved when http://issues.gradle.org/browse/GRADLE-2123 is fixed) is that dependencies of a 'war'+'eclipse-wtp' project are currently configured in a way that prevent Gradle from providing the sources of the JARs on which my Eclipse WTP project depends on. This is actually the area in which the "dependency management-less" mode was more promising for me to solve complex project setups that are described in STS-2186 and whose resolution in STS would need some work that also needs propaedeutic improvements on Gradle's counterpart, partially discussed recently by you and Szczepan Faber on http://issues.gradle.org/browse/GRADLE-1777 . But the major problem, for which I don't think there will ever by an effective solution in "dependency management-less" mode, arises again when you are sharing your projects in a SCM repository: when you let Gradle "eclipse" and "eclipse-wtp" plugins alone to handle dependencies, they configure your Eclipse project classpath with hard references to JAR files in your local filesystem. This means that if team member A and team member B check out the same shared Eclipse project on their systems, they must issue a "Refresh dependencies" on the project after checking it out (and this is not a problem) and the result of this operation leads to two different .classpath files (and maybe others, when WTP is involved) on A's and B's local working copies. This is bad, since unwanted changes are always generated whenever a dependency refresh is issued by any team member. This is not the case when STS dependency management is enabled, because apart from sharing an Eclipse setup where the STS container is in the projects' build path, JARs are then resolved dynamically by STS and no hard references to the local physical location of JARs are saved in the shared project files. This is an extremely important plus of the "dependency management-enabled" mode and I don't think there is any easy way to fix the "dependecy management-less" mode to handle this use case in the right way, other than adopting an approach similar to the one STS is already providing with its "Gradle Dependencies" container (and hence with the "dependency management-enabled" mode). In a "Gradle-ideal" world, maybe one may think about the possibility to just share Gradle projects and source files and let "gradle eclipse" to generate all the necessary Eclipse project setup for you whenever you check out your project from the SCM repository, without sharing the generated Eclipse project configuration files. However, I don't think this is a viable solution, since there are a lot of other project configuration aspects (like: build path inclusion/exclusions, formatter and convention settings, other Java editor settings and in general any project-specific configuration overriding) that can (or even must) be shared among the team members and hence Eclipse project configuration data must be shared together with the Gradle project and source files (unless you accept to miss all these features). For now, this is the result of my experiments. I'd like to know what you think about it... and I hope I have given my contribution to retain you from evaluating the drop of the "dependency management-enabled" mode in STS Mauro.
        Hide
        Kris De Volder (c) added a comment - - edited

        Hi Mauro, thanks for sharing your thoughts. I'll zoom right in on the one problem you mention can't be avoided in "dependency management-less" mode:

        ... when you are sharing your projects in a SCM repository: when you let Gradle "eclipse" and "eclipse-wtp" plugins alone to handle dependencies, they configure your Eclipse project classpath with hard references to JAR files in your local filesystem.

        Yes, that's the advantage of the classpath container, it replaces the absolute references with something that is dynamically computed. So the container is the better solution. But we are caught between a rock and hard-place so to speak. Since the limitation of tooling API means not all kinds of projects can be properly supported in this way.

        However, isn't the solution for this problem simply not add the .classpath file to SCM in 'dependecy management-less' mode? Since it will be generated the next time you refresh dependencies, it may
        make more sense not to commit it (just like you won't commit generated .class files to SCM).

        Or is there a particular problem you encounter when .classpath files are excluded from SCM?

        Kris

        Show
        Kris De Volder (c) added a comment - - edited Hi Mauro, thanks for sharing your thoughts. I'll zoom right in on the one problem you mention can't be avoided in "dependency management-less" mode: ... when you are sharing your projects in a SCM repository: when you let Gradle "eclipse" and "eclipse-wtp" plugins alone to handle dependencies, they configure your Eclipse project classpath with hard references to JAR files in your local filesystem. Yes, that's the advantage of the classpath container, it replaces the absolute references with something that is dynamically computed. So the container is the better solution. But we are caught between a rock and hard-place so to speak. Since the limitation of tooling API means not all kinds of projects can be properly supported in this way. However, isn't the solution for this problem simply not add the .classpath file to SCM in 'dependecy management-less' mode? Since it will be generated the next time you refresh dependencies, it may make more sense not to commit it (just like you won't commit generated .class files to SCM). Or is there a particular problem you encounter when .classpath files are excluded from SCM? Kris
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        that's interesting. In my previous message I said that it's not a viable solution to completely exclude the Eclipse project configuration files from the SCM, but maybe excluding only SOME of them (i.e.: those related to classpath configuration) could be the solution.

        However, it's still a risky solution. Some reasons that I thought of now:

        • if I decide to exclude .classpath from SCM, I need to handle via Gradle ANY classpath-related aspect of my Eclipse project. This might even be desirable, but in any case prevents me from making changes to the Eclipse project that I do not want to put in the Gradle scripts; You may think it would not be a good idea to do such things however, and I may agree with you, but are we sure that Gradle will always satisfy my needs regarding Eclipse project classpath configuration? What if I want to add some particular feature to the Eclipse project (i.e.: one provided by some plugin) that Gradle can't know of and that requires me to add something to the .classpath file? I couldn't share that configuration in the SCM repository and all the team members will have to configure it on their own. There currently is also another problem (do you remember http://issues.gradle.org/browse/GRADLE-1869? I'm pretty sure that problem also hits the handling of inclusions/exclusions in dependency management-less mode), although issues like this may be solved by Gradle
        • for WTP project, also. .settings/org.eclipse.wst.common.component must be excluded from the SCM repository; this prevents me from sharing other project properties like the context-root name of the deployed webapp or any additional resource mapping to customize webapp deploying; in complex projects (like the main one I work on) this is vital, since Gradle by itself does not allow to do WAR overlaying for instance (see http://issues.gradle.org/browse/GRADLE-811)

        So, for simple projects maybe avoiding to share the .classpath/.settings/org.eclipse.wst.common.component could be the solution, but in this case it's the dependency management-less mode (rather than the other one) to hit complex project configurations.

        Show
        Mauro Molinari added a comment - Hi Kris, that's interesting. In my previous message I said that it's not a viable solution to completely exclude the Eclipse project configuration files from the SCM, but maybe excluding only SOME of them (i.e.: those related to classpath configuration) could be the solution. However, it's still a risky solution. Some reasons that I thought of now: if I decide to exclude .classpath from SCM, I need to handle via Gradle ANY classpath-related aspect of my Eclipse project. This might even be desirable, but in any case prevents me from making changes to the Eclipse project that I do not want to put in the Gradle scripts; You may think it would not be a good idea to do such things however, and I may agree with you, but are we sure that Gradle will always satisfy my needs regarding Eclipse project classpath configuration? What if I want to add some particular feature to the Eclipse project (i.e.: one provided by some plugin) that Gradle can't know of and that requires me to add something to the .classpath file? I couldn't share that configuration in the SCM repository and all the team members will have to configure it on their own. There currently is also another problem (do you remember http://issues.gradle.org/browse/GRADLE-1869? I'm pretty sure that problem also hits the handling of inclusions/exclusions in dependency management-less mode), although issues like this may be solved by Gradle for WTP project, also. .settings/org.eclipse.wst.common.component must be excluded from the SCM repository; this prevents me from sharing other project properties like the context-root name of the deployed webapp or any additional resource mapping to customize webapp deploying; in complex projects (like the main one I work on) this is vital, since Gradle by itself does not allow to do WAR overlaying for instance (see http://issues.gradle.org/browse/GRADLE-811 ) So, for simple projects maybe avoiding to share the .classpath/.settings/org.eclipse.wst.common.component could be the solution, but in this case it's the dependency management-less mode (rather than the other one) to hit complex project configurations.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: