Force scalaVersion when using scala scalafmt extension #1273
Comments
|
I would expect that the scala version wouldn't depend on The scalaFmt classpath is resolved in an isolated way, as shown above. The I don't know how Gradle handles Scala, but I suppose that the scala plugin might modify the dependency resolution process somehow. Happy to take a PR that fixes this, but it seems like this should probably be pretty easy to workaround by disabling the spotless tasks on non-friendly Scala versions. |
Scalafmt is a scala project so it requires scala to be on the classpath to run so yes I do believe the gradle Scala plugin is actually providing that version of Scala on the classpath which is then picked up by spotless.
Indeed I think as a workaround this should be fine and since it appears that scalafmt is using an isolated class it should be possible to provide an alternate Scala version, I will have a look at this tomorrow. |
|
I created an issue at gradle (see gradle/gradle#21502) to also see if they have any ideas but I suspect to solve this issue we will need to use an isolated classloader due to the fact that we are going to have different scala versions in the same JVM instance. There might also be an argument that in general any of the spotless integrations should run in an isolated classloader since most of the formatters/linters are cli "like" tools that work on context free grammers (i.e. they just parse source files) |
|
@nedtwigg So I did some research on this issue (see gradle/gradle#21502 (comment)) and I better understand the problem/solutions. So the essentially problem is that spotless-scala hardcodes the Scala version (see https://github.com/diffplug/spotless/blob/0fd20bb80c6c426d20e0a3157c3c2b89317032da/lib/src/main/java/com/diffplug/spotless/scala/ScalaFmtStep.java) depending on which scalafmt version you configure. Due to spotless not knowing anything about gradle-scala plugin, this causes spotless-scala to pick Scala 2.13.x even if you configure the Scala version via gradle-scala to be 2.12.x and configuring gradle-scala to Scala 2.12 will override the Scala version globally in gradle causing gradle to load the scala lib/runtime for that version. This leaves us with 2 solutions
wdyt? For me I have a preference of detecting if gradle-scala is being used and just picking the scala version from that. Also willing to do a PR however I am not that familiar with gradle so if there is some quick reference/sample code and/or documentation on how to dynamically detect plugins that would be great. |
|
A few things - for one thing, if we wanted to remove the reflection, that is possible Also we are using an isolated classloader. We grab the jar files for ScalaFmt here and then use that isolated classloader here
You can do that like so: |
|
@nedtwigg I just made a PR that converts the scalafmt integration to use compile time source sets (see #1283). I still need to test this with Kafka, but if the issue due to reflection this should be enough to solve it. If not I will do a future PR which will try to detect a currently configured Scala version using the classpath. I want to test if this PR solves my problem by publishing Do you have any ideas how to temporarily disable signing just for local publish? |
|
Add |
|
Thanks for the tip, I ended up just disabling the In any case I have already implemented what I described at #1283 (comment), I just haven't committed the changes yet. |
|
Thanks to @mdedetrich for the new |
|
Thanks, I can confirm that the new release has also solved the underlying problem I had wrt Scala binary version. |
Related to #579
Currently I am having an issue in upgrading Kafka's scala's spotless plugin to the latest version of scalafmt (3.5.8), you can see the PR here apache/kafka#12475 (comment). While the spotless scala plugin works fine when running with the default Scala version that is 2.13.8, when happen to build Kafka with a different scala version by using the
-PscalaVersionflag it causes spotless to fail, i.e.Runs fine without any problems, but if you do
Then you get the following stack trace
The reason behind the stacktrace is the fact that the latest version of Scalafmt (3.5.8) is compiled against Scala 2.13.x but the usage of
-PscalaVersion=2.12happens to also override the Scala version used by Scalafmt. Note that the reason why we specify the version ofScala using
-PscalaVersion=2.12is because of building and then releasing Kafka against multiple Scala versions.Ultimately the point is that whatever version Scalafmt happens to run is irrelevant to what Scala version you are using to build your project and in this specific case we would ideally want to force a scalaVersion that scalafmt with regardless of the
-PscalaVersion=2.12flag, i.e. something likeRelevant details:
Spotless version: 6.9.0
Operating system: MacOS Montery 12.5 M1
Spotless Configuration
The text was updated successfully, but these errors were encountered: