+5,327 −59 What about the current compatibility framework? I see no removal or updates.
>> Each new version is represented by a single pom Sound not good. Could you please share examples for each feature you mentioned? Anyway. I don't like the idea to implement something new instead of improving the existing. On Tue, Feb 19, 2019 at 6:48 PM Pavel Kovalenko <jokse...@gmail.com> wrote: > Igniters, > > I would like to start a discussion about replacement existing > persistence compatibility test framework with the newer version. > The main purpose of that action is simplifying compatibility tests > development and support. > > The current version of the test framework has 3 disadvantages: > 1) It's uncomfortable to add and support new versions of Ignite product. > When a new version has released a developer must manually add new test > methods to all existing test suites to support the new product version. > 2) Manual maven dependency through java api. > If a new version of Ignite product has some specific dependency version > (like H2) a developer should take care about and manually cover this case > using java api. > 3) It doesn't cover the case when some code which works on the current > version will not work on older versions due to compile/runtime > incompatibility. > > A new version of the framework that is under development right now [1] > doesn't have such problems. > Here is a list of key features and possibilities: > > 1) One codebase - multiple versions support. > The key feature of the new framework is significant simplifying adding and > supporting the new versions of Ignite product. > Each new version is represented by a single pom file that contains Ignite > dependencies of specific version (core, indexing, etc.). All subdependecies > like H2 are covered by Maven automatically. > To add a new version for compatibility a developer just need to add a new > pom file with a new version of Ignite. All existing tests will > automatically detect the new version and will run tests against this > version without additional changes. This feature covers p. 1 and 2 of the > existing framework. > 2) Unified API to access and run code on old and new versions of Ignite. > Each of Ignite instance is represented by remote JVM with a single point of > interaction - running abstract closures. Each closure is just a class which > implement a "runner interface". Each closure object is serialized to a file > through Xstream library and executed on remote Ignite JVM. This approach > gives unified access to interact with both old and new versions of Ignite > and simplifies overall tests development. > 3) Ignite versions support for closures. Sometimes a closure couldn't be > run on newer or older Ignite version due to compile/runtime incompatibility > of that code. To resolve this problem a special annotation has introduced. > This annotation named as "@Since" contains minimal possible Ignite product > version where annotated closure can be compiled and run. Such closures are > processed on Ignite versions compile phase and this makes it possible to > use one closure for multiple Ignite versions without additional code > changes. Closures and versioning resolve p. 3 of the existing framework. > > [1] - https://issues.apache.org/jira/browse/IGNITE-11133 > > I would like to hear any opinions about the new framework. >
