Upgrade to Gradle 6.9.4 and Scala 2.12.20#964
Conversation
|
You probably have good reasons for 6.9.4, but I ask nevertheless, why not 7.6.x, 8.14.x or 9.2.x from this year? |
Not a question to me but I guess I can give a brief answer - it's not trivial to jump high on the Gradle versions - there are deprecations that stick around for a version or two and are removed in the next, I always find it easier to update on smaller increments 😄 |
|
Thanks @vnickolov! @michael-simons exactly what Veselin said :). |
build.gradle
Outdated
|
|
||
| dependencies { | ||
| compile group: 'org.scala-lang', name: 'scala-library', version: ver.scala.full | ||
| api group: 'org.scala-lang', name: 'scala-library', version: ver.scala.full |
There was a problem hiding this comment.
Heads up - the long dependency syntax group: x, name: y, version: z is deprecated in Gradle 9 and will be removed in 10 (I think) 🙃
There was a problem hiding this comment.
Also I wonder why changing from compile to api - the latter makes the dependency transitively exposed 🤔
Maybe compileOnly is what you need?
There was a problem hiding this comment.
Thanks, nice catch, I probably was a bit fast there.
There was a problem hiding this comment.
Some dependencies can probably be implementation rather that api too. But as far as I understand that requires knowledge about what is exposed in your public API, which sounds time consuming to figure out. Or perhaps I'm confused @vnickolov?
There was a problem hiding this comment.
In GDS we somewhat opted for using implementation instead api and leave the clients of the thing declare dependencies explicitly, if you switch to implementation and the build doesn't break then you're good. It's always better not to have unnecessary transitive dependencies 🙂
What I usually try to do is look at public classes and methods and if they use parameters or return something that is from a dependency then I can consider declaring that dependency in an api scope but that could be very time consuming.
There was a problem hiding this comment.
@loveleif You can probably assume that there is no public API and that there are no users for which breaking a supposed public API is a problem.
There was a problem hiding this comment.
Meaning that closing down access here could be a good starting point, as long as tests are green.
There was a problem hiding this comment.
Thanks, I'll try that.
57a344c to
d59ac15
Compare
michael-simons
left a comment
There was a problem hiding this comment.
Great stuff, however wrt to Gradle as of know I can only do "LGTM" approvals, sorry. If this is fine with you, I am happy to… Otherwise someone else should step in.
No description provided.