Re: [Discussion] Persistence compatibility framework refactoring

[Vyacheslav Daradur]

Pavel,

>> A new version of Ignite has released and a developer should update
>> compatibility tests to run it against the new version.

Now I think that understand a problem which you are trying to solve,
but I'd suggest another solution:
In unit-testing world such problems usually is solved similar way as
parameterized tests in JUnit.
>From my point of view we should implement test-runner supported
annotation, for example:

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.FIELD})
@Inherited
public @interface RunWithIgnite {
IgniteVersion since() default IgniteVersion.ver2_1;
IgniteVersion until();
}

So, a developer will be able use annotation to run a test with
different Ignite's versions.
I believe that it is much flexible solution in comparison with new
framework since we are still able to run nodes of directly defined
version.

>>  I still don't understand why this version was explicitly added and
>> not just inherited from ignite-indexing. If we delegate all dependency
>> management to Maven itself it will simplify tests development. Tests will
>> look much simpler.

At the current implementation, we build a classpath based on statement
"full current classpath with replaced ignite-core artifacts". In you
example, test relates to "ignite-indexing" module which changed H2
dependency version in one of previous version, so the dependency had
to be excluded directly in tests.

If it's a problem for us, this can be solved easily with a new
approach to build class path based on statement "only ignite-core
module + compatibility module". Look at
"IgniteCompatibilityAbstractTest#getDependencies" for more details.

>> Suppose you have a closure that invokes some deprecated method which will
>> be removed in next release. After method removal, such tests will be
>> broken. At the current framework, I can't see a resolution of that problem.

There is not such problem in the current framework, you described an
issue which will be in a new framework without restricting "compatible
version" for test.
Anyway see my suggestion about the annotation above, it solves
described issue too.

In summary, all described issues (if they are issues really) can be
easily solved in the current framework. I see no reason in a new
framework with restricting current API.

What do you think?

On Wed, Feb 20, 2019 at 5:00 PM Dmitriy Pavlov  wrote:
>
> Just a reminder: Veto is valid with justification. I see no reasons either
> (need some time to dive into details), but it is not a reason for a veto.
>
> ср, 20 февр. 2019 г. в 16:39, Anton Vinogradov :
>
> > Dmitriy,
> >
> > Please stop chilling community :)
> > No one makes final decisions here.
> > Please make sure you've got my position before chilling :)
> >
> > I see no arguments to replace one solution with another.
> > In case no real reasons will be provided this merge will gain my Veto, just
> > a warning...
> >
> > On Wed, Feb 20, 2019 at 4:37 PM Nikolay Izhikov 
> > wrote:
> >
> > > Dmitriy,
> > >
> > > > So I suggest chilling a couple of days without any discussion.
> > >
> > > Why you trying to stop regular, positive dev-list discussion?
> > >
> > > I think, we should have a strong reason to throw away some subsystem and
> > > completely rewrite it.
> > > We will damage product robustness with it.
> > >
> > > >> 1. Automatic tests scaling for new versions.
> > > >> 2. Automatic dependency management.
> > >
> > > This features needed by Ignite, for sure.
> > > Pavel, can we extend current solution with new framework features?
> > >
> > >
> > >
> > > ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :
> > >
> > > > Hi, please do not rush to make any final decision. I think we all need
> > > some
> > > > time to think about these 2 solutions.
> > > >
> > > > So I suggest chilling a couple of days without any discussion.
> > > >
> > > > Later we can come back to this topic and dive into it once again, maybe
> > > we
> > > > can merge it into one taking the best parts of both.
> > > >
> > > > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> > > >
> > > > > >> 1. Automatic tests scaling for new versions.
> > > > > >> 2. Automatic dependency management.
> > > > > Let's just improve the current solution.
> > > > > See no problems here.
> > > > >
> > > > > You'll have my *Veto* on merge without real reasons to replace
> > solution
> > > > > instead of improvement.
> > > > >
> > > > > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > > > > wrote:
> > > > >
> > > > > > Anton,
> > > > > >
> > > > > > In my first message, I already noticed the usability problems of
> > the
> > > > > > current framework and showed how they can be solved using the new
> > > > > > framework.
> > > > > > It gives us 2 major advantages:
> > > > > > 1. Automatic tests scaling for new versions.
> > > > > > 2. Automatic dependency management.
> > > > > > Described approach simplifies tests writing and supporting.
> > > > > >
> > > > > > I don't see now how we can avoid 

Re: [Discussion] Persistence compatibility framework refactoring

[Dmitriy Pavlov]

Just a reminder: Veto is valid with justification. I see no reasons either
(need some time to dive into details), but it is not a reason for a veto.

ср, 20 февр. 2019 г. в 16:39, Anton Vinogradov :

> Dmitriy,
>
> Please stop chilling community :)
> No one makes final decisions here.
> Please make sure you've got my position before chilling :)
>
> I see no arguments to replace one solution with another.
> In case no real reasons will be provided this merge will gain my Veto, just
> a warning...
>
> On Wed, Feb 20, 2019 at 4:37 PM Nikolay Izhikov 
> wrote:
>
> > Dmitriy,
> >
> > > So I suggest chilling a couple of days without any discussion.
> >
> > Why you trying to stop regular, positive dev-list discussion?
> >
> > I think, we should have a strong reason to throw away some subsystem and
> > completely rewrite it.
> > We will damage product robustness with it.
> >
> > >> 1. Automatic tests scaling for new versions.
> > >> 2. Automatic dependency management.
> >
> > This features needed by Ignite, for sure.
> > Pavel, can we extend current solution with new framework features?
> >
> >
> >
> > ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :
> >
> > > Hi, please do not rush to make any final decision. I think we all need
> > some
> > > time to think about these 2 solutions.
> > >
> > > So I suggest chilling a couple of days without any discussion.
> > >
> > > Later we can come back to this topic and dive into it once again, maybe
> > we
> > > can merge it into one taking the best parts of both.
> > >
> > > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> > >
> > > > >> 1. Automatic tests scaling for new versions.
> > > > >> 2. Automatic dependency management.
> > > > Let's just improve the current solution.
> > > > See no problems here.
> > > >
> > > > You'll have my *Veto* on merge without real reasons to replace
> solution
> > > > instead of improvement.
> > > >
> > > > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > > > wrote:
> > > >
> > > > > Anton,
> > > > >
> > > > > In my first message, I already noticed the usability problems of
> the
> > > > > current framework and showed how they can be solved using the new
> > > > > framework.
> > > > > It gives us 2 major advantages:
> > > > > 1. Automatic tests scaling for new versions.
> > > > > 2. Automatic dependency management.
> > > > > Described approach simplifies tests writing and supporting.
> > > > >
> > > > > I don't see now how we can avoid manual versions adding and
> > supporting
> > > in
> > > > > test suites and avoid manual dependency management using custom
> java
> > > api
> > > > > for Maven in the current version of the framework.
> > > > > If you have ideas how these problems can be resolved in the current
> > > > version
> > > > > please share it.
> > > > >
> > > > > Nikolay,
> > > > >
> > > > > The new framework is designed for persistence compatibility first
> but
> > > can
> > > > > be used for thin client testing as well.
> > > > > It works exactly as you described. It collects all available
> testing
> > > > > versions by scanning pom files. Then it builds jars for all old
> > > versions
> > > > > using Maven.
> > > > > Test framework run compatibility tests against all detected old
> > > versions.
> > > > > The number of versions to test is controlled by a property.
> > > > > Some versions can be excluded for particular test suite or the user
> > can
> > > > > bound it using versions range.
> > > > > In all of these cases, there are no needs to copy-paste methods for
> > > each
> > > > of
> > > > > testing Ignite versions.
> > > > >
> > > > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov  >:
> > > > >
> > > > > > Hello, Pavel.
> > > > > >
> > > > > > Please, clarify.
> > > > > >
> > > > > > What exactly your new compatibility framework should check?
> > > > > > I know at lease 2 compatible subsystem in Ignite that should work
> > > with
> > > > > > previous versions:
> > > > > >
> > > > > > 1. Persistence.
> > > > > > 2. Thin client.
> > > > > >
> > > > > > > A new version of Ignite has released and a developer should
> > update
> > > > > > compatibility tests to run it against the new version.
> > > > > >
> > > > > > I propose to change current approach - check version X with
> version
> > > Y.
> > > > > > We should check X with X - 1 with X - 2 and so on, depending on
> our
> > > > > > compatibility policies.
> > > > > >
> > > > > > This approach should lead to the following:
> > > > > >
> > > > > > 1. Tests should contains only number of previous versions we
> should
> > > > > check.
> > > > > > 2. Test framework should build versions list internally and use
> it
> > to
> > > > run
> > > > > > tests.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > >
> > > > > >
> > > > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko <
> jokse...@gmail.com
> > >:
> > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Thank you for answers!
> > > > > > >
> > > > > > > >> I'm not sure what is a problem here?
> 

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

Dmitriy,

Please stop chilling community :)
No one makes final decisions here.
Please make sure you've got my position before chilling :)

I see no arguments to replace one solution with another.
In case no real reasons will be provided this merge will gain my Veto, just
a warning...

On Wed, Feb 20, 2019 at 4:37 PM Nikolay Izhikov  wrote:

> Dmitriy,
>
> > So I suggest chilling a couple of days without any discussion.
>
> Why you trying to stop regular, positive dev-list discussion?
>
> I think, we should have a strong reason to throw away some subsystem and
> completely rewrite it.
> We will damage product robustness with it.
>
> >> 1. Automatic tests scaling for new versions.
> >> 2. Automatic dependency management.
>
> This features needed by Ignite, for sure.
> Pavel, can we extend current solution with new framework features?
>
>
>
> ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :
>
> > Hi, please do not rush to make any final decision. I think we all need
> some
> > time to think about these 2 solutions.
> >
> > So I suggest chilling a couple of days without any discussion.
> >
> > Later we can come back to this topic and dive into it once again, maybe
> we
> > can merge it into one taking the best parts of both.
> >
> > ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
> >
> > > >> 1. Automatic tests scaling for new versions.
> > > >> 2. Automatic dependency management.
> > > Let's just improve the current solution.
> > > See no problems here.
> > >
> > > You'll have my *Veto* on merge without real reasons to replace solution
> > > instead of improvement.
> > >
> > > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > > wrote:
> > >
> > > > Anton,
> > > >
> > > > In my first message, I already noticed the usability problems of the
> > > > current framework and showed how they can be solved using the new
> > > > framework.
> > > > It gives us 2 major advantages:
> > > > 1. Automatic tests scaling for new versions.
> > > > 2. Automatic dependency management.
> > > > Described approach simplifies tests writing and supporting.
> > > >
> > > > I don't see now how we can avoid manual versions adding and
> supporting
> > in
> > > > test suites and avoid manual dependency management using custom java
> > api
> > > > for Maven in the current version of the framework.
> > > > If you have ideas how these problems can be resolved in the current
> > > version
> > > > please share it.
> > > >
> > > > Nikolay,
> > > >
> > > > The new framework is designed for persistence compatibility first but
> > can
> > > > be used for thin client testing as well.
> > > > It works exactly as you described. It collects all available testing
> > > > versions by scanning pom files. Then it builds jars for all old
> > versions
> > > > using Maven.
> > > > Test framework run compatibility tests against all detected old
> > versions.
> > > > The number of versions to test is controlled by a property.
> > > > Some versions can be excluded for particular test suite or the user
> can
> > > > bound it using versions range.
> > > > In all of these cases, there are no needs to copy-paste methods for
> > each
> > > of
> > > > testing Ignite versions.
> > > >
> > > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> > > >
> > > > > Hello, Pavel.
> > > > >
> > > > > Please, clarify.
> > > > >
> > > > > What exactly your new compatibility framework should check?
> > > > > I know at lease 2 compatible subsystem in Ignite that should work
> > with
> > > > > previous versions:
> > > > >
> > > > > 1. Persistence.
> > > > > 2. Thin client.
> > > > >
> > > > > > A new version of Ignite has released and a developer should
> update
> > > > > compatibility tests to run it against the new version.
> > > > >
> > > > > I propose to change current approach - check version X with version
> > Y.
> > > > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > > > compatibility policies.
> > > > >
> > > > > This approach should lead to the following:
> > > > >
> > > > > 1. Tests should contains only number of previous versions we should
> > > > check.
> > > > > 2. Test framework should build versions list internally and use it
> to
> > > run
> > > > > tests.
> > > > >
> > > > > What do you think?
> > > > >
> > > > >
> > > > >
> > > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko  >:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > Thank you for answers!
> > > > > >
> > > > > > >> I'm not sure what is a problem here?
> > > > > > At the moment it's a little bit hard to understand the impact of
> > > such a
> > > > > > change because the number of test suites is small.
> > > > > > Let's Imagine you have X compatibility test suites where X is a
> > > > > relatively
> > > > > > big number, let's say 20.
> > > > > > A new version of Ignite has released and a developer should
> update
> > > > > > compatibility tests to run it against the new version.
> > > > > > A developer should manually find all of these 20 test suites and
> in
> > 

Re: [Discussion] Persistence compatibility framework refactoring

[Nikolay Izhikov]

Dmitriy,

> So I suggest chilling a couple of days without any discussion.

Why you trying to stop regular, positive dev-list discussion?

I think, we should have a strong reason to throw away some subsystem and
completely rewrite it.
We will damage product robustness with it.

>> 1. Automatic tests scaling for new versions.
>> 2. Automatic dependency management.

This features needed by Ignite, for sure.
Pavel, can we extend current solution with new framework features?



ср, 20 февр. 2019 г. в 16:23, Dmitriy Pavlov :

