Details
-
Type:
Improvement
-
Status: Resolved
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 2.12-rc-1
Description
The intent of 'provided' configuration is to define dependencies which are needed for compilation, but which should not be "exported" (aka should not show up in runtime configuration)
Issue Links
- dependent on
-
GRADLE-3399
Allow declaration of compile only dependencies
- Resolved
Activity
Hm. What isn't fixed in that scenario? I had no problems writing libs depending on (but not including) e.g. servlet api.
I previously used spring propdep but switched to "native" compileOnly instead.
LOL! 7 years! I'm at least 3 languages and 5 build systems away from this bug now.
TBH I had missed compileOnly in any releases so I have not played with it. And to be even more honest, 7 years later and all the shit I had to add to my builds to support this, its actually more of a hassle to rip that all out and try compileOnly.
Assuming compileOnly operates as out-lined in how I thought provided should work, it should also work for "container libraries" (assuming plugins pick that up and do not add them to WARs, EARs, etc).
@Joern Huxhorn
compileOnly gives us the dependency only during compilation. To be able to test these classes you'll need to add the same dependency to testCompile / testRuntime (maybe it's even useful in runtime see https://github.com/spring-projects/gradle-plugins/issues/45) configuration too, that's neither convenient nor does is follow the principals of DRY.
I simply don't understand the heavy resistance against the providedCompile scope for the jar plugin, while it's a first class concept for the war plugin.
At least for me as jee developer this configuration is the foundation of 90% of all projects. I have given up getting the full jee support as provided by maven, but this one ... well maybe we can tell our children one day about it.
I wonder how many gradle projects actually add propdeps or smth. alike to their basic configuration... at least i've had a good laugh for the birthday reminder from Joern Huxhorn 
I am considering this issue fixed with the introduction of the compileOnly configuration in Gradle 2.12. It covers the original use case described in the issue.
We recognize that are more aspects in the realm of Maven `provided` that have not been implemented yet. Any work in this area will be fleshed out in this design specification. Additionally, we started to gather related issues on GitHub mentioned in the discussion of this JIRA card e.g.
- Differences between compileOnly and providedCompile: https://github.com/gradle/gradle/issues/1171
- optional dependencies: https://github.com/gradle/gradle/issues/867
- API/implementation dependency separation: https://github.com/gradle/gradle/issues/1118
Please continue the discussion on the relevant GitHub issues or create a new GitHub issue if you think your use case is not covered yet.
This is specially for JavaPlugin I believe