Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to sbt-scoverage 2.0.0 creates dependency conflicts #439

Closed
guizmaii opened this issue Jun 26, 2022 · 15 comments
Closed

Update to sbt-scoverage 2.0.0 creates dependency conflicts #439

guizmaii opened this issue Jun 26, 2022 · 15 comments

Comments

@guizmaii
Copy link

guizmaii commented Jun 26, 2022

[error] java.lang.RuntimeException: found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[error] 
[error] 	* org.scala-lang.modules:scala-xml_2.13:2.1.0 (early-semver) is selected over 1.3.0
[error] 	    +- org.scoverage:scalac-scoverage-reporter_2.13:2.0.0 (depends on 2.1.0)
[error] 	    +- eu.timepit:refined_2.13:0.9.29                     (depends on 1.3.0)

The weird thing is that refined has updated to 2.1.0 in its latest version 0.9.29:

Hum, in fact they support both, depending on your Scala version:

image

🤔

@ckipp01
Copy link
Member

ckipp01 commented Jun 26, 2022

Hi @guizmaii, thanks for the report. Refined is for sure pulling in 1.3.0. You can see this with:

❯ cs resolve eu.timepit:refined_2.13:0.9.29
https://repo1.maven.org/maven2/eu/timepit/refined_2.13/0.9.29/refined_2.13-0.9.29.pom
  100.0% [##########] 2.6 KiB (21.5 KiB / s)
com.chuusai:shapeless_2.13:2.3.9:default
eu.timepit:refined_2.13:0.9.29:default
net.java.dev.jna:jna:5.9.0:default
org.jline:jline:3.21.0:default
org.scala-lang:scala-compiler:2.13.8:default
org.scala-lang:scala-library:2.13.8:default
org.scala-lang:scala-reflect:2.13.8:default
org.scala-lang.modules:scala-xml_2.13:1.3.0:default

Looking at the build you can also see:

https://github.com/fthomas/refined/blob/80f5cb7c88e8dcb0ae5846d9aef3f9ed3add27de/build.sbt#L170-L179

So it looks like it's using 2.1.0 for Scala 3, but 1.3.0 for everything else. The last time I looked most dependencies for 2.11 and 2.12 are still on the 1.x series for scala-xml (so is scoverage for 2.12), but for 2.13 and above most things have migrated to 2.x. So I'm not 100% sure why refined hasn't done the same, and why they only target 2.x for Scala 3.

@guizmaii
Copy link
Author

I'll see if I can push a PR to use scala-xml 2 for Scala 2.13 in refined.

Thanks @ckipp01 :)

@ckipp01
Copy link
Member

ckipp01 commented Jun 26, 2022

No problem, if you have any other issues, just report back.

@guizmaii
Copy link
Author

FYI fthomas/refined#1098

@guizmaii
Copy link
Author

FYI the issue is fixed in v0.10.0 of refined: https://github.com/fthomas/refined/releases/tag/v0.10.0

@ruippeixotog
Copy link

ruippeixotog commented Jul 23, 2022

@ckipp01 this is happening with more dependencies now, not just refined. Notably, scalatest migrated to scala-xml 2 in v3.2.11 (3.2.10 dependencies, 3.2.11 dependencies). Given scalatest is so widely used, should scoverage follow suit?

On PureConfig, for now I'm probably downgrading to scalatest to 3.2.10 in order to be able to use scoverage + Scala 2.12.6, but longer term the only solution seems to be for everyone to adopt scala-xml 2.

Example CI failure with newest scalatest: https://github.com/pureconfig/pureconfig/actions/runs/2724486086

@ckipp01
Copy link
Member

ckipp01 commented Jul 24, 2022

Hey @ruippeixotog, thanks for reporting back. I still don't think this is the best choice for 2.12 to migrate to the 2 series for scala-xml. The main reason I stuck on the version I did was due to Scala itself sticking to that version for 2.12. You can see this here.

If more and more people are hitting on this, then I guess it make sense to migrate, but if I'm not mistaken if we do, then we still may hit on issues the other way around with the version that scala can bring in.

@ckipp01
Copy link
Member

ckipp01 commented Jul 25, 2022

btw @ruippeixotog I did some more digging and I think we should be fine to update. I'd accept a pr to change this.

@ruippeixotog
Copy link

@ckipp01 sounds good, I have just opened scoverage/scalac-scoverage-plugin#488 for this. After that you'll need to publish a new version of scalac-scoverage-reporter and use it in sbt-coverage.

@ckipp01
Copy link
Member

ckipp01 commented Jul 27, 2022

2.0.1 is published and ready to go @ruippeixotog.

@carlosedp
Copy link

carlosedp commented Jul 27, 2022

I'm seeing these errors while updating from 2.0.0 to 2.0.1:

