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

Do not add Groovy Libraries to buildpath

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Invalid
    • Affects Version/s: 3.1.0.RELEASE
    • Fix Version/s: 3.7.0.RELEASE
    • Component/s: GRADLE
    • Labels:
      None

      Description

      The problem with adding the Groovy libraries to the build path is that it brings in servlet-api-2.5. If you have a project that depends on servlet-3.0, then the compilation of the project will fail. I have attached a sample project that demonstrates the issue. A relevant discussion for m2e and Groovy can be found in this thread. For anyone encountering this issue a workaround can be found below:

      task afterEclipseImport {
          ext.srcFile = file('.classpath')
          inputs.file srcFile
          outputs.dir srcFile
       
          onlyIf { srcFile.exists() }
       
          doLast {
              def classpath = new XmlParser().parse(srcFile)
       
              classpath.classpathentry.findAll{ it.@path == 'GROOVY_SUPPORT' }.each { classpath.remove(it) }
       
              def writer = new FileWriter(srcFile)
              new XmlNodePrinter(new PrintWriter(writer)).print(classpath)
          }
      }

        Activity

        Hide
        kdvolder Kris De Volder added a comment -

        Hi Rob,

        Sorry it took me a while to respond. Been busy with other things, and since you had a workaround it didn't seem as urgent.

        There is a bit of a dilemma here. These entries get added together with the 'DSL support' in an attempt to provide a better editor experience when editing .gradle files with the Greclipse editor.

        Removing the 'GROOVY_SUPPORT' container will probably break some of the editor support at least for some projects.

        So I'm reluctant to remove the container unconditionally.

        Right now the container is only added to a project if the option to 'Enable DSL Support' is enabled.

        So another way to get rid of the container is to not enable DSL support when you import a project.
        This will also get rid of other 'foreign' classpath entries that are not really part of your project but put there to try and get a better editor experience with Greclipse, such as the DSL support classpath container entry.

        By disabling DSL support, you are essentially saying that you rather have a 'correct' classpath for your project instead of extra cruft on the classpath put there to improve the experience editing .gradle files in your project.

        I'm really not quite sure how to resolve this issue.

        Show
        kdvolder Kris De Volder added a comment - Hi Rob, Sorry it took me a while to respond. Been busy with other things, and since you had a workaround it didn't seem as urgent. There is a bit of a dilemma here. These entries get added together with the 'DSL support' in an attempt to provide a better editor experience when editing .gradle files with the Greclipse editor. Removing the 'GROOVY_SUPPORT' container will probably break some of the editor support at least for some projects. So I'm reluctant to remove the container unconditionally. Right now the container is only added to a project if the option to 'Enable DSL Support' is enabled. So another way to get rid of the container is to not enable DSL support when you import a project. This will also get rid of other 'foreign' classpath entries that are not really part of your project but put there to try and get a better editor experience with Greclipse, such as the DSL support classpath container entry. By disabling DSL support, you are essentially saying that you rather have a 'correct' classpath for your project instead of extra cruft on the classpath put there to improve the experience editing .gradle files in your project. I'm really not quite sure how to resolve this issue.
        Hide
        rwinch Rob Winch added a comment - - edited

        Kris,

        No problem on the response time I figured you may be busy (especially with the holiday season).

        How would you feel about providing a hook to configure the dialog settings via the Gradle build? This way all the settings could be defaulted correctly. I haven't thought about how this would be implemented yet, but if it is something you would consider and you are looking for implementation suggestions I would be willing to provide any assistance I could.

        Alternatively, we could look at the classpath to see if there is a collision detected and default the settings that way.

        Show
        rwinch Rob Winch added a comment - - edited Kris, No problem on the response time I figured you may be busy (especially with the holiday season). How would you feel about providing a hook to configure the dialog settings via the Gradle build? This way all the settings could be defaulted correctly. I haven't thought about how this would be implemented yet, but if it is something you would consider and you are looking for implementation suggestions I would be willing to provide any assistance I could. Alternatively, we could look at the classpath to see if there is a collision detected and default the settings that way.
        Hide
        kdvolder Kris De Volder added a comment - - edited

        Thanks for the suggestions. My thoughts...

        > How would you feel about providing a hook to configure the dialog settings via the Gradle build?

        I like that idea. But at the moment, the 'model' I get from Gradle tools is really quite limited. E.g. I cannot ask the model about properties that the build sets or things like that. So the question is, if the build wants to 'tell the tools something', I'm not sure what mechanism we can use.

        > Alternatively, we could look at the classpath to see if there is a collision detected and default the settings that way.

        That sounds feasible, provided there some decent 'collision detection rules' we can come up with.

        By the way, if disabling DSL on import seems like a good solution for you... then it is possible to specify this as a default in your project by committing this file:

        ${rootProjectDir}/.settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs

        to source control. This file contains the defaults for the import wizard dialog options.
        They are saved there the first time you import a project.

        Show
        kdvolder Kris De Volder added a comment - - edited Thanks for the suggestions. My thoughts... > How would you feel about providing a hook to configure the dialog settings via the Gradle build? I like that idea. But at the moment, the 'model' I get from Gradle tools is really quite limited. E.g. I cannot ask the model about properties that the build sets or things like that. So the question is, if the build wants to 'tell the tools something', I'm not sure what mechanism we can use. > Alternatively, we could look at the classpath to see if there is a collision detected and default the settings that way. That sounds feasible, provided there some decent 'collision detection rules' we can come up with. By the way, if disabling DSL on import seems like a good solution for you... then it is possible to specify this as a default in your project by committing this file: ${rootProjectDir}/.settings/gradle/org.springsource.ide.eclipse.gradle.core.import.prefs to source control. This file contains the defaults for the import wizard dialog options. They are saved there the first time you import a project.
        Hide
        rwinch Rob Winch added a comment -

        Thanks for the information. It sounds as thought I already default the dialog with Gradle by having a "dependsOn eclipse" and generating the prefs file. I will play around with this and get back to you (this may be all I require to get past this issue).

        Show
        rwinch Rob Winch added a comment - Thanks for the information. It sounds as thought I already default the dialog with Gradle by having a "dependsOn eclipse" and generating the prefs file. I will play around with this and get back to you (this may be all I require to get past this issue).
        Hide
        kdvolder Kris De Volder added a comment -

        Caveat: depending on when the prefs file is generated by your build-script, it may already be too late. The tools don't have a mechanism yet to detect changes to that file after it has been read.

        Just so you know, if it appears you are generating the file correctly, but the dialog does not seem to pick up on the stuff you put into it this may be the reason.

        If so, let me know and we'll try to work out some fix that makes it work.

        Show
        kdvolder Kris De Volder added a comment - Caveat: depending on when the prefs file is generated by your build-script, it may already be too late. The tools don't have a mechanism yet to detect changes to that file after it has been read. Just so you know, if it appears you are generating the file correctly, but the dialog does not seem to pick up on the stuff you put into it this may be the reason. If so, let me know and we'll try to work out some fix that makes it work.
        Hide
        btiernay Bob Tiernay added a comment -

        I see this as a major defect. I hit this bug and it took me quite a while to figure out. Is it not possible to at the very least change the priority of these classpath entries? Also, I see no benefit of having them be exported between projects (which appears to be the case) since it causes this problem to infect other projects as well.

        Why can't the plugin simply encapsulate them internally and not expose them to the workspace? Why must they be added to the project?

        Show
        btiernay Bob Tiernay added a comment - I see this as a major defect. I hit this bug and it took me quite a while to figure out. Is it not possible to at the very least change the priority of these classpath entries? Also, I see no benefit of having them be exported between projects (which appears to be the case) since it causes this problem to infect other projects as well. Why can't the plugin simply encapsulate them internally and not expose them to the workspace? Why must they be added to the project?
        Hide
        kdvolder Kris De Volder added a comment -

        > Why can't the plugin simply encapsulate them internally and not expose them to the workspace? Why must they be added to the project?

        Unfortunately it can't because the groovy editor is in fact a 'hacked' Java editor and it depends on the project classpath for its proper functioning. Eclipse doesn't have a mechanism for editor to use different classpath for different files in a single project.

        However some of your suggestions are feasible (the not exporting one, for example). I will take another look at this soonish. Targetting for 3.6.0.M1 (may not get to it for 3.6.0.M1, but it will be higher on the 'radar' if its tagged with a release version fix).

        Show
        kdvolder Kris De Volder added a comment - > Why can't the plugin simply encapsulate them internally and not expose them to the workspace? Why must they be added to the project? Unfortunately it can't because the groovy editor is in fact a 'hacked' Java editor and it depends on the project classpath for its proper functioning. Eclipse doesn't have a mechanism for editor to use different classpath for different files in a single project. However some of your suggestions are feasible (the not exporting one, for example). I will take another look at this soonish. Targetting for 3.6.0.M1 (may not get to it for 3.6.0.M1, but it will be higher on the 'radar' if its tagged with a release version fix).
        Hide
        btiernay Bob Tiernay added a comment -

        Thanks for taking a look. Hopefully I didn't come across as being too snarky here. I was just very saddened that I couldn't use the terrific DSL support for my applications (Spring Boot).

        Much appreciated.

        Show
        btiernay Bob Tiernay added a comment - Thanks for taking a look. Hopefully I didn't come across as being too snarky here. I was just very saddened that I couldn't use the terrific DSL support for my applications (Spring Boot). Much appreciated.
        Hide
        kdvolder Kris De Volder added a comment -

        Given that we have in removed all traces of Groovy Eclipse integration from Gradle tooling, I beleave this is no longer a problem.

        Show
        kdvolder Kris De Volder added a comment - Given that we have in removed all traces of Groovy Eclipse integration from Gradle tooling, I beleave this is no longer a problem.

          People

          • Assignee:
            kdvolder Kris De Volder
            Reporter:
            rwinch Rob Winch
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: