[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-08-09 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903869#comment-16903869
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

Seems that the .net problem is the last one.

I brought the full context of the problem in the conversation. The problem is 
more general, JUnit migration looks like a consequence, not a cause.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Test-naming-on-TC-JUnit-5-tp42750p42810.html


> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-08-09 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903869#comment-16903869
 ] 

Ivan Fedotov edited comment on IGNITE-10973 at 8/9/19 1:05 PM:
---

[~Pavlukhin], Seems that the .net problem is the last one.

I brought the full context of the problem in the conversation. The problem is 
more general, JUnit migration looks like a consequence, not a cause.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Test-naming-on-TC-JUnit-5-tp42750p42810.html



was (Author: ivanan.fed):
Seems that the .net problem is the last one.

I brought the full context of the problem in the conversation. The problem is 
more general, JUnit migration looks like a consequence, not a cause.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Test-naming-on-TC-JUnit-5-tp42750p42810.html


> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-31 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897268#comment-16897268
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin] I delivered information about migration to the community.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-31 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897268#comment-16897268
 ] 

Ivan Fedotov edited comment on IGNITE-10973 at 7/31/19 3:09 PM:


[~Pavlukhin], I delivered information about migration to the community.


was (Author: ivanan.fed):
[~Pavlukhin] I delivered information about migration to the community.

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891243#comment-16891243
 ] 

Ivan Fedotov edited comment on IGNITE-10973 at 7/23/19 5:54 PM:


[~Pavlukhin] ,

According to Parametrized test - I added a new dependency in the last commit. 
We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is 
simplier than in the fourth version. Rule and ClassRule annotations can be 
replaced by Extension and ExtendWith respectively.

According to .net tests: the reason for failures is the only one: "The filename 
or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath 
because other args are hardcoded. I compared the log files from my branch [2] 
and master [3]. For some reason, jvmClasspath
contains all maven dependencies. Because of addition more dependencies to pom 
file, this string becomes too long for system .net function. I guess that it is 
not correct behavior of Classpath.cs#CreateClasspath function, because if we 
need to add some more dependencies to pom file, we faced this problem. 
Moreover, it is not jvmClasspath, it's the enumeration of all jat files.

[1] 
[https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148]
 [2] 
[https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning]
 [3] 
[https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4381131&_focus=53179]


was (Author: ivanan.fed):
[~Pavlukhin] ,

According to Parametrized test - I added a new dependency in the last commit. 
We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is 
simplier than in the fourth version. Rule and ClassRule annotations can be 
replaced by Extension and ExtendWith respectively.

According to .net tests: the reason for failures is the only one: "The filename 
or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath 
because other args are hardcoded. I compared the log files from my branch[2] 
and master[3]. For some reason, jvmClasspath
contains all maven dependencies. Because of addition more dependencies to pom 
file, this string becomes too long for system .net function. I guess that it is 
not correct behavior of Classpath.cs#CreateClasspath function, because if we 
need to add some more dependencies to pom file, we faced this problem. 
Moreover, it is not jvmClasspath, it's the enumeration of all jat files.

[1] 
[https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148]
 [2] 
[https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning]
 [3] 
[https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4381131&_focus=53179]

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891243#comment-16891243
 ] 

Ivan Fedotov edited comment on IGNITE-10973 at 7/23/19 5:44 PM:


[~Pavlukhin] ,

According to Parametrized test - I added a new dependency in the last commit. 
We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is 
simplier than in the fourth version. Rule and ClassRule annotations can be 
replaced by Extension and ExtendWith respectively.

According to .net tests: the reason for failures is the only one: "The filename 
or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath 
because other args are hardcoded. I compared the log files from my branch[2] 
and master[3]. For some reason, jvmClasspath
contains all maven dependencies. Because of addition more dependencies to pom 
file, this string becomes too long for system .net function. I guess that it is 
not correct behavior of Classpath.cs#CreateClasspath function, because if we 
need to add some more dependencies to pom file, we faced this problem. 
Moreover, it is not jvmClasspath, it's the enumeration of all jat files.

[1] 
[https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148]
 [2] 
[https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning]
 [3] 
[https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4381131&_focus=53179]


was (Author: ivanan.fed):
[~Pavlukhin] ,

According to Parametrized test - I added a new dependency in the last commit. 
We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is 
simplier than in the fourth version. Rule and ClassRule annotations can be 
replaced by Extension and ExtendWith respectively.

According to .net tests: the reason for failures is the only one: "The filename 
or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath 
because other args are hardcoded. I compared the log files from my branch[2] 
and master[3]. For some reason, jvmClasspath
contains all maven dependencies. Because of addition more dependencies to pom 
file, this string becomes too long for system .net function. I guess that it is 
not correct behavior of Classpath.cs#CreateClasspath function, because if we 
need to add some more dependencies to pom file, we faced this problem. 
Moreover, it is not jvmClasspath, it's the enumeration of all jat files.

 

[1] 
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148
[2] 
https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning
[3] 
https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4381131&_focus=53179

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891243#comment-16891243
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin] ,

According to Parametrized test - I added a new dependency in the last commit. 
We can use @CsvSource or @ParameterizedTest/@ValueSource annotations: usage is 
simplier than in the fourth version. Rule and ClassRule annotations can be 
replaced by Extension and ExtendWith respectively.

According to .net tests: the reason for failures is the only one: "The filename 
or extension is too long" in ExecutableTest [1]. I guess that it's jvmClasspath 
because other args are hardcoded. I compared the log files from my branch[2] 
and master[3]. For some reason, jvmClasspath
contains all maven dependencies. Because of addition more dependencies to pom 
file, this string becomes too long for system .net function. I guess that it is 
not correct behavior of Classpath.cs#CreateClasspath function, because if we 
need to add some more dependencies to pom file, we faced this problem. 
Moreover, it is not jvmClasspath, it's the enumeration of all jat files.

 

[1] 
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148
[2] 
https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning
[3] 
https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=4381131&_focus=53179

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-09 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881322#comment-16881322
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin],

I checked all blockers on TC bot. Apart from .Net block, the reason for all 
other blockers is "History for base branch is absent".

Moreover, I made an experiment with @UseTechnicalNames annotation (look on the 
last two commits [1]) - it does not help, the name for TC still does not 
correspond to the previous name.

So, from TC bot clear that all test from TC marked as blockers because of 
different name in parentheses and this is the only problem with naming.

[1] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.

2019-07-09 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881244#comment-16881244
 ] 

Ivan Fedotov commented on IGNITE-711:
-

[~Pavlukhin], thank you.
I resolved them in the last commit.

> [Java 8 Examples] Need to complete implementation of Java 8 examples.
> -
>
> Key: IGNITE-711
> URL: https://issues.apache.org/jira/browse/IGNITE-711
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are next examples for java 7, but there are no for java 8. Need to 
> implement if they are applicable for java 8.
> // BasicExamplesSelfTest
> - ComputeReducerExample
> - ComputeTaskMapExample
> - ComputeTaskSplitExample
> // CacheExamplesSelfTest:
> - IgniteAtomicLongExample.main
> - IgniteAtomicReferenceExample.main
> - IgniteAtomicSequenceExample.main
> - IgniteAtomicStampedExample.main
> - IgniteCountDownLatchExample.main
> - IgniteQueueExample.main
> - IgniteSetExample.main
> - CacheDummyStoreExample.main
> - CacheQueryExample.main
> - CacheTransactionExample.main
> - CacheDataStreamerExample.main
> - CachePutGetExample.main
> - CacheStarSchemaExample.main
> - CacheContinuousQueryExample.main
> // CheckpointExamplesSelfTest
> - ComputeFailoverExample 
> // ClusterGroupExampleSelfTest
> - ClusterGroupExample
> // ContinuationExamplesSelfTest
>  - ComputeFibonacciContinuationExample
> // ContinuousMapperExamplesSelfTest
> - ComputeContinuousMapperExample
> - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample
> - DeploymentExamplesSelfTest # testDeploymentExample
> // HibernateL2CacheExampleSelfTest
> - HibernateL2CacheExample
> - IgfsExamplesSelfTest # testIgniteFsApiExample
> // LifecycleExamplesSelfTest
> - LifecycleExample
> - look at MemcacheRestExamplesMultiNodeSelfTest
> - MemcacheRestExample
> - CreditRiskExample
> - SpringBeanExample
> - ComputeTaskSplitExample
> - ComputeTaskMapExample
> Examples should be implemented for java 8 or testing methods should be 
> removed if examples do not applicable for java 8.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean

2019-07-09 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov reassigned IGNITE-11923:
-

Assignee: Ivan Fedotov

> [IEP-35] Migrate IgniteMXBean
> -
>
> Key: IGNITE-11923
> URL: https://issues.apache.org/jira/browse/IGNITE-11923
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: IEP-35
>
> After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new 
> metric framework.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.

2019-07-08 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880455#comment-16880455
 ] 

Ivan Fedotov commented on IGNITE-711:
-

[~Pavlukhin], this ticket is ready for review and merge.
Could you please take a look at it?

> [Java 8 Examples] Need to complete implementation of Java 8 examples.
> -
>
> Key: IGNITE-711
> URL: https://issues.apache.org/jira/browse/IGNITE-711
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are next examples for java 7, but there are no for java 8. Need to 
> implement if they are applicable for java 8.
> // BasicExamplesSelfTest
> - ComputeReducerExample
> - ComputeTaskMapExample
> - ComputeTaskSplitExample
> // CacheExamplesSelfTest:
> - IgniteAtomicLongExample.main
> - IgniteAtomicReferenceExample.main
> - IgniteAtomicSequenceExample.main
> - IgniteAtomicStampedExample.main
> - IgniteCountDownLatchExample.main
> - IgniteQueueExample.main
> - IgniteSetExample.main
> - CacheDummyStoreExample.main
> - CacheQueryExample.main
> - CacheTransactionExample.main
> - CacheDataStreamerExample.main
> - CachePutGetExample.main
> - CacheStarSchemaExample.main
> - CacheContinuousQueryExample.main
> // CheckpointExamplesSelfTest
> - ComputeFailoverExample 
> // ClusterGroupExampleSelfTest
> - ClusterGroupExample
> // ContinuationExamplesSelfTest
>  - ComputeFibonacciContinuationExample
> // ContinuousMapperExamplesSelfTest
> - ComputeContinuousMapperExample
> - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample
> - DeploymentExamplesSelfTest # testDeploymentExample
> // HibernateL2CacheExampleSelfTest
> - HibernateL2CacheExample
> - IgfsExamplesSelfTest # testIgniteFsApiExample
> // LifecycleExamplesSelfTest
> - LifecycleExample
> - look at MemcacheRestExamplesMultiNodeSelfTest
> - MemcacheRestExample
> - CreditRiskExample
> - SpringBeanExample
> - ComputeTaskSplitExample
> - ComputeTaskMapExample
> Examples should be implemented for java 8 or testing methods should be 
> removed if examples do not applicable for java 8.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-711) [Java 8 Examples] Need to complete implementation of Java 8 examples.

2019-07-05 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879302#comment-16879302
 ] 

Ivan Fedotov commented on IGNITE-711:
-

[~ashutak], If you don't mind I will do this ticket - uncomment al mentioned 
tests.
For more information please take a look at the conversation [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Migration-to-JUnit-5-td40907.html


> [Java 8 Examples] Need to complete implementation of Java 8 examples.
> -
>
> Key: IGNITE-711
> URL: https://issues.apache.org/jira/browse/IGNITE-711
> Project: Ignite
>  Issue Type: Task
>Reporter: Artem Shutak
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> There are next examples for java 7, but there are no for java 8. Need to 
> implement if they are applicable for java 8.
> // BasicExamplesSelfTest
> - ComputeReducerExample
> - ComputeTaskMapExample
> - ComputeTaskSplitExample
> // CacheExamplesSelfTest:
> - IgniteAtomicLongExample.main
> - IgniteAtomicReferenceExample.main
> - IgniteAtomicSequenceExample.main
> - IgniteAtomicStampedExample.main
> - IgniteCountDownLatchExample.main
> - IgniteQueueExample.main
> - IgniteSetExample.main
> - CacheDummyStoreExample.main
> - CacheQueryExample.main
> - CacheTransactionExample.main
> - CacheDataStreamerExample.main
> - CachePutGetExample.main
> - CacheStarSchemaExample.main
> - CacheContinuousQueryExample.main
> // CheckpointExamplesSelfTest
> - ComputeFailoverExample 
> // ClusterGroupExampleSelfTest
> - ClusterGroupExample
> // ContinuationExamplesSelfTest
>  - ComputeFibonacciContinuationExample
> // ContinuousMapperExamplesSelfTest
> - ComputeContinuousMapperExample
> - DeploymentExamplesMultiNodeSelfTest # testDeploymentExample
> - DeploymentExamplesSelfTest # testDeploymentExample
> // HibernateL2CacheExampleSelfTest
> - HibernateL2CacheExample
> - IgfsExamplesSelfTest # testIgniteFsApiExample
> // LifecycleExamplesSelfTest
> - LifecycleExample
> - look at MemcacheRestExamplesMultiNodeSelfTest
> - MemcacheRestExample
> - CreditRiskExample
> - SpringBeanExample
> - ComputeTaskSplitExample
> - ComputeTaskMapExample
> Examples should be implemented for java 8 or testing methods should be 
> removed if examples do not applicable for java 8.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-01 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876385#comment-16876385
 ] 

Ivan Fedotov edited comment on IGNITE-10973 at 7/1/19 5:49 PM:
---

[~Pavlukhin] , part of the name in parentheses means path. In the case, where 
names are different in the version before path consists from "path to suite: 
path to test" and in the version after just "path to test".

I tried to find the place in the code where it is constructed. It seems that TC 
took this path from JUnit and it does not configure inside Ignite. But maybe I 
am wrong and we can configure it from TC.

[~ein] could you please clarify is it possible to configure test name in 
parentheses in TC?


was (Author: ivanan.fed):
[~Pavlukhin] , part of the name in parentheses means path. In the case, where 
names are different in the version before path consists from "path to suite: 
path to test" and in the version after just "path to test".

 

I tried to find the place in the code where it is constructed. It seems that TC 
took this path from JUnit and it does not configure inside Ignite. But maybe I 
am wrong and we can configure it from TC.

 

 

[~ein] could you please clarify is it possible to configure test name in 
parentheses in TC?

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-07-01 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876385#comment-16876385
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin] , part of the name in parentheses means path. In the case, where 
names are different in the version before path consists from "path to suite: 
path to test" and in the version after just "path to test".

 

I tried to find the place in the code where it is constructed. It seems that TC 
took this path from JUnit and it does not configure inside Ignite. But maybe I 
am wrong and we can configure it from TC.

 

 

[~ein] could you please clarify is it possible to configure test name in 
parentheses in TC?

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest

2019-07-01 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16876325#comment-16876325
 ] 

Ivan Fedotov commented on IGNITE-11849:
---

[~Pavlukhin], I rerun _IgniteCacheReadThroughEvictionSelfTest_ locally multiple 
times from IDEA and it passes. Through suite, 
_IgniteCacheReadThroughEvictionsVariationsSuite_ situation is the same.
 Could you please try it on branch IGNITE-11849 one more time?

> Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
> 
>
> Key: IGNITE-11849
> URL: https://issues.apache.org/jira/browse/IGNITE-11849
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> According to the test scenario after expiration entry must be present in 
> IgniteCache - it will be loaded from CacheStore.
> It is necessary to specify CacheStore in node config [1].
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-06-21 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869496#comment-16869496
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin], I tried to re-run multiple times, but the situation remains the 
same.
Bot says that history is absent for the base branch.
Can it be the case that bot is configured for the specific JUnit version (and 
it appears at least on some tests)?

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-11922) [IEP-35] Migrate ClusterMetricsMxBean

2019-06-20 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov reassigned IGNITE-11922:
-

Assignee: Ivan Fedotov

> [IEP-35] Migrate ClusterMetricsMxBean
> -
>
> Key: IGNITE-11922
> URL: https://issues.apache.org/jira/browse/IGNITE-11922
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: IEP-35
>
> After merging of IGNITE-11848 we should migrate `ClusterMetricsMxBean` to the 
> new metric framework.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest

2019-06-18 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866591#comment-16866591
 ] 

Ivan Fedotov commented on IGNITE-11849:
---

[~Pavlukhin] could you take a look on this patch please?

> Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
> 
>
> Key: IGNITE-11849
> URL: https://issues.apache.org/jira/browse/IGNITE-11849
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> According to the test scenario after expiration entry must be present in 
> IgniteCache - it will be loaded from CacheStore.
> It is necessary to specify CacheStore in node config [1].
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5

2019-06-14 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863955#comment-16863955
 ] 

Ivan Fedotov commented on IGNITE-10973:
---

[~Pavlukhin], Hi!

In general I managed with migration examples module to JUnit 5. What I did:
 * added JUnit5 dependencies to parent/pom.xml. JUnit4 still works without any 
changes: junit-vintage allows us to use the previous version.
 * added junit47 provider to use the JUnit version in the project >= 4.7
 * changed suite runner: from Suite.class to JUnitPlatform.class
 * in examples module changed annotations and uncommented ignored tests

However, TC bot shows as blocker those tests which for some reasons do not have 
history on master branch [1]. I checked logs and tests have failures because of 
functionality. Moreover, they fail on master branch locally for the same 
reasons. But TC history for them is empty and they are not marked as ignored in 
code.

Can be reason in TC/TC bot infrastucture, what do you think?

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest]

> Migrate example module tests from Junit 4 to 5
> --
>
> Key: IGNITE-10973
> URL: https://issues.apache.org/jira/browse/IGNITE-10973
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For more information refer parent task.
> Migrate from Junit 4 to 5 in the example module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest

2019-06-07 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16858527#comment-16858527
 ] 

Ivan Fedotov commented on IGNITE-11849:
---

[~ivan.glukos], Hi!

Could you please take a look on this patch?
We discussed it in the thread which is about IgniteConfig tests [1], you 
suggested a patch in the context of IGNITE-11708

I checked TC bot blockers and it seems that all of them relates to master 
branch.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/IgniteConfigVariationsAbstractTest-subclasses-do-not-run-td41783.html
[2] https://issues.apache.org/jira/browse/IGNITE-11708

> Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
> 
>
> Key: IGNITE-11849
> URL: https://issues.apache.org/jira/browse/IGNITE-11849
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> According to the test scenario after expiration entry must be present in 
> IgniteCache - it will be loaded from CacheStore.
> It is necessary to specify CacheStore in node config [1].
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch

2019-06-07 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11851:
--
Labels:   (was: iep-30)

> Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite 
> tests batch
> ---
>
> Key: IGNITE-11851
> URL: https://issues.apache.org/jira/browse/IGNITE-11851
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>
> IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. 
> The first batch (12 tests) runs without problems, but on next batches we got 
> an exception - default cache does not exist and we can not invoke unrwap() 
> method on it [1].
> It seems that cache is destroyed after the first batch and is not created on 
> the next one.
> [1] 
> [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-06-07 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11708:
--
Labels: iep-30  (was: iep30)

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch

2019-06-05 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov resolved IGNITE-11851.
---
Resolution: Not A Bug

> Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite 
> tests batch
> ---
>
> Key: IGNITE-11851
> URL: https://issues.apache.org/jira/browse/IGNITE-11851
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. 
> The first batch (12 tests) runs without problems, but on next batches we got 
> an exception - default cache does not exist and we can not invoke unrwap() 
> method on it [1].
> It seems that cache is destroyed after the first batch and is not created on 
> the next one.
> [1] 
> [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-06-05 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856549#comment-16856549
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], 
Sure, code style fixed.
Visa has attached above.


> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-06-04 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855917#comment-16855917
 ] 

Ivan Fedotov edited comment on IGNITE-11708 at 6/4/19 5:42 PM:
---

[~Pavlukhin], 
I fixed some moments after TC results:
* added ConfigVariationsExecutionTest to testSuite [1]
* ignored cache test in MVCC [2]
* make dummyCfg non-static: since testCfg already is not static, now static 
dummyCfg is not necessary [3].

TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them 
have a lot of recent failures (76 and 37 % respectively) [4].

[1] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234
[2] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91
[3] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376
[4] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest


was (Author: ivanan.fed):
[~Pavlukhin], 
I fixed some moments after TC results:
* added ConfigVariationsExecutionTest to testSuite [1]
* ignored cache test in MVCC [2]
* make dummyCfg non-static: science testCfg already is not static, now static 
dummyCfg is not necessary [3].

TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them 
have a lot of recent failures (76 and 37 % respectively) [4].

[1] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234
[2] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91
[3] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376
[4] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-06-04 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855917#comment-16855917
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], 
I fixed some moments after TC results:
* added ConfigVariationsExecutionTest to testSuite [1]
* ignored cache test in MVCC [2]
* make dummyCfg non-static: science testCfg already is not static, now static 
dummyCfg is not necessary [3].

TC Bot gives me 2 blockers: code style and .Net Inspections, but both of them 
have a lot of recent failures (76 and 37 % respectively) [4].

[1] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-e36adf615dfcc36775e2edd132042b4aR234
[2] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-1cf9dd56dece1e687eada1c9cbc3388eR91
[3] 
https://github.com/apache/ignite/pull/6434/commits/62ac5a64b8489ea5d16cd27487f284ee248aa2f3#diff-cd3a07ce10f21d396c1eac0c328850e0L376
[4] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6434/head=Latest

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11886) Unable to check query result in IgniteCacheConfigVariationsQueryTest

2019-05-31 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11886:
-

 Summary: Unable to check query result in 
IgniteCacheConfigVariationsQueryTest
 Key: IGNITE-11886
 URL: https://issues.apache.org/jira/browse/IGNITE-11886
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov


After turn on IgniteConfigVariationsAbstractTest 
IgniteCacheConfigVariationsQueryTest #testLocalScanQuery and 
testScanQueryLocalFilter became failed [1]. Not all predicates were executed 
during query - failed to check execEvtLatch.

[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=3978709=IgniteTests24Java8_QueriesConfigVariations




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11885) Tests from IgniteCacheConfigVariationsFullApiTest failed on TC

2019-05-31 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11885:
-

 Summary: Tests from IgniteCacheConfigVariationsFullApiTest failed 
on TC
 Key: IGNITE-11885
 URL: https://issues.apache.org/jira/browse/IGNITE-11885
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov


After turn on IgniteConfigVariationsAbstractTest multiple tests in 
IgniteCacheConfigVariationsFullApiTest became failed [1]. The reason is that 
the expected value was not found in the cache, but deeper reason for each test 
can be different - this issue must be investigated.

[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=3978681=IgniteTests24Java8_CacheFullApiBasicConfigVariations



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11884) Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest

2019-05-31 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11884:
-

 Summary: Time outed invokeAll tests in 
WithKeepBinaryCacheFullApiTest
 Key: IGNITE-11884
 URL: https://issues.apache.org/jira/browse/IGNITE-11884
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov


After turn on IgniteConfigVariationsAbstractTest 2 tests in 
WithKeepBinaryCacheFullApiTest became failed: testInvokeAll and 
testInvokeAllAsync. Tests failed because of time out [1].

[1] 
https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_CacheFullApiConfigVariations=3978682




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy

2019-05-31 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11883:
-

 Summary: Unable to find keys in testKeyAffinityDeploy
 Key: IGNITE-11883
 URL: https://issues.apache.org/jira/browse/IGNITE-11883
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov


After turn on IgniteConfigVariationsAbstractTest 
IgniteServiceConfigVariationsFullApiTest#testKeyAffinityDeploy became failed - 
"Unable to find 1 required keys" [1].
It is necessary to investigate the reason and fix the test.

[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=3978784=buildResultsDiv=IgniteTests24Java8_ServiceGridLegacyMode#testNameId5798659135386117314




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-29 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850983#comment-16850983
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], Injection through constructor looks better, it is obviously. 
Situation on TC remains the same.

Please check the last commit [1].

Now I will ignore failed tests and rise discussion on dev-list about them.

Do you have any other suggestions according to this PR?

[1] 
[https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R429]

 

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-28 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850028#comment-16850028
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], I removed the garbage injection and left only one non-static cfg 
variable.
Moreover, I assigned configuration directly before each test (and 
beforeTestsStarted method) with reflection instead of injectTestsConfiguration 
method invocation [1].
I think now it looks better and without unnecessary actions.
Also, I removed double stopAllGrids (I don't know why it's necessary to invoke 
it twice - because of this Cache tests were broken) [2].
I checked RunAllNightly and new failures seem for me from the first view not 
because of test workflow, but because of real reasons.
Could you take a look at such solution, please?

[1]https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R434
[2] 
https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L179

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-28 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850028#comment-16850028
 ] 

Ivan Fedotov edited comment on IGNITE-11708 at 5/28/19 6:44 PM:


[~Pavlukhin], I removed the garbage injection and left only one non-static cfg 
variable.
Moreover, I assigned configuration directly before each test (and 
beforeTestsStarted method) with reflection instead of injectTestsConfiguration 
method invocation [1].
I think now it looks better and without unnecessary actions.

Also, I removed double stopAllGrids (I don't know why it's necessary to invoke 
it twice - because of this Cache tests were broken) [2].

I checked RunAllNightly and new failures seem for me from the first view not 
because of test workflow, but because of real reasons.
Could you take a look at such solution, please?

[1]https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R434
[2] 
https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L179


was (Author: ivanan.fed):
[~Pavlukhin], I removed the garbage injection and left only one non-static cfg 
variable.
Moreover, I assigned configuration directly before each test (and 
beforeTestsStarted method) with reflection instead of injectTestsConfiguration 
method invocation [1].
I think now it looks better and without unnecessary actions.
Also, I removed double stopAllGrids (I don't know why it's necessary to invoke 
it twice - because of this Cache tests were broken) [2].
I checked RunAllNightly and new failures seem for me from the first view not 
because of test workflow, but because of real reasons.
Could you take a look at such solution, please?

[1]https://github.com/apache/ignite/pull/6434/files#diff-3da5dbb6f22e5bf3bf18734933f1bfc5R434
[2] 
https://github.com/apache/ignite/pull/6434/files#diff-cd3a07ce10f21d396c1eac0c328850e0L179

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-22 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845953#comment-16845953
 ] 

Ivan Fedotov edited comment on IGNITE-11708 at 5/22/19 3:01 PM:


[~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The 
problem is in NPE in 

IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default 
VariationsTestsConfig all works fine, it is clear from the previous TC results. 
But when we use injected config, default ignite instance does not create - 
ignite() method returns null [3].

I think that the problem is in makeTestClass method when configs are injected 
[4]. For some reason, configs are not correct or are not correct injected. But 
this reason is unclear for me now.

[1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly]

[2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204]

[3] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469]

[4] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434]


was (Author: ivanan.fed):
[~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The 
problem is in NPE in 

IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default 
VariationsTestsConfig all works fine, it is clear from the previous TC results. 
But when we use injected config, default ignite instance does not create - 
ignite() method returns null [3].

I think that the problem is in makeTestClass method when configs are injected. 
For some reason, configs are not correct or are not correct injected. But this 
reason is unclear for me now.

[1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly]

[2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204]

[3] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469]

[4] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434]

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-22 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845953#comment-16845953
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The 
problem is in NPE in 

IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default 
VariationsTestsConfig all works fine, it is clear from the previous TC results. 
But when we use injected config, default ignite instance does not create - 
ignite() method returns null [3].

I think that the problem is in makeTestClass method when configs are injected. 
For some reason, configs are not correct or are not correct injected. But this 
reason is unclear for me now.

[1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly]

[2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204]

[3] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469]

[4] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434]

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-05-20 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16843757#comment-16843757
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin] , I think that PR is ready for review/merge.

Could you please take a look on it?

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
> Attachments: read_through_eviction_self_test.patch, 
> tx_out_test_fixed.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch

2019-05-14 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11851:
-

 Summary: Cache does not exist after first 
IgniteContinuousQueryConfigVariationsSuite tests batch
 Key: IGNITE-11851
 URL: https://issues.apache.org/jira/browse/IGNITE-11851
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. The 
first batch (12 tests) runs without problems, but on next batches we got an 
exception - default cache does not exist and we can not invoke unrwap() method 
on it [1].

It seems that cache is destroyed after the first batch and is not created on 
the next one.

[1] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212]

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest

2019-05-14 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11849:
--
Description: 
According to the test scenario after expiration entry must be present in 
IgniteCache - it will be loaded from CacheStore.

It is necessary to specify CacheStore in node config [1].

[1] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233

  was:
According to the test scenario after expiration entry must be present in 
IgniteCache - it will be loaded from CacheStore.

It is necessary to specify CacheStore in node config.


> Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
> 
>
> Key: IGNITE-11849
> URL: https://issues.apache.org/jira/browse/IGNITE-11849
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>
> According to the test scenario after expiration entry must be present in 
> IgniteCache - it will be loaded from CacheStore.
> It is necessary to specify CacheStore in node config [1].
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/IgniteCacheReadThroughEvictionSelfTest.java#L233



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11850) Missing check atomicity mode on null

2019-05-14 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11850:
--
Description: 
In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. 

getAtomicityMode() method can return null, but test scenario does not take it 
into consideration [1].

Default cache atomicity mode must be used in case if getAtomicityMode() returns 
null.

[1] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L380

  was:
In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. 

getAtomicityMode() method can return null, but test scenario does not take it 
into consideration.

Default cache atomicity mode must be used in case if getAtomicityMode() returns 
null.


> Missing check atomicity mode on null
> 
>
> Key: IGNITE-11850
> URL: https://issues.apache.org/jira/browse/IGNITE-11850
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>
> In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. 
> getAtomicityMode() method can return null, but test scenario does not take it 
> into consideration [1].
> Default cache atomicity mode must be used in case if getAtomicityMode() 
> returns null.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L380



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11850) Missing check atomicity mode on null

2019-05-14 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11850:
-

 Summary: Missing check atomicity mode on null
 Key: IGNITE-11850
 URL: https://issues.apache.org/jira/browse/IGNITE-11850
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. 

getAtomicityMode() method can return null, but test scenario does not take it 
into consideration.

Default cache atomicity mode must be used in case if getAtomicityMode() returns 
null.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest

2019-05-14 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11849:
-

 Summary: Specify CacheStore in 
IgniteCacheReadThroughEvictionSelfTest
 Key: IGNITE-11849
 URL: https://issues.apache.org/jira/browse/IGNITE-11849
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


According to the test scenario after expiration entry must be present in 
IgniteCache - it will be loaded from CacheStore.

It is necessary to specify CacheStore in node config.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11802) Check keepSerializedObjects() condition after each test

2019-04-28 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16828846#comment-16828846
 ] 

Ivan Fedotov commented on IGNITE-11802:
---

[~Pavlukhin] , Hi!

I think this ticket is ready for review and merge. 

According to TC bot [1] it is only one blocker, .Net test, but it has 87.7% of 
recent fails, so I think this ticket does not affect .Net part.

 

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6498/head=Latest]

 

> Check keepSerializedObjects() condition after each test
> ---
>
> Key: IGNITE-11802
> URL: https://issues.apache.org/jira/browse/IGNITE-11802
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After some changes in GridAbstractTest class [1] condition on 
> {{serializedObj.clear()}} invocation was removed [2]. 
>  In the previous master version {{serializedObj.clear()}} will be invoked 
> only if {{!keepSerializedObjects()}} condition will be satisfied.
> Due to this reason, some tests became failed [3], so it is necessary to 
> return such check.
> [1] https://issues.apache.org/jira/browse/IGNITE-11412
>  [2] 
> [https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152]
>  [3] 
> [http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11802) Check keepSerializedObjects() condition after each test

2019-04-24 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11802:
--
Description: 
After some changes in GridAbstractTest class [1] condition on 
{{serializedObj.clear()}} invocation was removed [2]. 
 In the previous master version {{serializedObj.clear()}} will be invoked only 
if {{!keepSerializedObjects()}} condition will be satisfied.

Due to this reason, some tests became failed [3], so it is necessary to return 
such check.

[1] https://issues.apache.org/jira/browse/IGNITE-11412
 [2] 
[https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152]
 [3] 
[http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html]

  was:
After some changes in GridAbstractTest class [1] condition on 
{{serializedObj.clear()}} invocation was removed [2]. 
In the previous master version {{serializedObj.clear()}} will be invoked only 
if {{(!keepSerializedObjects())}} condition will be satisfied.

Due to this reason, some tests became failed [3], so it is necessary to return 
such check.

[1] https://issues.apache.org/jira/browse/IGNITE-11412
[2] 
https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152
[3] 
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html



> Check keepSerializedObjects() condition after each test
> ---
>
> Key: IGNITE-11802
> URL: https://issues.apache.org/jira/browse/IGNITE-11802
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After some changes in GridAbstractTest class [1] condition on 
> {{serializedObj.clear()}} invocation was removed [2]. 
>  In the previous master version {{serializedObj.clear()}} will be invoked 
> only if {{!keepSerializedObjects()}} condition will be satisfied.
> Due to this reason, some tests became failed [3], so it is necessary to 
> return such check.
> [1] https://issues.apache.org/jira/browse/IGNITE-11412
>  [2] 
> [https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152]
>  [3] 
> [http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11802) Check keepSerializedObjects() condition after each test

2019-04-24 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11802:
-

 Summary: Check keepSerializedObjects() condition after each test
 Key: IGNITE-11802
 URL: https://issues.apache.org/jira/browse/IGNITE-11802
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


After some changes in GridAbstractTest class [1] condition on 
{{serializedObj.clear()}} invocation was removed [2]. 
In the previous master version {{serializedObj.clear()}} will be invoked only 
if {{(!keepSerializedObjects())}} condition will be satisfied.

Due to this reason, some tests became failed [3], so it is necessary to return 
such check.

[1] https://issues.apache.org/jira/browse/IGNITE-11412
[2] 
https://github.com/apache/ignite/pull/6267/files#diff7a554fa780cd51aae79479d6e9dfcc96L2152
[3] 
http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-3681058-3680965-needs-to-be-handled-td41859.html




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824054#comment-16824054
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], sorry, did not noticed the latest master changes.

Conflicts are resolved.

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823947#comment-16823947
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], Thank you for the review.

Could you please merge it?

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-22 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16823136#comment-16823136
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], 

I think that now this ticket is completely ready.

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11412:
--
Description: Refactor JUnit3TestLegacySupport class and remove, if it is 
possible.  (was: Specify JUnit3TestLegacySupport class documentation.)

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Refactor JUnit3TestLegacySupport class and remove, if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-04-16 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
 ] 

Ivan Fedotov edited comment on IGNITE-11708 at 4/16/19 12:26 PM:
-

[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}} 
execution according to your suggestions. May be add similar check that 
before/after JUnit methods also work, what do you think?

According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I 
decided to simplify code and remove outer rule and ruleChain from 
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if 
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests 
work - you can try to start 
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods 
work indeed (it takes time unlike the master branch).

But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and 
it seems that failures are related to what tests check, but not JUnit error. I 
mean that in master tests are green just because nothing happens, but indeed 
tests can fail. I can not figure out in each test quickly, but in nutshell, 
according to logs the failures are caused errors in tests functionality. 
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.

[1] [https://github.com/apache/ignite/pull/6434/files]
 [2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
 [3] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]


was (Author: ivanan.fed):
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}} 
execution according to your suggestions. May be add similar check that 
before/after JUnit methods also work, what do you think?

According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I 
decided to simplify code and remove outer rule and ruleChain from 
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if 
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests 
work - you can try to start 
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods 
work indeed (it takes time unlike the master branch).

But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and 
it seems that failures are related to what tests check, but not JUnit error. I 
mean that in master tests are green just because nothing happens, but indeed 
tests can fail. I can not figure out in each tests quickly, but in nutshell, 
according to logs the failures are caused errors in tests functionality. 
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.

[1] [https://github.com/apache/ignite/pull/6434/files]
 [2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
 [3] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-04-16 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
 ] 

Ivan Fedotov edited comment on IGNITE-11708 at 4/16/19 8:23 AM:


[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}} 
execution according to your suggestions. May be add similar check that 
before/after JUnit methods also work, what do you think?

According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I 
decided to simplify code and remove outer rule and ruleChain from 
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if 
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests 
work - you can try to start 
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods 
work indeed (it takes time unlike the master branch).

But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and 
it seems that failures are related to what tests check, but not JUnit error. I 
mean that in master tests are green just because nothing happens, but indeed 
tests can fail. I can not figure out in each tests quickly, but in nutshell, 
according to logs the failures are caused errors in tests functionality. 
Moreover, 450 failures on 15_000 tests are just 3%, so it could be true.

[1] [https://github.com/apache/ignite/pull/6434/files]
 [2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java]
 [3] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest]


was (Author: ivanan.fed):
[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}} 
execution according to your suggestions. May be add similar check that 
before/after JUnit methods also work, what do you think?

According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I 
decided to simplify code and remove outer rule and ruleChain from 
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if 
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests 
work - you can try to start 
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods 
work indeed (it takes time unlike the master branch). 

But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and 
it seems that failures are related to what tests check, but not JUnit error. I 
mean that in master tests are green just because nothing happens, but indeed 
tests can fail. I can not figure out in each tests quickly, but in nutshell, 
according to logs the failures are caused errors in tests functionality. 
Moreover, 300 failures on 15_000 tests are just 2%, so it could be true.


[1] https://github.com/apache/ignite/pull/6434
[2] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java
[3] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest



> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-04-16 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818759#comment-16818759
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], I added test for check {{IgniteConfigVariationsAbstractTest}} 
execution according to your suggestions. May be add similar check that 
before/after JUnit methods also work, what do you think?

According to fix {{IgniteConfigVariationsAbstractTest}} rules workflow. I 
decided to simplify code and remove outer rule and ruleChain from 
{{IgniteConfigVariationsAbstractTest}} [1]. We can implement the same idea if 
we just put {{testCfg}} initilization in {{beforeTestsStarted}}. Now all tests 
work - you can try to start 
{{InterceptorCacheConfigVariationsFullApiTestSuite}} [2] and see that methods 
work indeed (it takes time unlike the master branch). 

But now TeamCity bot shows us a lot of failures [3]. I tried to figure out and 
it seems that failures are related to what tests check, but not JUnit error. I 
mean that in master tests are green just because nothing happens, but indeed 
tests can fail. I can not figure out in each tests quickly, but in nutshell, 
according to logs the failures are caused errors in tests functionality. 
Moreover, 300 failures on 15_000 tests are just 2%, so it could be true.


[1] https://github.com/apache/ignite/pull/6434
[2] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java
[3] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest



> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-04-11 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815498#comment-16815498
 ] 

Ivan Fedotov commented on IGNITE-11708:
---

[~Pavlukhin], thank you for the items, I agree with all of them (I am not sure 
how to implement the third point, may be insert a counter, increment it in test 
bodies and check counter's value after all tests, in nutshell).

I think that the problem is not that {{base.evaluate}}  in {{rulePrivate}} does 
not call inside (I tried to debug it with system.out and it works). Meanwhile, 
the following rule
{noformat}
@Rule public transient TestRule runRule = (base, desc) -> new Statement() {
@Override public void evaluate() throws Throwable {
assert getName() != null : "getName returned null";

runTest(base);
}
};
{noformat}
from GridAbstractTest indeed does not call {{base.evaluate}} by some reason.
  

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-10 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814541#comment-16814541
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], it really looks like {{GridAbstractTest#runRule}} must be 
replaced by {{nameAndRunRulesChain}} in {{IgniteConfigVariationsAbstractTest}}, 
according to the master branch, but it does not fix {{LegacyLifecycleTest}}. I 
did replacement in the last commit and marked failed test as {{@Ignore}}. Now 
the order is the following:
{noformat}
GridAbstractTest nameRule
GridAbstractTest runRule
IgniteConfigVariationsAbstractTest rulePrivate
{noformat}
I tried to check an order of rules execution in master and got interesting 
results:
{noformat}
GridAbstractTest nameRule
IgniteConfigVariationsAbstractTest rulePrivate
{noformat}
It is clear from output that test does not run. This problem must be resolved 
in a separate ticket since it relates to the master branch, do you think so?

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses

2019-04-10 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11708:
--
Summary: Unable to run tests in IgniteConfigVariationsAbstractTest 
subclasses  (was: Unable to run tests with IgniteConfigVariationsAbstractTest 
extension)

> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
> 
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-10 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814207#comment-16814207
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], I am not sure that null assertion for {{getName()}} is necessary 
here - such assert already exists in {{GridAbstractTest}} [1]. Moreover, 
{{testsCfg}} and {{testsCfgInjected}} also already initialized [2] as 
{{dummyCfg()}}.

I think other {{variation}} tests are green because there are no assertions 
that check test work in {{before/after}} test conditions like in 
{{LegacyLifecycleTest}}. So such tests are successfully like empty code. I 
inserted throwing exception in methods under {{@Test}} annotation in 
{{IgniteConfigVariationsAbstractTest}} subclasses and nothing happened.

According to the current ticket, I will mark failed tests as {{Ingnore}}, 
right? Do you have any other suggestions to this patch?

[1] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L183]
 [2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L78]

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11708) Unable to run tests with IgniteConfigVariationsAbstractTest extension

2019-04-09 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11708:
--
Summary: Unable to run tests with IgniteConfigVariationsAbstractTest 
extension  (was: Unable to run tests under IgniteConfigVariationsAbstractTest 
class)

> Unable to run tests with IgniteConfigVariationsAbstractTest extension
> -
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>
> It seems that test classes that extend from 
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test 
> annotation. 
> It is easy to check: if throw exception in any test methods, nothing will 
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
> maybe it destroys existing test workflow.
> [1] 
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-09 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813455#comment-16813455
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~Pavlukhin], I made some refactor stuff - moved logic from 
{{TestJUnit3TestLegacySupport/TestConditionsAware}} to {{GridAbstractTest}} and 
renamed {{setUp/tearDown}} methods. The issue with {{nameRule}} I resolved with 
rule chain.

In general TC results look good [1], but I faced a problem with 
{{LegacyLifecycleTest}}. I found that tests from this inner class do not work, 
even from master branch. It is easy to see - you can insert output like this
{code:title=Log for bug 
detection|theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
private void processStage(String desc, int exp, int update) {
System.out.println("exp: " + exp + " update: " + update);

Assert.assertEquals(desc + " at test class id " + testClsId, exp, 
stageCnt.get());

stageCnt.set(update);
}
{code}

and it becomes clear that in master works only {{beforeTestsStarted / 
afterTestsStopped}} methods. Since {{beforeTestsStarted}} method makes 
replacement of {{AtomicInteger stageCnt}} on value that {{afterTestsStopped}} 
expects, the test on master is green.

I went deeper and it turned out that other test methods in classes that extend 
from {{IgniteConfigVariationsAbstractTest}} also do not work in master branch.

So, I created the appropriate ticket [2].

[1] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6267/head=Latest
[2] https://issues.apache.org/jira/browse/IGNITE-11708


> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11708) Unable to run tests under IgniteConfigVariationsAbstractTest class

2019-04-09 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11708:
-

 Summary: Unable to run tests under 
IgniteConfigVariationsAbstractTest class
 Key: IGNITE-11708
 URL: https://issues.apache.org/jira/browse/IGNITE-11708
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


It seems that test classes that extend from IgniteConfigVariationsAbstractTest 
cannot be started with JUnit4 @Test annotation. 
It is easy to check: if throw exception in any test methods, nothing will 
happen.
Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], 
maybe it destroys existing test workflow.

[1] 
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-04-03 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808862#comment-16808862
 ] 

Ivan Fedotov commented on IGNITE-11412:
---

[~EdShangGG], [~Pavlukhin] Could you please take a look on this patch?
Basically, it is about documentation, so this ticket is the last one in the 
context of JUnit 3->4 migration.
If you have any other suggestions about fixes, that should be done in this 
context, feel free to tell me about them.

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-03 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov resolved IGNITE-11413.
---
Resolution: Not A Problem

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-03 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov closed IGNITE-11413.
-

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (IGNITE-11414) Remove JUnit3LegacySupport

2019-04-03 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov closed IGNITE-11414.
-

> Remove JUnit3LegacySupport
> --
>
> Key: IGNITE-11414
> URL: https://issues.apache.org/jira/browse/IGNITE-11414
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest 
> class or remove if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-11414) Remove JUnit3LegacySupport

2019-04-03 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov resolved IGNITE-11414.
---
Resolution: Not A Problem

As it was mentioned in the ticket 
[IGNITE-11413|https://issues.apache.org/jira/browse/IGNITE-11413] 
beforeTest/afterTest and beforeTests/afterTests methods should be used under 
the Rule and ClassRule annotations respectively.
In this context mentioned methods will remain in Ignite test framework and 
removing of JUnit3LegacySupport class becomes not actual.

> Remove JUnit3LegacySupport
> --
>
> Key: IGNITE-11414
> URL: https://issues.apache.org/jira/browse/IGNITE-11414
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest 
> class or remove if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-02 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807876#comment-16807876
 ] 

Ivan Fedotov commented on IGNITE-11413:
---

[~Pavlukhin], Thus, I will close current issue as "Not a problem".
 In the context of JUnit 3->4 migration it remains only IGNITE-11412 which is 
about some documentation stuff.

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-02 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807834#comment-16807834
 ] 

Ivan Fedotov commented on IGNITE-11413:
---

[~Pavlukhin], yes, except of those fact that {{setUp}} and {{tearDown}} methods 
locate in {{runTest}}. 
 Do you think that making them out of {{runTest}}, directly in {{runRule}} will 
make code more understandable?

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-02 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807641#comment-16807641
 ] 

Ivan Fedotov commented on IGNITE-11413:
---

[~Pavlukhin], 

In principal {{beforeTest/afterTest}} methods now work from rule. It is clear 
from {{GridAbstractTest}} class: methods are used in {{setUp}}, {{tearDown}} 
respectively. And the last ones are used under rule in {{runTest}} method [1].

What kind of work do you mean?

[1][https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L2035]

 

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-04-01 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806888#comment-16806888
 ] 

Ivan Fedotov commented on IGNITE-11413:
---

[~Pavlukhin], let's move conversation thread from 
[IGNITE-11411|https://issues.apache.org/jira/browse/IGNITE-11411] here as more 
appropriate.

As I understood from our conversation on dev-list [1], we inject the main 
before/after test logic under Rule annotation. And it seems that before/after 
test class methods also could be remained under ClassRule annotation to make as 
less as possible changes in already existing tests.

What do you think about such strategy?

[1][http://apache-ignite-developers.2346864.n4.nabble.com/beforeTest-afterTest-JUnit-scenario-implementation-td41396.html]

 

> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
> annotations for such purposes. Methods must be moved in corresponded classes 
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under  
> @BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11637) Remove class loader initilization in GridSpiAbstractTest

2019-03-27 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11637:
-

 Summary: Remove class loader initilization in GridSpiAbstractTest
 Key: IGNITE-11637
 URL: https://issues.apache.org/jira/browse/IGNITE-11637
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


Investigate necessity of secondary class loader initilization in 
GridSpiAbstractTest. 

Initilization is secondary because the first is in GridAbstractTest. Now it 
seems that setting class loader in GridSpiAbstractTest should be removed.

 

[1] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/spi/GridSpiAbstractTest.java#L151]

[2] 
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L558]

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-03-26 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11412:
--
Description: Specify JUnit3TestLegacySupport class documentation.  (was: 
Specify beforeTest, afterTest methods documentation in JUnit3TestLegacySupport.)

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11412) Actualize JUnit3TestLegacySupport class

2019-03-26 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11412:
--
Summary: Actualize JUnit3TestLegacySupport class  (was: Actualize 
beforeTest, afterTest from JUnit3TestLegacySupport)

> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify beforeTest, afterTest methods documentation in 
> JUnit3TestLegacySupport.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-24 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072
 ] 

Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:53 PM:


[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2] https://issues.apache.org/jira/browse/IGNITE-11356 

[3] https://issues.apache.org/jira/browse/IGNITE-11413

 


was (Author: ivanan.fed):
[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356

[3] https://issues.apache.org/jira/browse/IGNITE-11413

 

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-24 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072
 ] 

Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:53 PM:


[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356

[3] https://issues.apache.org/jira/browse/IGNITE-11413

 


was (Author: ivanan.fed):
[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356


 [3] https://issues.apache.org/jira/browse/IGNITE-11413

 

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-24 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072
 ] 

Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:52 PM:


[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356


 [3] https://issues.apache.org/jira/browse/IGNITE-11413

 


was (Author: ivanan.fed):
[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356
[3] https://issues.apache.org/jira/browse/IGNITE-11413

 

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-24 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072
 ] 

Ivan Fedotov commented on IGNITE-11411:
---

[~Pavlukhin] , Thank you for your attention.

I fixed merge conflicts and re-run TC nightly[1]. According to this, there are 
no blockers related to this ticket.
I guess that now ticket is ready for the review again.

By the way, I noticed that your changes in the ticket [2] have an influence on 
beforeTestsStarted(), afterTestsStarted() methods. 
I guess that now when we decided to leave the support of such methods in the 
context of JUnit rules, my ticket about removing of them [3] becomes not 
actual. If you do not mind, I will comment it with a link on your ticket and 
close as "Not a problem".

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest]

[2]https://issues.apache.org/jira/browse/IGNITE-11356
[3] https://issues.apache.org/jira/browse/IGNITE-11413

 

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-23 Thread Ivan Fedotov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799607#comment-16799607
 ] 

Ivan Fedotov commented on IGNITE-11568:
---

The TC results for RunAll (Nightly) are ready [1]. There are no blockers.

[1] 
[https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6303/head=Latest]

 

> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed after test anyway (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest for more details).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11568:
--
Description: 
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
after test anyway (see JUnit3TestLegacySupport and beforeTest/afterTest usage 
in GridAbstractTest for more details).

 

So, it is necessary to change after annotation on override.

  was:
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more details).

 

So, it is necessary to change after annotation on override.


> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed after test anyway (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest for more details).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11568:
--
Description: 
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more details).

 

So, it is necessary to change after annotation on override.

  was:
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more detailes).

 

So, it is necessary to change after annotation on override.


> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed before test afterTest (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest for more details).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11568:
--
Description: 
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more detailes).

 

So, it is necessary to change after annotation on override.

  was:
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest).

 

So, it is necessary to change after annotation on override.


> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed before test  afterTest (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest for more detailes).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11568:
--
Description: 
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more detailes).

 

So, it is necessary to change after annotation on override.

  was:
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest for more detailes).

 

So, it is necessary to change after annotation on override.


> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed before test afterTest (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest for more detailes).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11568:
--
Description: 
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see JUnit3TestLegacySupport and beforeTest/afterTest 
usage in GridAbstractTest).

 

So, it is necessary to change after annotation on override.

  was:
afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see 

JUnit3TestLegacySupport and beforeTest/afterTest usage in GridAbstractTest).

 

So, it is necessary to change after annotation on override.


> Change afterTest() annotation in TcpDiscoveryFailedJoinTest
> ---
>
> Key: IGNITE-11568
> URL: https://issues.apache.org/jira/browse/IGNITE-11568
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>
> afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated 
> by after. Meanwhile, it is under prohibition because afterTest will be 
> executed before test  afterTest (see JUnit3TestLegacySupport and 
> beforeTest/afterTest usage in GridAbstractTest).
>  
> So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest

2019-03-19 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11568:
-

 Summary: Change afterTest() annotation in 
TcpDiscoveryFailedJoinTest
 Key: IGNITE-11568
 URL: https://issues.apache.org/jira/browse/IGNITE-11568
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated by 
after. Meanwhile, it is under prohibition because afterTest will be executed 
before test  afterTest (see 

JUnit3TestLegacySupport and beforeTest/afterTest usage in GridAbstractTest).

 

So, it is necessary to change after annotation on override.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11412) Actualize beforeTest, afterTest from JUnit3TestLegacySupport

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11412:
--
Description: Specify beforeTest, afterTest methods documentation in 
JUnit3TestLegacySupport.  (was: Replace beforeTest, afterTest methods in 
JUnit3TestLegacySupport by annotations @Before, @After in corresponding 
classes.)

> Actualize beforeTest, afterTest from JUnit3TestLegacySupport
> 
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Specify beforeTest, afterTest methods documentation in 
> JUnit3TestLegacySupport.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11412) Actualize beforeTest, afterTest from JUnit3TestLegacySupport

2019-03-19 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11412:
--
Summary: Actualize beforeTest, afterTest from JUnit3TestLegacySupport  
(was: Remove beforeTest, afterTest from JUnit3TestLegacySupport)

> Actualize beforeTest, afterTest from JUnit3TestLegacySupport
> 
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Replace beforeTest, afterTest methods in JUnit3TestLegacySupport by 
> annotations @Before, @After in corresponding classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-05 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11411:
--
Labels: iep-30  (was: iep30)

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-03-05 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11411:
--
Ignite Flags:   (was: Docs Required)

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11396) Actualize JUnit3TestLegacyAssert

2019-02-27 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11396:
--
Description: Rename JUnit3TestLegacyAssert class and actualize methods.  
(was: Replace assert methods by imports.

That will lead to full remove JUnit3TestLegacyAssert class.)