> Hi, please do not rush to make any final decision. I think we all need some
> time to think about these 2 solutions.
>
> So I suggest chilling a couple of days without any discussion.
>
> Later we can come back to this topic and dive into it once again, maybe we
> can merge it into one taking the best parts of both.
>
> ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :
>
> > >> 1. Automatic tests scaling for new versions.
> > >> 2. Automatic dependency management.
> > Let's just improve the current solution.
> > See no problems here.
> >
> > You'll have my *Veto* on merge without real reasons to replace solution
> > instead of improvement.
> >
> > On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> > wrote:
> >
> > > Anton,
> > >
> > > In my first message, I already noticed the usability problems of the
> > > current framework and showed how they can be solved using the new
> > > framework.
> > > It gives us 2 major advantages:
> > > 1. Automatic tests scaling for new versions.
> > > 2. Automatic dependency management.
> > > Described approach simplifies tests writing and supporting.
> > >
> > > I don't see now how we can avoid manual versions adding and supporting
> in
> > > test suites and avoid manual dependency management using custom java
> api
> > > for Maven in the current version of the framework.
> > > If you have ideas how these problems can be resolved in the current
> > version
> > > please share it.
> > >
> > > Nikolay,
> > >
> > > The new framework is designed for persistence compatibility first but
> can
> > > be used for thin client testing as well.
> > > It works exactly as you described. It collects all available testing
> > > versions by scanning pom files. Then it builds jars for all old
> versions
> > > using Maven.
> > > Test framework run compatibility tests against all detected old
> versions.
> > > The number of versions to test is controlled by a property.
> > > Some versions can be excluded for particular test suite or the user can
> > > bound it using versions range.
> > > In all of these cases, there are no needs to copy-paste methods for
> each
> > of
> > > testing Ignite versions.
> > >
> > > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> > >
> > > > Hello, Pavel.
> > > >
> > > > Please, clarify.
> > > >
> > > > What exactly your new compatibility framework should check?
> > > > I know at lease 2 compatible subsystem in Ignite that should work
> with
> > > > previous versions:
> > > >
> > > > 1. Persistence.
> > > > 2. Thin client.
> > > >
> > > > > A new version of Ignite has released and a developer should update
> > > > compatibility tests to run it against the new version.
> > > >
> > > > I propose to change current approach - check version X with version
> Y.
> > > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > > compatibility policies.
> > > >
> > > > This approach should lead to the following:
> > > >
> > > > 1. Tests should contains only number of previous versions we should
> > > check.
> > > > 2. Test framework should build versions list internally and use it to
> > run
> > > > tests.
> > > >
> > > > What do you think?
> > > >
> > > >
> > > >
> > > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Thank you for answers!
> > > > >
> > > > > >> I'm not sure what is a problem here?
> > > > > At the moment it's a little bit hard to understand the impact of
> > such a
> > > > > change because the number of test suites is small.
> > > > > Let's Imagine you have X compatibility test suites where X is a
> > > > relatively
> > > > > big number, let's say 20.
> > > > > A new version of Ignite has released and a developer should update
> > > > > compatibility tests to run it against the new version.
> > > > > A developer should manually find all of these 20 test suites and in
> > > each
> > > > of
> > > > > these suites and add a new version to test it (new method).
> > > > > This is a long process and there could be developer mistakes, some
> of
> > > the
> > > > > test suites can be missed and nobody will know about it before real
> > > > > compatibility problem appears.
> > > > > We already faced with the situation when after new version release
> > > > > (2.5-2.6) no compatibility tests were modified to support new
> version
> > > > > because nobody remembers about it and there is no such process
> after
> > > > > release.
> > > > > Adding new pom is a very simple step and 

Re: [Discussion] Persistence compatibility framework refactoring

[Dmitriy Pavlov]

Hi, please do not rush to make any final decision. I think we all need some
time to think about these 2 solutions.

So I suggest chilling a couple of days without any discussion.

Later we can come back to this topic and dive into it once again, maybe we
can merge it into one taking the best parts of both.

ср, 20 февр. 2019 г. в 16:07, Anton Vinogradov :

> >> 1. Automatic tests scaling for new versions.
> >> 2. Automatic dependency management.
> Let's just improve the current solution.
> See no problems here.
>
> You'll have my *Veto* on merge without real reasons to replace solution
> instead of improvement.
>
> On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko 
> wrote:
>
> > Anton,
> >
> > In my first message, I already noticed the usability problems of the
> > current framework and showed how they can be solved using the new
> > framework.
> > It gives us 2 major advantages:
> > 1. Automatic tests scaling for new versions.
> > 2. Automatic dependency management.
> > Described approach simplifies tests writing and supporting.
> >
> > I don't see now how we can avoid manual versions adding and supporting in
> > test suites and avoid manual dependency management using custom java api
> > for Maven in the current version of the framework.
> > If you have ideas how these problems can be resolved in the current
> version
> > please share it.
> >
> > Nikolay,
> >
> > The new framework is designed for persistence compatibility first but can
> > be used for thin client testing as well.
> > It works exactly as you described. It collects all available testing
> > versions by scanning pom files. Then it builds jars for all old versions
> > using Maven.
> > Test framework run compatibility tests against all detected old versions.
> > The number of versions to test is controlled by a property.
> > Some versions can be excluded for particular test suite or the user can
> > bound it using versions range.
> > In all of these cases, there are no needs to copy-paste methods for each
> of
> > testing Ignite versions.
> >
> > ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
> >
> > > Hello, Pavel.
> > >
> > > Please, clarify.
> > >
> > > What exactly your new compatibility framework should check?
> > > I know at lease 2 compatible subsystem in Ignite that should work with
> > > previous versions:
> > >
> > > 1. Persistence.
> > > 2. Thin client.
> > >
> > > > A new version of Ignite has released and a developer should update
> > > compatibility tests to run it against the new version.
> > >
> > > I propose to change current approach - check version X with version Y.
> > > We should check X with X - 1 with X - 2 and so on, depending on our
> > > compatibility policies.
> > >
> > > This approach should lead to the following:
> > >
> > > 1. Tests should contains only number of previous versions we should
> > check.
> > > 2. Test framework should build versions list internally and use it to
> run
> > > tests.
> > >
> > > What do you think?
> > >
> > >
> > >
> > > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> > >
> > > > Vyacheslav,
> > > >
> > > > Thank you for answers!
> > > >
> > > > >> I'm not sure what is a problem here?
> > > > At the moment it's a little bit hard to understand the impact of
> such a
> > > > change because the number of test suites is small.
> > > > Let's Imagine you have X compatibility test suites where X is a
> > > relatively
> > > > big number, let's say 20.
> > > > A new version of Ignite has released and a developer should update
> > > > compatibility tests to run it against the new version.
> > > > A developer should manually find all of these 20 test suites and in
> > each
> > > of
> > > > these suites and add a new version to test it (new method).
> > > > This is a long process and there could be developer mistakes, some of
> > the
> > > > test suites can be missed and nobody will know about it before real
> > > > compatibility problem appears.
> > > > We already faced with the situation when after new version release
> > > > (2.5-2.6) no compatibility tests were modified to support new version
> > > > because nobody remembers about it and there is no such process after
> > > > release.
> > > > Adding new pom is a very simple step and can be done by any human who
> > > even
> > > > may not be familiar with the compatibility module and may not know
> > > anything
> > > > which compatibility tests are used. If we include adding pom file to
> > > > post-release process all existing tests will automatically detect new
> > > > version and next TC run will immediately show to us results. If there
> > are
> > > > some compatibility problems during development new version TC run
> will
> > > show
> > > > it. At the current approach, compatibility tests are out of focus and
> > we
> > > > may not see potential issues.
> > > >
> > > > >> This is not about usability, it's about the framework's internals
> > > > At the current approach, a developer should take care of dependency
> > > > management for 

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

>> 1. Automatic tests scaling for new versions.
>> 2. Automatic dependency management.
Let's just improve the current solution.
See no problems here.

You'll have my *Veto* on merge without real reasons to replace solution
instead of improvement.

On Wed, Feb 20, 2019 at 3:55 PM Pavel Kovalenko  wrote:

> Anton,
>
> In my first message, I already noticed the usability problems of the
> current framework and showed how they can be solved using the new
> framework.
> It gives us 2 major advantages:
> 1. Automatic tests scaling for new versions.
> 2. Automatic dependency management.
> Described approach simplifies tests writing and supporting.
>
> I don't see now how we can avoid manual versions adding and supporting in
> test suites and avoid manual dependency management using custom java api
> for Maven in the current version of the framework.
> If you have ideas how these problems can be resolved in the current version
> please share it.
>
> Nikolay,
>
> The new framework is designed for persistence compatibility first but can
> be used for thin client testing as well.
> It works exactly as you described. It collects all available testing
> versions by scanning pom files. Then it builds jars for all old versions
> using Maven.
> Test framework run compatibility tests against all detected old versions.
> The number of versions to test is controlled by a property.
> Some versions can be excluded for particular test suite or the user can
> bound it using versions range.
> In all of these cases, there are no needs to copy-paste methods for each of
> testing Ignite versions.
>
> ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :
>
> > Hello, Pavel.
> >
> > Please, clarify.
> >
> > What exactly your new compatibility framework should check?
> > I know at lease 2 compatible subsystem in Ignite that should work with
> > previous versions:
> >
> > 1. Persistence.
> > 2. Thin client.
> >
> > > A new version of Ignite has released and a developer should update
> > compatibility tests to run it against the new version.
> >
> > I propose to change current approach - check version X with version Y.
> > We should check X with X - 1 with X - 2 and so on, depending on our
> > compatibility policies.
> >
> > This approach should lead to the following:
> >
> > 1. Tests should contains only number of previous versions we should
> check.
> > 2. Test framework should build versions list internally and use it to run
> > tests.
> >
> > What do you think?
> >
> >
> >
> > ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
> >
> > > Vyacheslav,
> > >
> > > Thank you for answers!
> > >
> > > >> I'm not sure what is a problem here?
> > > At the moment it's a little bit hard to understand the impact of such a
> > > change because the number of test suites is small.
> > > Let's Imagine you have X compatibility test suites where X is a
> > relatively
> > > big number, let's say 20.
> > > A new version of Ignite has released and a developer should update
> > > compatibility tests to run it against the new version.
> > > A developer should manually find all of these 20 test suites and in
> each
> > of
> > > these suites and add a new version to test it (new method).
> > > This is a long process and there could be developer mistakes, some of
> the
> > > test suites can be missed and nobody will know about it before real
> > > compatibility problem appears.
> > > We already faced with the situation when after new version release
> > > (2.5-2.6) no compatibility tests were modified to support new version
> > > because nobody remembers about it and there is no such process after
> > > release.
> > > Adding new pom is a very simple step and can be done by any human who
> > even
> > > may not be familiar with the compatibility module and may not know
> > anything
> > > which compatibility tests are used. If we include adding pom file to
> > > post-release process all existing tests will automatically detect new
> > > version and next TC run will immediately show to us results. If there
> are
> > > some compatibility problems during development new version TC run will
> > show
> > > it. At the current approach, compatibility tests are out of focus and
> we
> > > may not see potential issues.
> > >
> > > >> This is not about usability, it's about the framework's internals
> > > At the current approach, a developer should take care of dependency
> > > management for the old versions. E.g. if you look
> > > at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2
> > dependency
> > > version. I still don't understand why this version was explicitly added
> > and
> > > not just inherited from ignite-indexing. If we delegate all dependency
> > > management to Maven itself it will simplify tests development. Tests
> will
> > > look much simpler.
> > >
> > > >> Please, describe the issue in more details?
> > > Suppose you have a closure that invokes some deprecated method which
> will
> > > be removed in next release. After method removal, such tests 

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

Anton,

In my first message, I already noticed the usability problems of the
current framework and showed how they can be solved using the new framework.
It gives us 2 major advantages:
1. Automatic tests scaling for new versions.
2. Automatic dependency management.
Described approach simplifies tests writing and supporting.

I don't see now how we can avoid manual versions adding and supporting in
test suites and avoid manual dependency management using custom java api
for Maven in the current version of the framework.
If you have ideas how these problems can be resolved in the current version
please share it.

Nikolay,

The new framework is designed for persistence compatibility first but can
be used for thin client testing as well.
It works exactly as you described. It collects all available testing
versions by scanning pom files. Then it builds jars for all old versions
using Maven.
Test framework run compatibility tests against all detected old versions.
The number of versions to test is controlled by a property.
Some versions can be excluded for particular test suite or the user can
bound it using versions range.
In all of these cases, there are no needs to copy-paste methods for each of
testing Ignite versions.

ср, 20 февр. 2019 г. в 12:45, Nikolay Izhikov :

> Hello, Pavel.
>
> Please, clarify.
>
> What exactly your new compatibility framework should check?
> I know at lease 2 compatible subsystem in Ignite that should work with
> previous versions:
>
> 1. Persistence.
> 2. Thin client.
>
> > A new version of Ignite has released and a developer should update
> compatibility tests to run it against the new version.
>
> I propose to change current approach - check version X with version Y.
> We should check X with X - 1 with X - 2 and so on, depending on our
> compatibility policies.
>
> This approach should lead to the following:
>
> 1. Tests should contains only number of previous versions we should check.
> 2. Test framework should build versions list internally and use it to run
> tests.
>
> What do you think?
>
>
>
> ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :
>
> > Vyacheslav,
> >
> > Thank you for answers!
> >
> > >> I'm not sure what is a problem here?
> > At the moment it's a little bit hard to understand the impact of such a
> > change because the number of test suites is small.
> > Let's Imagine you have X compatibility test suites where X is a
> relatively
> > big number, let's say 20.
> > A new version of Ignite has released and a developer should update
> > compatibility tests to run it against the new version.
> > A developer should manually find all of these 20 test suites and in each
> of
> > these suites and add a new version to test it (new method).
> > This is a long process and there could be developer mistakes, some of the
> > test suites can be missed and nobody will know about it before real
> > compatibility problem appears.
> > We already faced with the situation when after new version release
> > (2.5-2.6) no compatibility tests were modified to support new version
> > because nobody remembers about it and there is no such process after
> > release.
> > Adding new pom is a very simple step and can be done by any human who
> even
> > may not be familiar with the compatibility module and may not know
> anything
> > which compatibility tests are used. If we include adding pom file to
> > post-release process all existing tests will automatically detect new
> > version and next TC run will immediately show to us results. If there are
> > some compatibility problems during development new version TC run will
> show
> > it. At the current approach, compatibility tests are out of focus and we
> > may not see potential issues.
> >
> > >> This is not about usability, it's about the framework's internals
> > At the current approach, a developer should take care of dependency
> > management for the old versions. E.g. if you look
> > at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2
> dependency
> > version. I still don't understand why this version was explicitly added
> and
> > not just inherited from ignite-indexing. If we delegate all dependency
> > management to Maven itself it will simplify tests development. Tests will
> > look much simpler.
> >
> > >> Please, describe the issue in more details?
> > Suppose you have a closure that invokes some deprecated method which will
> > be removed in next release. After method removal, such tests will be
> > broken. At the current framework, I can't see a resolution of that
> problem.
> > In a new framework, you can keep the old version of closure, mark it with
> > special annotation and place to separate module with old Ignite version
> > dependency. This closure will be compiled using an old version of Ignite
> > and the user can still run it on the old version.
> >
> >
> >
> > вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :
> >
> > > Hi, Pavel!
> > >
> > > First of all, I'd like to clarify that the Compatibility 

Re: [Discussion] Persistence compatibility framework refactoring

[Nikolay Izhikov]

Hello, Pavel.

Please, clarify.

What exactly your new compatibility framework should check?
I know at lease 2 compatible subsystem in Ignite that should work with
previous versions:

1. Persistence.
2. Thin client.

> A new version of Ignite has released and a developer should update
compatibility tests to run it against the new version.

I propose to change current approach - check version X with version Y.
We should check X with X - 1 with X - 2 and so on, depending on our
compatibility policies.

This approach should lead to the following:

1. Tests should contains only number of previous versions we should check.
2. Test framework should build versions list internally and use it to run
tests.

What do you think?



ср, 20 февр. 2019 г. в 11:41, Pavel Kovalenko :

> Vyacheslav,
>
> Thank you for answers!
>
> >> I'm not sure what is a problem here?
> At the moment it's a little bit hard to understand the impact of such a
> change because the number of test suites is small.
> Let's Imagine you have X compatibility test suites where X is a relatively
> big number, let's say 20.
> A new version of Ignite has released and a developer should update
> compatibility tests to run it against the new version.
> A developer should manually find all of these 20 test suites and in each of
> these suites and add a new version to test it (new method).
> This is a long process and there could be developer mistakes, some of the
> test suites can be missed and nobody will know about it before real
> compatibility problem appears.
> We already faced with the situation when after new version release
> (2.5-2.6) no compatibility tests were modified to support new version
> because nobody remembers about it and there is no such process after
> release.
> Adding new pom is a very simple step and can be done by any human who even
> may not be familiar with the compatibility module and may not know anything
> which compatibility tests are used. If we include adding pom file to
> post-release process all existing tests will automatically detect new
> version and next TC run will immediately show to us results. If there are
> some compatibility problems during development new version TC run will show
> it. At the current approach, compatibility tests are out of focus and we
> may not see potential issues.
>
> >> This is not about usability, it's about the framework's internals
> At the current approach, a developer should take care of dependency
> management for the old versions. E.g. if you look
> at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2 dependency
> version. I still don't understand why this version was explicitly added and
> not just inherited from ignite-indexing. If we delegate all dependency
> management to Maven itself it will simplify tests development. Tests will
> look much simpler.
>
> >> Please, describe the issue in more details?
> Suppose you have a closure that invokes some deprecated method which will
> be removed in next release. After method removal, such tests will be
> broken. At the current framework, I can't see a resolution of that problem.
> In a new framework, you can keep the old version of closure, mark it with
> special annotation and place to separate module with old Ignite version
> dependency. This closure will be compiled using an old version of Ignite
> and the user can still run it on the old version.
>
>
>
> вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :
>
> > Hi, Pavel!
> >
> > First of all, I'd like to clarify that the Compatibility Testing
> > Framework was designed to work with a cluster of multi-version nodes.
> > The main idea is to run a test to verify backward compatibility or do
> > some kind of rolling upgrades.
> >
> > It's not about persistence compatibility, but actually, it is used for
> > this now.
> >
> > >> 1) It's uncomfortable to add and support new versions of Ignite
> product.
> >
> > I'm not sure what is a problem here?
> > As I understand you suggest to do similar things - adding new pom.xml
> > when new a version is released. Pay attention that not all tests
> > should be tested on all versions, some test may want to test specific
> > versions each other.
> >
> > >> 2) Manual maven dependency through java api.
> >
> > This is not about usability, it's about the framework's internals. If
> > you have issues let's fix it and improve approach if needed.
> >
> > >> 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.
> >
> > Please, describe the issue in more details?
> >
> > On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> > wrote:
> > >
> > > Anton,
> > >
> > > >> What about the current compatibility framework?
> > > Current compatibility framework will be removed after final adjusting
> to
> > > new framework.
> > >
> > > >> Could you please share examples for each feature you mentioned?
> > > You can see example in PR e.g. file
> > > 

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

Vyacheslav,

Thank you for answers!

>> I'm not sure what is a problem here?
At the moment it's a little bit hard to understand the impact of such a
change because the number of test suites is small.
Let's Imagine you have X compatibility test suites where X is a relatively
big number, let's say 20.
A new version of Ignite has released and a developer should update
compatibility tests to run it against the new version.
A developer should manually find all of these 20 test suites and in each of
these suites and add a new version to test it (new method).
This is a long process and there could be developer mistakes, some of the
test suites can be missed and nobody will know about it before real
compatibility problem appears.
We already faced with the situation when after new version release
(2.5-2.6) no compatibility tests were modified to support new version
because nobody remembers about it and there is no such process after
release.
Adding new pom is a very simple step and can be done by any human who even
may not be familiar with the compatibility module and may not know anything
which compatibility tests are used. If we include adding pom file to
post-release process all existing tests will automatically detect new
version and next TC run will immediately show to us results. If there are
some compatibility problems during development new version TC run will show
it. At the current approach, compatibility tests are out of focus and we
may not see potential issues.

>> This is not about usability, it's about the framework's internals
At the current approach, a developer should take care of dependency
management for the old versions. E.g. if you look
at IgnitePKIndexesMigrationToUnwrapPkTest you can see "magic" H2 dependency
version. I still don't understand why this version was explicitly added and
not just inherited from ignite-indexing. If we delegate all dependency
management to Maven itself it will simplify tests development. Tests will
look much simpler.

>> Please, describe the issue in more details?
Suppose you have a closure that invokes some deprecated method which will
be removed in next release. After method removal, such tests will be
broken. At the current framework, I can't see a resolution of that problem.
In a new framework, you can keep the old version of closure, mark it with
special annotation and place to separate module with old Ignite version
dependency. This closure will be compiled using an old version of Ignite
and the user can still run it on the old version.



вт, 19 февр. 2019 г. в 21:44, Vyacheslav Daradur :

> Hi, Pavel!
>
> First of all, I'd like to clarify that the Compatibility Testing
> Framework was designed to work with a cluster of multi-version nodes.
> The main idea is to run a test to verify backward compatibility or do
> some kind of rolling upgrades.
>
> It's not about persistence compatibility, but actually, it is used for
> this now.
>
> >> 1) It's uncomfortable to add and support new versions of Ignite product.
>
> I'm not sure what is a problem here?
> As I understand you suggest to do similar things - adding new pom.xml
> when new a version is released. Pay attention that not all tests
> should be tested on all versions, some test may want to test specific
> versions each other.
>
> >> 2) Manual maven dependency through java api.
>
> This is not about usability, it's about the framework's internals. If
> you have issues let's fix it and improve approach if needed.
>
> >> 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.
>
> Please, describe the issue in more details?
>
> On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> wrote:
> >
> > Anton,
> >
> > >> What about the current compatibility framework?
> > Current compatibility framework will be removed after final adjusting to
> > new framework.
> >
> > >> Could you please share examples for each feature you mentioned?
> > You can see example in PR e.g. file
> > modules/compatibility/ignite-versions/2.1.0/pom.xml
> > <
> https://github.com/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc
> >
> >
> > I think such representing of Ignite product version is more cleaner than
> > existing approach with Java classes with dependencies and manual
> dependecy
> > management.
> >
> > >> Anyway. I don't like the idea to implement something new instead of
> > improving the existing.
> > If you have concrete proposals how to improve current framework please
> > share it.
> >
> >
> > вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :
> >
> > > +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.
> 

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

