I agree with Cameron here. If you absolutely have to have binary compatibility you can use the hack I created at https://github.com/Randgalt/curator_5_0_test <https://github.com/Randgalt/curator_5_0_test> - if need be, we can distributed the hack with 5.0.
CURATOR COMMUNITY - PLEASE CHIME IN HERE - The decision we make here will affect Curator for a long time. Now's your chance to have input on that direction. -Jordan > On May 24, 2020, at 3:48 PM, Cameron McKenzie <cammcken...@apache.org> wrote: > > Enrico, > Can you explain your environment that exposes these backwards > compatibility issues? I am probably coming from a place of ignorance, but I > haven't seen new versions of a third party binary being dropped into an > existing environment without recompiling the application, so I have never > encountered these binary compatibility issues before. My expectation with > this release was that if you wanted to pickup the changes in Curator 5.0 > that you would rebuild your application against the new binaries and then > redeploy the application. Obviously this compilation will break if you are > using any of the changed APIs, but they are pretty trivial change to fix. > We could potentially deprecate the existing APIs and add the new ones, but > this will produce more tech debt to clean up later. > cheers > > On Sat, May 23, 2020 at 7:40 PM Enrico Olivelli <eolive...@gmail.com> wrote: > >> I will check you trick ad soon as possible. I am sorry, this is a very >> busy week for me and do not have enough cycles. But I think that we should >> address this problem in order to ease the adoption of the new code and APIs. >> >> Did you evaluate to eventually rollback the breaking changes? >> >> Another alternative, if we want to let users use both the old and the new >> APIs is to simply rename all of the packages and start a brand new system. >> This approach was done in Apache Commons and IIRC it will be done with >> Netty5. We also did it with the new Apache Bookkeeper API. >> >> Pros: >> No need to preserve compatibility, we are free to clean up all of the tech >> debt. >> The switch to Curator 5 will be explicit opted in >> >> Cons: >> Cherry picks won't be straightforward. >> >> Enrico >> >> Il Ven 22 Mag 2020, 23:40 Jordan Zimmerman <jor...@jordanzimmerman.com> >> ha scritto: >> >>> 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 >>> >>> 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. The Clirr >>> report shows the exact API changes: >>> 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 >>> 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 >>> >>> >>>
