CODEWITHSUNDEEP
javaeclipsegradledependenciesgradle-eclipse
Kartu
Kartu

Reputation: 71

gradle eclipse dependencies, skipping testCompile/providedRuntime etc

Gradle is used to build a simple web application, split into handful of eclipse projects within the same workspace. Gradle script runs tests/creates deployable EAR file just fine. EAR file runs without any issues on a Liberty Profile server.

However, I have problems running it from eclipse (with gradle plugin). The root of the problems seems to be automatic "gradle depencency" management (bunch of dependencies that get injected by "classpass container" org.springsource.ide.eclipse.gradle.classpathcontainer). This thing seems to pick up any dependency, be it compileOnly, testCompile, providedCompile etc. This leads to libs with classes like javax.persistence., javax.inject that are needed for standalone build, but are provided by the application server and are not needed when running from eclipse, being deployed to the app server as part of the application and cause all kinds of errors/warnings.

Is there a way to filter dependencies that gradle eclipse plugin picks up for deployment?

Upvotes: 0

Views: 521

Answers (1)

Kris
Kris

Reputation: 3957

This is a long standing issue with STS gradle tooling. It stems from the fact that gradle-tooling-api doesn't distinguish between provided / test etc. dependencies in the model it produces for the 'eclipse classpath'. At least it was the case when STS gradle tooling was implemented. The tooling-api model has evolved since then, but STS gradle tooling is being phased out and this is unlikely to get a real fix.

That being said, there is a workaround that was specifically implemented for this exact situation.

Go to Window >> Preferences >> Gradle (STS) >> WTP. There you will see a list of regular expression labeled Gradle Dependencies Deployment Exclusions. You can add more expressions there. These act as a kind of global filter. Any jar matching one of these expression will be excluded from WTP deployment assembly.

This may work for you.

However, it is a bit of a crude workaround.

So... I hear that BuildShip which is STS Gradle-tooling's official successor now has WTP support. So perhaps you want to try and switch over to BuildShip. I would assume it deals with provided, test etc. dependencies correctly w.r.t to WTP deployment assembly (if it doesn't you should consider filing a bug report against BuildShip).

Upvotes: 1

Related Questions