Fully agree with Slava,

Pavel, please share your vision of compatibility framework (current and
desired).
It really looks like you don't love current just because you can't
understand how to use it properly.
But this should not mean we have to remove the current, we should
improve/refactor/document it instead, if necessary.

Please share features you're not able to implement using the current
framework, whole list.
And we will help you to find improvement way instead of replacement.

Evolution is always better than a revolution.

Viva La Evolucion! :)

On Tue, Feb 19, 2019 at 9:44 PM Vyacheslav Daradur 
wrote:

> Hi, Pavel!
>
> First of all, I'd like to clarify that the Compatibility Testing
> Framework was designed to work with a cluster of multi-version nodes.
> The main idea is to run a test to verify backward compatibility or do
> some kind of rolling upgrades.
>
> It's not about persistence compatibility, but actually, it is used for
> this now.
>
> >> 1) It's uncomfortable to add and support new versions of Ignite product.
>
> I'm not sure what is a problem here?
> As I understand you suggest to do similar things - adding new pom.xml
> when new a version is released. Pay attention that not all tests
> should be tested on all versions, some test may want to test specific
> versions each other.
>
> >> 2) Manual maven dependency through java api.
>
> This is not about usability, it's about the framework's internals. If
> you have issues let's fix it and improve approach if needed.
>
> >> 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.
>
> Please, describe the issue in more details?
>
> On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko 
> wrote:
> >
> > Anton,
> >
> > >> What about the current compatibility framework?
> > Current compatibility framework will be removed after final adjusting to
> > new framework.
> >
> > >> Could you please share examples for each feature you mentioned?
> > You can see example in PR e.g. file
> > modules/compatibility/ignite-versions/2.1.0/pom.xml
> > <
> https://github.com/apache/ignite/pull/5974/files#diff-3c44ef223c31de9ff1e10bd7699cbcdc
> >
> >
> > I think such representing of Ignite product version is more cleaner than
> > existing approach with Java classes with dependencies and manual
> dependecy
> > management.
> >
> > >> Anyway. I don't like the idea to implement something new instead of
> > improving the existing.
> > If you have concrete proposals how to improve current framework please
> > share it.
> >
> >
> > вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :
> >
> > > +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 
> > > 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 

Re: [Discussion] Persistence compatibility framework refactoring

[Vyacheslav Daradur]

Hi, Pavel!

First of all, I'd like to clarify that the Compatibility Testing
Framework was designed to work with a cluster of multi-version nodes.
The main idea is to run a test to verify backward compatibility or do
some kind of rolling upgrades.

It's not about persistence compatibility, but actually, it is used for this now.

>> 1) It's uncomfortable to add and support new versions of Ignite product.

I'm not sure what is a problem here?
As I understand you suggest to do similar things - adding new pom.xml
when new a version is released. Pay attention that not all tests
should be tested on all versions, some test may want to test specific
versions each other.

>> 2) Manual maven dependency through java api.

This is not about usability, it's about the framework's internals. If
you have issues let's fix it and improve approach if needed.

>> 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.

Please, describe the issue in more details?

On Tue, Feb 19, 2019 at 7:55 PM Pavel Kovalenko  wrote:
>
> Anton,
>
> >> What about the current compatibility framework?
> Current compatibility framework will be removed after final adjusting to
> new framework.
>
> >> Could you please share examples for each feature you mentioned?
> You can see example in PR e.g. file
> modules/compatibility/ignite-versions/2.1.0/pom.xml
> 
>
> I think such representing of Ignite product version is more cleaner than
> existing approach with Java classes with dependencies and manual dependecy
> management.
>
> >> Anyway. I don't like the idea to implement something new instead of
> improving the existing.
> If you have concrete proposals how to improve current framework please
> share it.
>
>
> вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :
>
> > +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 
> > 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 

Re: [Discussion] Persistence compatibility framework refactoring

[Pavel Kovalenko]

Anton,

>> What about the current compatibility framework?
Current compatibility framework will be removed after final adjusting to
new framework.

>> Could you please share examples for each feature you mentioned?
You can see example in PR e.g. file
modules/compatibility/ignite-versions/2.1.0/pom.xml


I think such representing of Ignite product version is more cleaner than
existing approach with Java classes with dependencies and manual dependecy
management.

>> Anyway. I don't like the idea to implement something new instead of
improving the existing.
If you have concrete proposals how to improve current framework please
share it.


вт, 19 февр. 2019 г. в 19:11, Anton Vinogradov :

> +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 
> 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.
> >
>

Re: [Discussion] Persistence compatibility framework refactoring

[Anton Vinogradov]

+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  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.
>