Hi Everyone,
I've coded a possible solution in the test project. See here:
https://github.com/Randgalt/curator_5_0_test/blob/master/combo/pom.xml#L49
<https://github.com/Randgalt/curator_5_0_test/blob/master/combo/pom.xml#L49>
It uses the Maven dependency plugin to create a small compatibility JAR that
contains the Curator 4.3.0 versions of the classes that have changed in 5.0.0
(i.e. the ones that no longer return ListenerContainer). If this JAR is
included in a CLASSPATH before Curator 5.0.0's JARs, these old classes will
take precedence and thus old binaries will continue to work. The
curator_5_0_test shows this. run.sh is the previous way with the error.
run-compatibility.sh is with the compatibility JAR.
Thoughts? Notable, this doesn't change the master code of Curator at all. We
could add it to the 5.0 release. I don't think there's an issue with this
"hack". Can anyone think of one? I'd really appreciate people testing with it.
Try a build with just Curator 5.0 and then install and include this
curator-5_0-test:combo:1.0-SNAPSHOT early in the CLASSPATH - it should work.
-Jordan
> On May 21, 2020, at 10:43 AM, Jordan Zimmerman <jor...@jordanzimmerman.com>
> wrote:
>
> Hello All,
>
> Sorry for the cross-posting but this is important enough to justify it.
>
> Apache Curator is in the process of releasing version 5.0. We've taken the
> opportunity to address some long standing tech debt but this causes breaking
> changes. We've detailed the breaks here:
> http://curator.apache.org/staging/breaking-changes.html
> <http://curator.apache.org/staging/breaking-changes.html>. The Clirr report
> shows the exact API changes:
> http://curator.apache.org/staging/curator-recipes/clirr-report.html
> <http://curator.apache.org/staging/curator-recipes/clirr-report.html>. The
> first two of these are the most worrisome. NodeCache's and
> PathChildrenCache's getListenable() methods now have a different return type.
> This has far reaching implications. If a Curator user were to drop in Curator
> 5.0 without any code changes they will get runtime exceptions when these
> methods are called.
>
> I've written a test that shows the problem:
>
> git clone https://github.com/Randgalt/curator_5_0_test.git
> <https://github.com/Randgalt/curator_5_0_test.git>
> cd curator_5_0_test
> ./run.sh
>
> You will see:
>
> java.lang.NoSuchMethodError:
> org.apache.curator.framework.recipes.cache.PathChildrenCache.getListenable()Lorg/apache/curator/framework/listen/ListenerContainer;
> at binary.Curator50Test.run(Curator50Test.java:26)
> at test.Test.main(Test.java:9)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:748)
>
> Enrico Olivelli brought this to our attention. Curator 5.0 is a major version
> bump so breaking changes are implied. But, maybe this is blocker? What do
> people think? If this is a serious enough concern we can come up with a
> workaround.
>
> Please discuss and let's hold off completing the current release until this
> has been fully discussed.
>
> -Jordan
