Announcement Announcement Module
No announcement yet.
Excluding Groovy dependencies from Gradle projects or re-ordering the classpath Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Excluding Groovy dependencies from Gradle projects or re-ordering the classpath

    I've got a problem similar to this thread but the issue is that the conflicting dependency in question (servlet-api-2.4) is being included due to the Groovy Libraries, not the Gradle DSL support.

    Disabling DSL support and refreshing dependencies doesn't appear to have any effect on the Groovy Libraries entries. If there's no way to eliminate the Groovy libraries from the classpath for Gradle projects in STS, is there at least a way to re-order the classpath so the dependencies I've specified in my Gradle build file come first?

    If anyone is interested in reproducing this, just check out Jon Brisbin's spring-data-rest-webmvc project and import it into STS. It'll immediately complain about RestExporterWebInitializer because it uses new Servlet API 3.0 methods and STS is picking up 2.4.

    Attached Files

  • #2
    As a first try, simply select "Groovy Libraries" right-click -> Build path -> Remove from build path.

    If these libraries come back after a doing a Gradle -> Refresh, select the "Disable DSL support" from the options menu.


    • #3
      Some more info that might be useful.

      1) unless your project is an actual groovy project the groovy nature and groovy libraries are only added to it as part of DSL support.
      2) However, when you disable DSL support the Groovy nature and library entries probably will not be removed for a project that has dependency management enabled. This is because the tools don't really have a way of knowing right now that they are not needed. I've been thinking about a way to fix that, but haven't come up with a good solution yet.

      To avoid the groovy nature and libs getting added try cleaning out all the Eclipse configuration from your project then import it again making sure the 'enable DSL' is not selected on initial import.

      Alternatively, you can manually remove the library entry as Andrew suggested and, I believe, if DSL support is disabled, it should not come back the next time you refresh dependencies.



      • #4
        Ah! That worked perfectly, Kris. I just re-imported the project and left DSL support disabled.


        • #5
          I encountered the same problem with Brisbin's rest-webmvc project (mentioned above) a few days ago, and posted a question in the Spring Data forum asking how to resolve this. After a few days of no answers, I decided to do some googling (groovy libraries exclude "servlet-api") just now, and came across this thread.

          It lead me to try

          1. select the project node in Project Explorer;
          2. right-click, select "Groovy > Remove Groovy libraries from classpath"

          The compiler errors disappeared.

          The "tomcatRun" target seems to run just fine without the Groovy libs on the classpath.