[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning] [3] [https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning [3] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetLongRunning [3] https://ci.ignite.apache.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6606/head&action=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.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/IGNITE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6606/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6434/head&action=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6434/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6434/head&action=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
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&buildTypeId=IgniteTests24Java8_QueriesConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11885) Tests from IgniteCacheConfigVariationsFullApiTest failed on TC
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&buildTypeId=IgniteTests24Java8_CacheFullApiBasicConfigVariations -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11884) Time outed invokeAll tests in WithKeepBinaryCacheFullApiTest
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&buildId=3978682 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11883) Unable to find keys in testKeyAffinityDeploy
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&tab=buildResultsDiv&buildTypeId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&buildTypeId=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&buildTypeId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&buildTypeId=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ 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
[ 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
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
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
[ https://issues.apache.org/jira/browse/IGNITE-11802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6498/head&action=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
[ 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
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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAll&branchForTc=pull/6434/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6267/head&action=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
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
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6227/head&action=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
[ https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&suiteId=IgniteTests24Java8_RunAllNightly&branchForTc=pull/6303/head&action=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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
[ 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
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
[ 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
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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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)