Re: SQL: INSERT with hidden columns _key, _val and check the type of input objects
Folks,
Do we want to preserve the annotation-based configuration? There are too
many ways to configure SQL indexes/fields.
For instance, if our new SQL API could see and access all of the fields
out-of-the-box (without any extra settings) and DDL will be used to define
indexed fields then that would be a huge usability improvement.
-
Denis
On Thu, Feb 21, 2019 at 5:27 AM Taras Ledkov wrote:
> Hi,
>
> Lets discuss SQL DML (INSERT/UPDATE) current behavior specific:
>
> Ignite doesn't check a type of input objects when hidden columns _key,
> _value is used in a DML statements.
> I describe the current behavior for example:
>
> 1. Cache configuration: 'setIndexedTypes(PersonKey.class, Person.class))'
> 2. PersonKey type contains 'int id' field.
> 3. SQL statement: 'INSERT INTO test (_val, _key) VALUES (?, ?)'
>
> Cases:
> 1. Invalid value object type:
> - Any value object may be passed as a query parameter
> - Query is executed without an error and returns '1' (one row updated);
> - There is not inserted row at the 'SELECT * FROM test' results.
> - cache.get(key) returns inserted object;
>
> 2. Invalid key object type:
> 2.1 Non-primitive object is passed and binary representation doesn't
> contain 'id' field.
> - Query is executed without error and returns '1' (one row updated);
> - The inserted row is available by 'SELECT *' and the row contains id =
> null;
> 2.2 Non-primitive object is passed and binary representation contains
> 'id' field.
> - The inserted row is available by 'SELECT *' and the row contains
> expected 'id' field;
> - The cache entry cannot be gathered by 'cache.get' operation with the
> corresponding 'PersonKey(id)' (keys differ).
>
> I propose to check type of the user's input object.
>
> I guess that using _key/_val columns works close to 'cache.put()' but it
> looks like significant usability issue.
> To confuse the 'PersonKey.class.getName()' and
> 'node.binary().builder("PersonKey")' is a typical mistake of Ignite
> newcomers.
>
> One more argument for check: SQL INSERT sematic means the row is
> inserted into the specified TABLE, not into the cache.
> So, throw IgniteSQLException is expected behavior in this case, i think.
>
> [1]. https://issues.apache.org/jira/browse/IGNITE-5250
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>
Re: [MTCGA]: new failures in builds [3002875] needs to be handled
It is still that strange issue with tests naming changes in case of initialization failure. So it is not contributed test, but flaky init. failure. пт, 22 февр. 2019 г. в 00:56, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *Recently contributed test failed in master > continuous.CacheContinuousQueryOperationFromCallbackTest > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6577589696474712460=%3Cdefault%3E=testDetails > No changes in the build > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 00:56:31 22-02-2019 >
[MTCGA]: new failures in builds [3002875] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Recently contributed test failed in master continuous.CacheContinuousQueryOperationFromCallbackTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6577589696474712460=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 00:56:31 22-02-2019
[jira] [Created] (IGNITE-11384) Introduce an opportunity of services hot redeployment via DeploymentSpi
Vyacheslav Daradur created IGNITE-11384: --- Summary: Introduce an opportunity of services hot redeployment via DeploymentSpi Key: IGNITE-11384 URL: https://issues.apache.org/jira/browse/IGNITE-11384 Project: Ignite Issue Type: Sub-task Components: managed services Reporter: Vyacheslav Daradur Assignee: Vyacheslav Daradur Fix For: 2.8 We can integrate service processor with DeploymentSpi to introduce an opportunity of services hot redeployment. For this change, the service processor should try to get and use registered classloader registered for the service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11383) Unable to restart node with WALMode.NONE
Pavel Vinokurov created IGNITE-11383:
Summary: Unable to restart node with WALMode.NONE
Key: IGNITE-11383
URL: https://issues.apache.org/jira/browse/IGNITE-11383
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.7
Reporter: Pavel Vinokurov
Attachments: MemoryRestoreReproducer.java
Scenario:
1. Start single node with persistence without WAL.
2. Stream data to a cache.
3. Restart the node.
Result:
Node failed with following exception.
{code:java}
Exception in thread "main" class org.apache.ignite.IgniteException: null
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1059)
at org.apache.ignite.Ignition.start(Ignition.java:324)
at MemoryRestoreReproducer.main(MemoryRestoreReproducer.java:27)
Caused by: class org.apache.ignite.IgniteCheckedException: null
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1196)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1992)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1109)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:629)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:554)
at org.apache.ignite.Ignition.start(Ignition.java:321)
... 1 more
Caused by: java.util.NoSuchElementException
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:39)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.read(FileWriteAheadLogManager.java:855)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.performBinaryMemoryRestore(GridCacheDatabaseSharedManager.java:2120)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:749)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4963)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1058)
... 7 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Migration to JUnit 5
Hi Ivan, Thank you for your efforts! I checked a section "Motivation" in IEP and I think that we should add more details there. You provided mostly examples of more convenient assertions. But there are other options to deal with it. E.g. AssertJ library [1] (I think that we can consider it even after migration to junit5). It would be great if we can describe some junit5 features which can make our life simpler and there is no alternative in junit4. E.g. we have the similar Parameterized concept in junit4, so it does not look as a big win here. Also, an impact on everyday development should be estimated. As I know, junit5 has a compatibility layer which allows to migrate from junit4 seamlessly. But as I understood you would like to use new junit5 features. And we have well-known GridAbstractTest which historically was bound to junit3, now is bound to junit4. Should we change it significantly for junit5? Should we change other existing tests? Suites? Could you please address my concerns? Let's discuss pros and cons. I will be happy to help there. [1] http://joel-costigliola.github.io/assertj/ чт, 21 февр. 2019 г. в 18:07, Ivan Fedotov : > > Dmitriy, thank you, access is fine. > > I have created the corresponding IEP [1]. > > Now I am going to continue work on this. If somebody has any suggestions or > additions I am ready to discuss them. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > чт, 21 февр. 2019 г. в 01:42, Dmitriy Pavlov : > > > Done, please check access now. > > > > ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov : > > > > > Dmitriy, thank you for the response. > > > > > > My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com > > . > > > > > > ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov : > > > > > > > Hi Ivan, > > > > > > > > Now admin service is unavailable (gives error 503). I'll add rights > > once > > > it > > > > is up and running. > > > > > > > > Could you share your wiki username? I can't find any users who signed > > up > > > in > > > > the wiki with any similar email/username > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov : > > > > > > > > > Hi, Igniters. > > > > > > > > > > I am planning to formalize migration to JUnit5 and create IEP which > > > will > > > > > include related issues. > > > > > > > > > > I already started to work on one of the issues [1] and created a > > draft > > > > for > > > > > the corresponding IEP [2]. > > > > > > > > > > Please, give me rights for confluence to create IEP. > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973 > > > > > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759 > > > > > > > > > > Sincerely, > > > > > Ivan Fedotov. > > > > > > > > > > ivanan...@gmail.com > > > > > > > > > > > > > > > > > > -- > > > Ivan Fedotov. > > > > > > ivanan...@gmail.com > > > > > > > > -- > Ivan Fedotov. > > ivanan...@gmail.com -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-11382) Stop managers from all caches before caches stop
Anton Kalashnikov created IGNITE-11382: -- Summary: Stop managers from all caches before caches stop Key: IGNITE-11382 URL: https://issues.apache.org/jira/browse/IGNITE-11382 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov It is required to stop all cache managers before stopping this caches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Dmitriy, thank you, access is fine. I have created the corresponding IEP [1]. Now I am going to continue work on this. If somebody has any suggestions or additions I am ready to discuss them. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 чт, 21 февр. 2019 г. в 01:42, Dmitriy Pavlov : > Done, please check access now. > > ср, 20 февр. 2019 г. в 21:49, Ivan Fedotov : > > > Dmitriy, thank you for the response. > > > > My wiki username is "ivanan", the related mailbox is ivanan...@gmail.com > . > > > > ср, 20 февр. 2019 г. в 18:38, Dmitriy Pavlov : > > > > > Hi Ivan, > > > > > > Now admin service is unavailable (gives error 503). I'll add rights > once > > it > > > is up and running. > > > > > > Could you share your wiki username? I can't find any users who signed > up > > in > > > the wiki with any similar email/username > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > ср, 20 февр. 2019 г. в 18:26, Ivan Fedotov : > > > > > > > Hi, Igniters. > > > > > > > > I am planning to formalize migration to JUnit5 and create IEP which > > will > > > > include related issues. > > > > > > > > I already started to work on one of the issues [1] and created a > draft > > > for > > > > the corresponding IEP [2]. > > > > > > > > Please, give me rights for confluence to create IEP. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10973 > > > > [2] https://gist.github.com/1vanan/1f81319f1dc6d6ebca30c216fdd82759 > > > > > > > > Sincerely, > > > > Ivan Fedotov. > > > > > > > > ivanan...@gmail.com > > > > > > > > > > > > > -- > > Ivan Fedotov. > > > > ivanan...@gmail.com > > > -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11381) Document XML task config format for UriDeploymentSpi
Denis Mekhanikov created IGNITE-11381:
-
Summary: Document XML task config format for UriDeploymentSpi
Key: IGNITE-11381
URL: https://issues.apache.org/jira/browse/IGNITE-11381
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
{{UriDeploymentSpi}} lets archives with deployed classes contain {{ignite.xml}}
file, describing tasks in the the archive. Format of this file should be
documented and examples should be provided.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: UriDeploymentSpi and GAR files
I created the following tickets: https://issues.apache.org/jira/browse/IGNITE-11379 – drop support of GARs https://issues.apache.org/jira/browse/IGNITE-11380 – support JARs https://issues.apache.org/jira/browse/IGNITE-11381 – document ignite.xml file format. Denis ср, 20 февр. 2019 г. в 12:30, Nikolay Izhikov : > Hello, Denis. > > > This XML may contain task descriptors, but I couldn't find any > documentation on this format. > > This information can be provided in simple JAR files with the same file > structure. > > I support you proposal. Let's: > > 1. Support jar files instead of gar. > 2. Write down documentation about XML config format. > 3. Provide some examples. > > Can you crate a tickets for it? > > > ср, 20 февр. 2019 г. в 11:49, Denis Mekhanikov : > > > Denis, > > > > This XML may contain task descriptors, but I couldn't find any > > documentation on this format. > > Also it may contain a userVersion [1] parameter, which can be used to > force > > tasks redeployment in some cases. > > > > This information can be provided in simple JAR files with the same file > > structure. > > There is no need to confuse people and require their packages to have a > GAR > > extension. > > > > Also if you don't specify the task descriptors, then all tasks in the > file > > will be registered. > > So, I doubt, that anybody will bother specifying the descriptors. XML is > > not very user-friendly. > > This piece of configuration doesn't seem necessary to me. > > > > [1] > > > > > https://apacheignite.readme.io/docs/deployment-modes#section-un-deployment-and-user-versions > > > > Denis > > > > ср, 20 февр. 2019 г. в 01:35, Denis Magda : > > > > > Denis, > > > > > > What was the purpose of having XML and other files within the GARs? > Guess > > > it was somehow versioning related - you might have several tasks of the > > > same class but different versions running in a cluster. > > > > > > - > > > Denis > > > > > > > > > On Tue, Feb 19, 2019 at 8:40 AM Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > > > > > wrote: > > > > > > > Hello! > > > > > > > > Yes, I think we should accept plain JARs if anybody needs this at > all. > > > > Might still keep meta info support for compatibility. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > вт, 19 февр. 2019 г. в 19:38, Denis Mekhanikov < > dmekhani...@gmail.com > > >: > > > > > > > > > Hi! > > > > > > > > > > There is a feature in Ignite called DeploymentSpi [1], that allows > > > adding > > > > > and changing implementation of compute tasks without nodes' > downtime. > > > > > The only usable implementation right now is UriDeploymentSpi [2], > > which > > > > > lets you provide classes of compute tasks packaged as an archive > of a > > > > > special form. And this special form is the worst part. > > > > > GAR file is just like a JAR, but with some additional meta info. It > > may > > > > > contain an XML with description of tasks, a checksum and also > > > > dependencies. > > > > > > > > > > We barely have any tools to build these files, and they can be > > replaced > > > > > with simple uber-JARs. > > > > > The only tool we have right now is IgniteDeploymentGarAntTask, > which > > is > > > > not > > > > > documented anywhere, and it's supposed to be used from a > > long-forgotten > > > > > Apache Ant build system. > > > > > > > > > > I don't think we need this file format. How about we deprecate and > > > remove > > > > > it and make UriDeploymentSpi support plain JARs? > > > > > > > > > > [1] https://apacheignite.readme.io/docs/deployment-spi > > > > > [2] > > > > > > > > > > > > > > > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/deployment/uri/UriDeploymentSpi.html > > > > > > > > > > Denis > > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-11379) Drop support of GAR files
Denis Mekhanikov created IGNITE-11379: - Summary: Drop support of GAR files Key: IGNITE-11379 URL: https://issues.apache.org/jira/browse/IGNITE-11379 Project: Ignite Issue Type: Task Reporter: Denis Mekhanikov GAR file format doesn't seem to be actually needed in Ignite. There are virtually no tools for their assembly, and simple JARs with the same structure could be used instead. Dev list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/UriDeploymentSpi-and-GAR-files-td40869.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11380) Make UriDeploymentSpi support JAR files
Denis Mekhanikov created IGNITE-11380:
-
Summary: Make UriDeploymentSpi support JAR files
Key: IGNITE-11380
URL: https://issues.apache.org/jira/browse/IGNITE-11380
Project: Ignite
Issue Type: Improvement
Reporter: Denis Mekhanikov
Fix For: 2.8
{{UriDeploymentSpi}} doesn't support JAR files. Only GAR files can be used
currently.
It would be good to add possibility to provide classes to the {{UriDeployment}}
packaged as plain JARs.
Dev list discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/UriDeploymentSpi-and-GAR-files-td40869.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11378) Critical system errors on cluster with enabled peristance
Pavel Vinokurov created IGNITE-11378: Summary: Critical system errors on cluster with enabled peristance Key: IGNITE-11378 URL: https://issues.apache.org/jira/browse/IGNITE-11378 Project: Ignite Issue Type: Bug Components: persistence Reporter: Pavel Vinokurov Attachments: CheckpointLockReproducer.java The attached reproducer shows the following exception during streaming data to cache: [2019-02-21 16:15:23,202][ERROR][tcp-disco-msg-worker-[100a6976 0:0:0:0:0:0:0:1%lo:47500]-#19%3%][root] Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet []]], failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker [name=data-streamer-stripe-5, igniteInstanceName=3, finished=false, heartbeatTs=1550754912905]]] class org.apache.ignite.IgniteException: GridWorker [name=data-streamer-stripe-5, igniteInstanceName=3, finished=false, heartbeatTs=1550754912905] If the blocked timeout is changed by cfg.setSystemWorkerBlockedTimeout(30_000), after streaming data and restarting several nodes the following critical error occurs: [2019-02-21 16:24:07,164][ERROR][grid-timeout-worker-#214%client%][G] Blocked system-critical thread has been detected. This can lead to cluster-wide undefined behaviour [threadName=tcp-comm-worker, blockedFor=36s] [2019-02-21 16:24:07,166][WARN ][grid-timeout-worker-#214%client%][G] Thread [name="tcp-comm-worker-#25%client%", id=482, state=TIMED_WAITING, blockCnt=0, waitCnt=729] [2019-02-21 16:24:07,168][ERROR][grid-timeout-worker-#214%client%][root] Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet []]], failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker [name=tcp-comm-worker, igniteInstanceName=client, finished=false, heartbeatTs=1550755410331]]] class org.apache.ignite.IgniteException: GridWorker [name=tcp-comm-worker, igniteInstanceName=client, finished=false, heartbeatTs=1550755410331] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
SQL: INSERT with hidden columns _key, _val and check the type of input objects
Hi,
Lets discuss SQL DML (INSERT/UPDATE) current behavior specific:
Ignite doesn't check a type of input objects when hidden columns _key,
_value is used in a DML statements.
I describe the current behavior for example:
1. Cache configuration: 'setIndexedTypes(PersonKey.class, Person.class))'
2. PersonKey type contains 'int id' field.
3. SQL statement: 'INSERT INTO test (_val, _key) VALUES (?, ?)'
Cases:
1. Invalid value object type:
- Any value object may be passed as a query parameter
- Query is executed without an error and returns '1' (one row updated);
- There is not inserted row at the 'SELECT * FROM test' results.
- cache.get(key) returns inserted object;
2. Invalid key object type:
2.1 Non-primitive object is passed and binary representation doesn't
contain 'id' field.
- Query is executed without error and returns '1' (one row updated);
- The inserted row is available by 'SELECT *' and the row contains id =
null;
2.2 Non-primitive object is passed and binary representation contains
'id' field.
- The inserted row is available by 'SELECT *' and the row contains
expected 'id' field;
- The cache entry cannot be gathered by 'cache.get' operation with the
corresponding 'PersonKey(id)' (keys differ).
I propose to check type of the user's input object.
I guess that using _key/_val columns works close to 'cache.put()' but it
looks like significant usability issue.
To confuse the 'PersonKey.class.getName()' and
'node.binary().builder("PersonKey")' is a typical mistake of Ignite
newcomers.
One more argument for check: SQL INSERT sematic means the row is
inserted into the specified TABLE, not into the cache.
So, throw IgniteSQLException is expected behavior in this case, i think.
[1]. https://issues.apache.org/jira/browse/IGNITE-5250
--
Taras Ledkov
Mail-To: tled...@gridgain.com
Re: beforeTestsStarted() was deprecated, what should we use instead?
Hi Anton, I re-checked details of the JIRA task you mentioned [1] and it looks like finished to me, sorry. Ticket description is a list of specific items to be addressed and as far as I can tell all of them are done. Since you mentioned review, changes made per this ticket were fairly thoroughly reviewed: for example respective PR [2] lists five commits that were done to address review comments. And as far as I remember at the time of review we had a solid consensus that scope of these changes is determined by concrete items listed in task description. Note by the way that after merge of these changes it became impossible to write JUnit3 tests inheriting GridAbstractTest. One can probably call this part of the changes final. --- Speaking of JUnit3TestLegacySupport, TODOs are there to help readers see that some specific parts of code in this class are expected to change per particular JIRA task. That it should be (eventually) completely removed or somehow reworked in the future is irrelevant here because this can be done gradually, in different time, for different reasons and by different JIRA tasks. --- With regards to what you call "final Junit3 removal", I find it hard to comprehend what exactly you want nor how this can be expressed in practical actions of changing concrete code. In contrast, the way how migration effort was explained at dev list discussion that started it looks clear and understandable: "Is it time to start translating tests to Unit 4 style?" (worth noting that it further goes into even more concrete and practical explanation of what change is desired and why, explaining that we want to be able to use @Ignore annotation to simplify maintenance at Teamcity) And umbrella JIRA task that followed this discussion [4] also has actionable description of what is to be done: "This task is to migrate all tests to single uniform version Junit 4". Speaking in terms of mentioned discussion and JIRA task, this is all done and over - finished and verified ([5]). In fact, anyone can verify whether migration is completed by doing plain text search for "junit.framework" in project files and reviewing search results to make sure that there are no test classes / suites inheriting the old API (JUnit 3 package names start with junit.framework). It's very easy, just give it a try. Summing up, I don't know what you have in mind speaking of what else should be done or finalized, but whatever it is, I can't see how it would fit into the scope of our original discussion here and of original JIRA task. [1] https://issues.apache.org/jira/browse/IGNITE-10177 [2] https://github.com/apache/ignite/pull/5615 [3] http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-td29608.html [4] https://issues.apache.org/jira/browse/IGNITE-10173 [5] https://issues.apache.org/jira/browse/IGNITE-10629 regards, Oleg Anton Vinogradov-2 wrote > Oleg, > > You may use TODO if it is really necessary. > I see no reason to have any todo at JUnit3TestLegacySupport class since > it's already marked as legacy and should be removed in the future. > And we should have an issue about this removal. > > Why you closed GNITE-10177 "cleanup Junit 3 from the project" since you're > not finished work? > Why now we discuss incorrect deprecation instead of making proper fix > design in advance? > > One more question to the committer. > Dmitriy, > > Why incomplete fix was merged to master without any issues responsible for > finalization? > Who's now responsible for final Junit3 removal? > > On Mon, Feb 18, 2019 at 4:22 PM oignatenko > oignatenko@ > wrote: > >> Hi Anton, >> >> I removed @deprecated from javadoc, thanks for noticing. PR #6122 [1] is >> updated. >> >> As for TODOs, I think you are wrong here because Ignite coding guidelines >> [2] not only explicitly allow these but also explain the format in which >> these should be presented. If you find violations of recommended TODOs >> format, please let me know. >> >> regards, Oleg >> >> [1]: https://github.com/apache/ignite/pull/6122 >> [2]: >> >> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-TODOs >> >> >> >> -- >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
