I want to change one of my library to the latest version. where to find the version of the dependency in play.
In general, you can see a list of Play's direct dependencies by checking the project/Dependencies.scala file in the source code for that version of Play. For version 2.4.3, that file is here: https://github.com/playframework/playframework/blob/2.4.3/framework/project/Dependencies.scala
In the specific case of Jackson, the group ID and module structure changed between Jackson 1.x and 2.x. Play 2.4.3 is using Jackson 2.5.4. If your project depends on Jackson 1.8.5, this dependency isn't coming from Play, but from some other source.
You can use the sbt-dependency-graph plugin to view the full tree of transitive dependencies and see where it is introduced.
To update to a newer version, you can add a direct dependency to your build.sbt with the desired version:
libraryDependencies += "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.13"
This will override the version requested by other libraries; by default, sbt will use the greatest version requested.
However, there are a few things to keep in mind:
Jackson is composed of several sub-modules. If you are using several of these in the same project, including transitively, it's a good idea to use the same version of all of them. This might require adding additional dependencies to your project to keep them all in sync.
When upgrading dependencies in your application that are also used by other libraries it depends on, you'll need to consider backward compatibility. Jackson is not always fully backward compatible between minor versions, so if you update to a newer version of Jackson than what your libraries were designed to use, you might encounter problems at runtime.
Using both Jackson 1.x and 2.x in the same project is possible, since they have different group IDs and Java package names, but it may be confusing and error prone. If you can, it would be better to standardise on the Jackson version that is used by the Play Framework version you choose.
Related
If I add the com.google.truth.extensions:truth-proto-extension:1.1 jar to my bazel workspace, it seems to totally nuke the classes from com.google.guava:guava:28.2-jre, resulting in errors like
import static com.google.common.collect.ImmutableMap.toImmutableMap;
^
symbol: static toImmutableMap
location: class ImmutableMap
java/com/google/fhir/protogen/ProtoGenerator.java:316: error: cannot find symbol
.collect(toImmutableMap(def -> def.getId().getValue(), def -> def));
^
symbol: method toImmutableMap((def)->def[...]lue(),(def)->def)
location: class ProtoGenerator
Your documentation says
One warning: Truth depends on the “Android” version of Guava, a subset of the “JRE” version.
If your project uses the JRE version, be aware that your build system might select the Android version instead.
If so, you may see “missing symbol” errors.
The easiest fix is usually to add a direct dependency on the newest JRE version of Guava.
Does this mean anything other than the maven dep on com.google.guava:guava:28.2-jre? If not, what's the next easiest fix?
The key word here is "newest": You'll need to depend on (as of this writing) 30.1-jre. I have edited the docs to emphasize this.
(You can see the newest version in various locations, including: Maven Central, Maven Central Search, the Guava GitHub page.)
The problem is:
Some tools (including Gradle as well as the maven_install rule from Bazel's rules_jvm_external) pick the "newest" version of any given artifact among all versions found in your transitive dependencies.
Truth 1.1 depends on version 30.0-android.
30.0-android is considered to be "newer" than 28.2-jre (because 30 is greater than 28).
The -android releases lack the Java 8 APIs.
(So you can actually fix this by depending on any -jre version from 30.0-jre up: 30.0-jre is considered "newer" than 30.0-android because of alphabetical order. Fun!)
Unfortunately, the Maven ecosystem doesn't support a good way to offer 2 "flavors" of every release (JRE+Android). (People often suggest the Maven "classifier," but that does not actually solve the problem.)
For the future:
Gradle: Gradle is working with us to provide its own solution, but it's not quite ready yet.
Maven: Maven is unlikely to provide help. (It doesn't even try to pick the "newest" version, let alone support "flavors.")
Bazel: I don't know if rules_jvm_external (which uses Coursier) has any plans to support "flavors." (Editorializing a bit: In an ideal world, I would rather specify all my repo's transitive dependencies and their versions myself, rather than having the build system try to work it out for me. That can help avoid surprises like this one. But that brings its own challenges, and we've made only incremental effort toward addressing them in our own Bazel-based projects.)
The recommendation is to use Microsoft.AspNetCore.All in .NET Core 2 as it simplifies dependencies and uses tree shaker magic to not bloat what you publish.
I encountered one issue of moving to it: When using a library that references StackExchange.Redis, I ended up with a conflict as something within Microsoft.AspNetCore.All references StackExchange.Redis.StrongName. See question VS.NET 2017 forces using StackExchange.Redis 1.2.4.0 in ASP.NET 2.0 Core app for further info. If I stick to referencing dependencies individually then I avoid this conflict and can compile.
Other than getting conflicts between things you don't use from Microsoft.AspNetCore.All, what are the other issues could you encounter because of this recommendation?
IMHO it is not a usual issue since there are not many libraries out there published twice with the same types, in two different packages: one strongly named and one not. Especially being referenced by the metapackage Microsoft.AspNetCore.All 2.0.0
You are definitely not the only one with this StackExchange.Redis issue (I stumbled across it twice already) but the maintainers are planning to drop the StrongName package on version 2.0.
You can try dealing with it with the extern alias approach discussed here.
A quick way around it is to target the same package AspNetCore targets (the StrongName one). In case it's just a project within a solution you work with, it's an easy hack.
Another is to target Microsoft.Extensions.Caching.Redis. That's what the metapackage depends on.
That's until SE.Redis releases version 2.0.0.
I've been working to get NuGet versioning squared away in my ASP Core project and have come across some odd behaviors and would like to ask why they decided to do it this way.
1) Choose the lowest version in a range.
ex: [1.0.0, 2.0.0) Does not mean choose the most recentversion in 1.X.X but choose the lowest version, basically always 1.0.0 and never update.
2) Setting the specific version chooses a different version
ex: "1.0.0" will really select "1.0.X".
This one really concerns me. I want to make sure that when I tag code, using a specific version, all future builds will always use the same version. With this implementation, builds are not guaranteed to be reproducible!
I'm coming from using Maven and NPM and am trying to keep an open mind to other ways of doing versioning, but these two baffle me.
Please help me understand why they would do this, basically backwards from other package manager solutions.
You can use a floating version if you want the most recent version, ex 1.0.*.
I think you're incorrect here. If 1.0.0 is requested, it'll install 1.0.0 if 1.0.0 is available on the NuGet server. If it's not found on the server, it'll install the next closest version found, 1.0.1.
This is pretty well documented at
http://docs.nuget.org/consume/ProjectJson-Dependency#dependency-resolution-in-nuget-v3-/-project.json
I'm trying to use a third party commercial JS library in my angular-meteor project
The vendor just informed me, that they only support angular version 1.3.11
Is there a way to install urigu:angular-meteor with this specific version of angular?
According to the meteor documentation you can set a version using #= so it should be like that:
meteor add angularjs:angular#=1.3.11
However, doing so you might have versions conflict like that:
>meteor add angularjs:angular#=1.3.11
=> Errors while adding packages:
While selecting package versions:
error: Potentially incompatible change required to top-level dependency: urigo:angular 0.6.8, was 0.8.4.
Constraints on package "urigo:angular":
To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.
So you have here few alternatives:
Downgrade urigo:angular: I think this is not a good option, there might be major changes since the package is pretty new.
Convince the vendor to "take the risk"
Since angular is much more mature that angular-meteor and 1.3.11 to 1.3.15 should not have breaking changes, this option have a clear advantage.
If you do wish to use the first option, add --allow-incompatible-update to the command line.
I have a an sbt multiproject (sbt 0.11.3) where one of the sub-projects is a PlayProject using play sbt-plugin 2.0.1) and another is my application logic. My application needs to use 0.4.1 version of com.typesafe.Config but I believe the play plugin seems to embed an older version 0.2.1 which causes a conflict when I perform a dist (create a jar) where one of the new methods does not exist in 0.2.1.
I want to know if there is a way I can exclude the old version and only have the new one. I have tired many methods without success (excludes, filtration[If I did that properly at all], etc..)
Thanks in advance to the wizard who either can tell me explicitly how to make this happen, or the chap that tells me it isn't going to happen and why.
Answer:
There was not a good way. The only way was to open the jar remove the config classes in akka and repackage. This was not going to work for us, so I used the older version of the config.