[error] java.lang.RuntimeException: found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[error]
[error] 	* org.scala-lang.modules:scala-xml_2.12:2.1.0 (early-semver) is selected over {1.2.0}
[error] 	    +- org.scoverage:scalac-scoverage-reporter_2.12:2.0.1 (depends on 2.1.0)
[error] 	    +- org.scalariform:scalariform_2.12:0.2.10            (depends on 1.2.0)
[error] 	    +- org.jmotor.artifact:artifact-versions_2.12:1.0.6   (depends on 1.2.0)
[error]
[error]
[error] this can be overridden using libraryDependencySchemes or evictionErrorLevel
[error] 	at scala.sys.package$.error(package.scala:30)
[error] 	at sbt.internal.LibraryManagement$.resolve$1(LibraryManagement.scala:89)
[error] 	at sbt.internal.LibraryManagement$.$anonfun$cachedUpdate$12(LibraryManagement.scala:133)
[error] 	at sbt.util.Tracked$.$anonfun$lastOutput$1(Tracked.scala:73)
[error] 	at sbt.internal.LibraryManagement$.$anonfun$cachedUpdate$20(LibraryManagement.scala:146)
[error] 	at scala.util.control.Exception$Catch.apply(Exception.scala:228)
[error] 	at sbt.internal.LibraryManagement$.$anonfun$cachedUpdate$11(LibraryManagement.scala:146)
[error] 	at sbt.internal.LibraryManagement$.$anonfun$cachedUpdate$11$adapted(LibraryManagement.scala:127)
[error] 	at sbt.util.Tracked$.$anonfun$inputChangedW$1(Tracked.scala:219)
[error] 	at sbt.internal.LibraryManagement$.cachedUpdate(LibraryManagement.scala:160)
[error] 	at sbt.Classpaths$.$anonfun$updateTask0$1(Defaults.scala:3688)
[error] 	at scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error] 	at sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error] 	at sbt.std.Transform$$anon$4.work(Transform.scala:68)
[error] 	at sbt.Execute.$anonfun$submit$2(Execute.scala:282)
[error] 	at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:23)
[error] 	at sbt.Execute.work(Execute.scala:291)
[error] 	at sbt.Execute.$anonfun$submit$1(Execute.scala:282)
[error] 	at sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:265)
[error] 	at sbt.CompletionService$$anon$2.call(CompletionService.scala:64)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
[error] 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
[error] 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
[error] 	at java.base/java.lang.Thread.run(Thread.java:833)
[error] (update) found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[error]
[error] 	* org.scala-lang.modules:scala-xml_2.12:2.1.0 (early-semver) is selected over {1.2.0}
[error] 	    +- org.scoverage:scalac-scoverage-reporter_2.12:2.0.1 (depends on 2.1.0)
[error] 	    +- org.scalariform:scalariform_2.12:0.2.10            (depends on 1.2.0)
[error] 	    +- org.jmotor.artifact:artifact-versions_2.12:1.0.6   (depends on 1.2.0)
[error]
[error]
[error] this can be overridden using libraryDependencySchemes or evictionErrorLevel

This happens in my libraries at https://github.com/carlosedp/scalautils

@ckipp01
Copy link
Member

ckipp01 commented Jul 27, 2022

Thanks for the reply. Of course, this is exactly what I mentioned up above. We now updated to 2.x whereas before we were on 1.x. So those other libraries that are conflicting are still stuck on 1.x which isn't compatible. We're in a situation where everything either needs to stick on 1.x or 2.x. Since the 2.x train has left, we've jumped on board and there really isn't anything we can do about it. I suggest reporting this in those other places and request them to update.

EDIT: Looking a bit closer at those deps that are conflicting @carlosedp, both of those libraries that are conflicting haven't been updated in years. I'd imagine you'll continually hit on more and more issues with them as the ecosystem evolves.

@carlosedp
Copy link

You mean org.scalariform:scalariform_2.12:0.2.10 and org.jmotor.artifact:artifact-versions_2.12:1.0.6` right?

I don't know where those deps come from, they are not added directly by me. How can I find which plugin uses them? Going to each and looking at the deps?

@ckipp01
Copy link
Member

ckipp01 commented Jul 27, 2022

You mean org.scalariform:scalariform_2.12:0.2.10 and org.jmotor.artifact:artifact-versions_2.12:1.0.6` right?

Yup exactly.

I don't know where those deps come from, they are not added directly by me. How can I find which plugin uses them? Going to each and looking at the deps?

If you're using a modern sbt version, one way to do this is using the built in addDependencyTreePlugin. Once you add that to either your global or project plugins you can do:

sbt  <-- starts sbt
reload plugins <-- jumps you into your meta build
whatDependsOn org.scalariform scalariform_2.12 <-- this comes from addDependencyTreePlugin

This should then show you what is depending on that specific artifact.

@carlosedp
Copy link

Nice, opened an issue over the plugin but disabled it temporarily.
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants