Open nbauma109 opened 2 years ago
This is another example of the flaws of how Buildship translates Gradle dependency information to Eclipse. In a nutshell, you get a union of all dependencies from eclipse.classpath.plusConfigurations
. We are aware that it needs more fine-tuning. You can work around the issue by removing commos-io from the compile classpath in a eclipse.classpath.file.whenMerged
block.
I'm closing this issue to keep the board clean, but it doesn't mean that we don't recognize the problem. I'll look into what can be done here in the future.
Unfortunately, the workaround does not work. In your example, there are problems with the execution via Eclipse, as the "commons-io" is required for runtime. Eclipse itself only recognises one scope and always uses this (runtime, api, implementation). I have managed without Gradle by restricting access to the library itself. Unfortunately, this is not possible via the Projectdependencies Container. Maybe you can start there.
With gradle it's now possible to use a runtimeOnly dependency
When I set a dependency as runtimeOnly in the build.gradle, I expect it to be unavailable to compile, but it's still included in the compile classpath.
The expected behaviour with the following example is a compilation error.
See in the screenshot below the illustration of the difference of behaviour between maven (m2e) and gradle in Eclipse.
build.gradle :
pom.xml :
In src/main/java, Main.java :