I have upgraded to reactive mongo 0.17.1 to 0.20.3. and after that I facing these warnings.
[WARN] [03/17/2020 12:20:43.782] [main]
[ManifestInfo(akka://reactivemongo)] Detected possible incompatible
versions on the classpath. Please note that a given Akka version MUST
be the same across all modules of Akka that you are using, e.g. if you
use [2.5.25] all other modules that are released together MUST be of
the same version. Make sure you're using a compatible set of
libraries. Possibly conflicting versions [2.5.25, 2.5.11] in libraries
[akka-protobuf:2.5.25, akka-actor:2.5.25, akka-slf4j:2.5.11,
akka-stream:2.5.25]
The reason for the error is that it is not safe to mix different patch versions of Akka modules, they all need to be of the same version (you can read more about this in the docs here.
Most often you can just add explicit dependencies in your build for the transitive ones to force them to be of the Akka version you want (2.5.25 in this case).
Related
I would like to cross-build some of my Bazel targets to Scala 2.12 and 2.13. As a further point of complexity, I need to be able to express cross-target dependencies (eg. some 2.13 target may have a Bazel dependency on a 2.12 target).
Note: this isn't a regular library dependency (eg. with the dependency 2.12-built JAR showing up on the class path when compiling the 2.13 JAR), as that would almost surely result in issues due to having two incompatible versions of the Scala standard library on the class path. Rather, this is just a case where I need the dependency JAR built so I can use it in some integration tests in the 2.13 target.
What I've found online so far...
This issue from rules_scala seems it doesn't support baking the Scala version into the target and instead you have to pick the Scala version globally.
This Databricks post has a cross-building section that is exactly what I think I would like (eg. one target generated per library per supported Scala version), but the snippets in that post don't seem to be backed by any runnable Bazel code.
This later post by Databricks also hints at a cross_scala_lib rule, but also doesn't have any accompanying code.
I have quite a big Play/Akka project on Scala 2.11 with literally dozens of dependencies, for which we need to migrate to all new stack: newest Play, Akka, Scala etc.
But along the upgrade way, our team constantly facing unexpected issues after certain lib update that another lib has transitive dependency on it, which was evicted and suddenly starting to crash in runtime somewhere in internals. E.g. play-pac4j has transitive dependency on Play, which we forgot to upgrade properly after Play upgrade from 2.5 to 2.7.
Question: is there any sbt plugin, which can say in advance which dependencies I need to change to which version version, if I want to update dependency group % name from version-x to version-y?
I'm aware of sbt-dependency-graph plugin and we are using, but I want some automation. Meaning: sbt-dependency-graph has whatDependsOn command, but I don't want to manually verify which version is compatible with transitive dependency i want to go to.
Thank you.
I want to understand the dependencies for a multi-module maven project and for that referred to eclipse dependency hierarchy.
I did understand fairly, however some of the things I am not able to understand at all.
Below is the screen shot.
The things which I didn't understand are:
--> managed from 1.0.2 [Compile}
--> managed from 1.0.2 (omitted for conflict with 1.0.0) [Compile]
I did search online but I got information in traces. Can anyone help me understand what they mean in easy to understand?
Thanks.
Maven builds a flat classpath from the dependency tree each for compiling ([compile]), for testing, and for running.
In a flat classpath, unlike OSGi, a dependency can only exist in one version. In your cropped screenshot, there is on the second level among other things:
kafka-streams 1.0.2 and
kafka-clients 1.0.0.
kafka-streams 1.0.2 requires kafka-clients 1.0.2 which conflicts to kafka-clients 1.0.0. Therefore kafka-streams 1.0.2 is omitted for conflicts with 1.0.0 even if the version 1.0.2 is required here ("managed from 1.0.2").
More detailed:The classpath which is used to compile or run a plain Java application is flat: all required libraries are globally specified as an ordered list. It is not possible to use a library of a specific version for one package and for another package the same library in a different version.In Maven dependencies builds a tree: each dependency might have its own dependencies. Maven maps the tree of dependencies to the classpath, an ordered list of libraries. If in the Maven dependencies tree the same library exists in different versions, it is not possible to create a flat classpath. This is a conflict.This conflict is resolved by picking one version and omitting all other versions. At the place where the picked version is used instead of the required version, (managed from <required but not picked version>) and (omitted for conflict with <picked version to use instead>) is displayed.In addition, Maven can create different classpaths to compile, to test or to run a Java application via so-called scopes. The [compile] scope is the default scope for using a library in all tasks: compiling, testing and running.
Make sure that the versions specified in the pom.xml file are compatible with each other (which is not yet the case in your screenshot): you have to upgrade kafka-clients from 1.0.0 to 1.0.2 (or downgrade the other libraries).
I had been using Scalariform in a project I upgraded to Scala 2.11. In doing so, I discovered that Scalariform does not appear to have an artifact published for 2.11 in any of the usual places. This makes the usual sbt cross-version dependency unhappy.
As 2.11 has been out for a while already, this has me questioning if the usage of Scalariform as an embedded library should be considered abandoned? Has the community moved on to an alternative I just don't know about?
Scalafmt is an alternative code formatter that does compile to 2.11 and can be used as an embedded library. An up-to-date usage example is here https://olafurpg.github.io/scalafmt/#Standalonelibrary
The Scala 2.10 release notes says this: "Akka Actors now part of the distribution. The original Scala actors are now deprecated."
The latest Akka library ("Akka 2.1.0 for Scala 2.10") mentions the following dependency:
com.typesafe.akka:akka-actor_2.10:2.1.0
and the following examples:
import akka.actor.Actor
class MyActor extends Actor {..}
val system = ActorSystem("MySystem")
My project includes these libraries:
org.scala-lang:scala-library:2.10.0
org.scala-lang:scala-actors:2.10.0
In my classpath, I have no package called "akka". I do see instead scala.actors, but it doesn't seem deprecated.
So, in which way are Akka Actors "part of the distribution"?
If this is, indeed, the case, then am I still supposed to add the "akka-actor_2.10" library as a dependency? If so, do I use akka.Actor or the non-deprecated scala.actors.Actor ?
In scala 2.9.2 scala actors was part of scala-library.jar.
If you download a scala-2.10.0 distribution it there are no actors in scala-library and both akka-actors.jar and scala-actors.jar are supplied.
The latter is present for backwards compatibility and will be removed in a future major release.
akka-actors is the replacement and what you should use for any new development (and look to move anything using scala-actors across when possible).
If you have no current code in your project using actors you should probably reconfigure your project's dependencies to remove org.scala-lang:scala-actors:2.10.0 and instead depend on com.typesafe.akka:akka-actors_2.10:2.1.0 if you want to use actors.
I am not sure why there's no deprecation annotation on the classes in scala-actors in 2.10.0 but I believe it's to be added in 2.10.1.
You can find more info on the migration guide.