> Actualize JUnit3TestLegacyAssert
> 
>
> Key: IGNITE-11396
> URL: https://issues.apache.org/jira/browse/IGNITE-11396
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rename JUnit3TestLegacyAssert class and actualize methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11396) Actualize JUnit3TestLegacyAssert

2019-02-27 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11396:
--
Summary: Actualize JUnit3TestLegacyAssert  (was: Remove 
JUnit3TestLegacyAssert)

> Actualize JUnit3TestLegacyAssert
> 
>
> Key: IGNITE-11396
> URL: https://issues.apache.org/jira/browse/IGNITE-11396
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Replace assert methods by imports.
> That will lead to full remove JUnit3TestLegacyAssert class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11414) Remove JUnit3LegacySupport

2019-02-25 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11414:
-

 Summary: Remove JUnit3LegacySupport
 Key: IGNITE-11414
 URL: https://issues.apache.org/jira/browse/IGNITE-11414
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest 
class or remove if it is possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport

2019-02-25 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11413:
-

 Summary: Remove beforeTestsStarted, afterTestsStarted from 
JUnit3TestLegacySupport
 Key: IGNITE-11413
 URL: https://issues.apache.org/jira/browse/IGNITE-11413
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


beforeTestsStarted and afterTestsStarted methods are deprecated in context of 
JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass 
annotations for such purposes. Methods must be moved in corresponded classes 
and marked by annotations.

It could require changes in start/stop nodes process because methods under  
@BeforeClass, @AfterClass annotations must be static.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11396) Remove JUnit3TestLegacyAssert

2019-02-25 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11396:
--
Issue Type: Improvement  (was: Bug)

> Remove JUnit3TestLegacyAssert
> -
>
> Key: IGNITE-11396
> URL: https://issues.apache.org/jira/browse/IGNITE-11396
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> Replace assert methods by imports.
> That will lead to full remove JUnit3TestLegacyAssert class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11412) Remove beforeTest, afterTest from JUnit3TestLegacySupport

2019-02-25 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11412:
-

 Summary: Remove beforeTest, afterTest from JUnit3TestLegacySupport
 Key: IGNITE-11412
 URL: https://issues.apache.org/jira/browse/IGNITE-11412
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


Replace beforeTest, afterTest methods in JUnit3TestLegacySupport by annotations 
@Before, @After in corresponding classes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport

2019-02-25 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11411:
--
Summary: Remove tearDown, setUp from JUnit3TestLegacySupport  (was: Remove 
tearDown, setUp from GridAbstractTest)

> Remove tearDown, setUp from JUnit3TestLegacySupport
> ---
>
> Key: IGNITE-11411
> URL: https://issues.apache.org/jira/browse/IGNITE-11411
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep30
>
> TearDown and setUp methods are deprecated for JUnit 4+ version. It is 
> necessary to replace them with appropriate methods, marked by @Before and 
> @After annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11411) Remove tearDown, setUp from GridAbstractTest

2019-02-25 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11411:
-

 Summary: Remove tearDown, setUp from GridAbstractTest
 Key: IGNITE-11411
 URL: https://issues.apache.org/jira/browse/IGNITE-11411
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


TearDown and setUp methods are deprecated for JUnit 4+ version. It is necessary 
to replace them with appropriate methods, marked by @Before and @After 
annotations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11396) Remove JUnit3TestLeggriacyAssert

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11396:
--
Labels: iep-30  (was: )

> Remove JUnit3TestLeggriacyAssert
> 
>
> Key: IGNITE-11396
> URL: https://issues.apache.org/jira/browse/IGNITE-11396
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> Replace assert methods by imports.
> That will lead to full remove JUnit3TestLeggriacyAssert class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-11396) Remove JUnit3TestLeggriacyAssert

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-11396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-11396:
--
Ignite Flags:   (was: Docs Required)

> Remove JUnit3TestLeggriacyAssert
> 
>
> Key: IGNITE-11396
> URL: https://issues.apache.org/jira/browse/IGNITE-11396
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
>
> Replace assert methods by imports.
> That will lead to full remove JUnit3TestLeggriacyAssert class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-11396) Remove JUnit3TestLeggriacyAssert

2019-02-22 Thread Ivan Fedotov (JIRA)
Ivan Fedotov created IGNITE-11396:
-

 Summary: Remove JUnit3TestLeggriacyAssert
 Key: IGNITE-11396
 URL: https://issues.apache.org/jira/browse/IGNITE-11396
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov


Replace assert methods by imports.

That will lead to full remove JUnit3TestLeggriacyAssert class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-10958:
--
Description: 
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass -> 
BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled, Categories -> Tag
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace checking timeouts according to JUnit 5 concept: via 
{{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}

8. Change test suites running: @RunWith(Suit.class) to 
@Runwith(JunitPlatform.class)

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]

  was:
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass -> 
BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace checking timeouts according to JUnit 5 concept: via 
{{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}

8. Change test suites running: @RunWith(Suit.class) to 
@Runwith(JunitPlatform.class)

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]


> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for 
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId: 
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from 
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass 
> -> BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled, Categories -> Tag
> 4. Replace concept rules by extension model where it is necessary: 
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace checking timeouts according to JUnit 5 concept: via 
> {{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}
> 8. Change test suites running: @RunWith(Suit.class) to 
> @Runwith(JunitPlatform.class)
> Investigation about migration to JUnit5 is provided in the ticket 
> IGNITE-10180.
> [1] 
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-10958:
--
Description: 
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass -> 
BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace checking timeouts according to JUnit 5 concept: via 
{{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}

8. Change test suites running: @RunWith(Suit.class) to 
@Runwith(JunitPlatform.class)

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]

  was:
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace checking timeouts according to JUnit 5 concept: via 
{{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]


> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for 
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId: 
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from 
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass 
> -> BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled
> 4. Replace concept rules by extension model where it is necessary: 
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace checking timeouts according to JUnit 5 concept: via 
> {{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}
> 8. Change test suites running: @RunWith(Suit.class) to 
> @Runwith(JunitPlatform.class)
> Investigation about migration to JUnit5 is provided in the ticket 
> IGNITE-10180.
> [1] 
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-10958:
--
Description: 
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace checking timeouts according to JUnit 5 concept: via 
{{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]

  was:
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace chrecking timeouts: via {{@Test}}{{(timeout = }}{{1}}{{) or 
assertTimeout.}}

8. 

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]


> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for 
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId: 
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from 
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
> 4. Replace concept rules by extension model where it is necessary: 
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace checking timeouts according to JUnit 5 concept: via 
> {{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}
> Investigation about migration to JUnit5 is provided in the ticket 
> IGNITE-10180.
> [1] 
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5

2019-02-22 Thread Ivan Fedotov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov updated IGNITE-10958:
--
Description: 
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

7. Replace chrecking timeou 

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]

  was:
Starting with maven-surefire-plugin version 2.22.0 there is full support for 
JUnit 5 [1].

Migration to the JUnit 5 includes multiple steps:
 1. adding new JUnit dependencies to pom files. By artifactId: 
junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
junit-platform-runner
 2. Replace all imports of old JUnit annotations by the newest: from 
org.junit.Test to org.junit.jupiter.api.Test
 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
 4. Replace concept rules by extension model where it is necessary: 
ExpectedException to assertThrows
 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].

Investigation about migration to JUnit5 is provided in the ticket IGNITE-10180.

[1] 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]


> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
>  Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: iep-30
> Fix For: 2.8
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for 
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId: 
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, 
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from 
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
> 4. Replace concept rules by extension model where it is necessary: 
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace chrecking timeou 
> Investigation about migration to JUnit5 is provided in the ticket 
> IGNITE-10180.
> [1] 
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


  1   2   3   >