I have a maven project with many dependencies, two of them primefaces-extensions and hapi-fhir-base, both of them needs commons-lang3, but primefaces declares version 3.1 as dependency, but hapi needs >= 3.2. Is safe to assume that commons-lang3 3.4 will be fine for primefaces if it declares 3.1 as dependency version ?
See the release notes:
For 3.4 compatibility to 3.3.x:
Commons Lang 3.4 is fully binary compatible to the last release and
can therefore be used as a drop in replacement for 3.3.2.
For 3.3.x to 3.1:
This release introduces backwards incompatible changes in
org.apache.commons.lang3.time.FastDateFormat:
Method 'protected java.util.List parsePattern()' has been removed
Method 'protected java.lang.String parseToken(java.lang.String, int[])' has been removed
Method 'protected org.apache.commons.lang3.time.FastDateFormat$NumberRule. selectNumberRule(int, int)' has been removed
These changes were the result of [LANG-462]. It is assumed that this
change will not break clients
So it should work, as long as the changes in FastDateFormat are not breaking your code, which the developers think should not be possible.
Related
While debugging compilation errors of the generated Protobuf code after upgrading a Scala project to Gradle 6 & Zinc 1.3.5 I found that the compiler classpath contains two versions of the protobuf jar - the one I need (3.9.x) and 3.7. The latter is a dependency of the Zinc.
What is the correct way to run Zinc Scala build in Gradle without leaking its own dependencies to the classpath?
This was resolved with sbt/zinc PR 799 that was merged and included in the 1.4.0 release of Zinc.
With this MR they started shading the protobuf dependency (see this commit).
Unfortunately, it's not currently possible to use this version of Zinc with Gradle as Gradle issue #15491 was never resolved (note the issue title mentions Zinc 1.4.3 but applies for all versions of Zinc after the 1.3.x series).
It doesn't look like there's any plans to address #15491 but it looks like the issue will get solved as a side-effect of PR 18001 which is actively being developed with the intention of adding Scala 3 support to Gradle (and also involves cleaning up various long standing issues classpath related issues).
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).
I have learned that Scala is suffering from a limitation, that all Scala bytecodes needs to be generated from same compiler version. e.g. I cannot have a library built for 2.9 to work with my application which is built by 2.9.1
http://lift.la/blog/scalas-version-fragility-make-the-enterprise
I tried to search from the web for more discussion on this issue but cannot find much updates. Is this issue, as in Scala 2.11.6, fixed in any extend?
In Scala, the 'middle' number in the version string is the major version, so in 2.10.x and 2.11.x, the major version is 10 and 11 respectively.
Major versions are binary compatible. Therefore, if you have a library compiled against Scala 2.11.0, you can safely use it in a project that uses 2.11.6 without recompilation, and vice versa. If your library was compiled for Scala 2.10.5, you would have to compile it newly to use in a Scala 2.11.x project.
If your code doesn't call into deprecated API, it should be source compatible with the subsequent major version.
Most libraries are published for at least two major versions at the same time, so there is quite a bit of elasticity. Take an example, Scalaz, it has its latest artifacts cross-built for Scala 2.9.3, Scala 2.10.x, and Scala 2.11.x.
since the 2.6.0 release of GWT which dropped support of ie6 browser my current project which also uses GXT is failing to compile with the following error:
Loading inherited module 'com.sencha.gxt.ui.GXT'
Loading inherited module 'com.sencha.gxt.data.Data'
Loading inherited module 'com.sencha.gxt.core.Core'
[ERROR] The value ie6 was not previously defined.
[ERROR] Line 96: Unexpected exception while processing element 'set-property'
i tried to set
<set-property name="gxt.user.agent" value="safari3, safari4, safari5, chrome, air, gecko1_8, gecko1_9"/> and the <extend-property name="user.agent" ....../>
but without any success. Are there any workarounds on this?
GWT 2.6.0 has several breaking changes over GWT 2.4.0 and 2.5.1 - these don't affect all libraries, but they do affect both GXT 2 and 3. Code changes in GWT 2.6.0 that break libraries like GXT include:
Changing permutations (ie6 and opera are gone, ie10 was added, note that newer versions of opera are webkit based and do not need their own permutation)
Element added new final methods hasClassName and toggleClassName that can't compiled with XElement methods of the same name
String utils methods removed, switched to newer version of Guava (which now uses those methods)
Saw an upvote, so I know this is still getting readers months later, so editing this to point out that GXT 3.1.0 is in maven central and supports GWT 2.6.0, 2.6.1, and as of Friday anyway, supports GWT 2.7.0-SNAPSHOT. I can't promise it is totally future-proof, but as long no public methods in GWT change, it isn't likely to break again in the GWT 2.7 series.
while compiling from GWT 2.1 to 2.4, the following error is shown:
Found interface com.google.gwt.core.ext.typeinfo.JClassType, but class was expected
so kindly provide me with the solution to this issue.
There's a binary backwards-incompatibility in GWT 2.2 (where com.google.gwt.core.ext.typeinfo.JClassType et al. were changed from classes to interfaces). You have to update your third-party dependencies with ones that have been compiled against the GWT 2.2 SDK or a newer version; for your own library or if the third-party lib has been somewhat abandoned, you'll have to recompile it (javac).
GIN for example provides 2 builds of its 1.5 release: one compatible with GWT 2.1.1 and older, and one compatible with 2.2 onwards (there are two distinct JARs in the gwt-1.5.zip download).