beforeTestsStarted() was deprecated recently.
See following comment at beforeTestsStarted():
* @deprecated This method is deprecated. Instead of invoking or overriding
it, it is recommended to make your own
* method with {@code @BeforeClass} annotation.
But, according to Junit documentation:
* An
Hi Anton,
You can start and stop grid from static context required by mentioned
annotations using code like:
MyTestClass.class.newInstance().startGrid();
This way doesn't look very convenient and I created JIRA task to address
that:
https://issues.apache.org/jira/browse/IGNITE-11240
D
Hi,
AFAIK various startGrid* methods of GridAbstractTest are not tied to
concrete instance of test class. I think that a we can make them
static. Also same can be done for some other methods and all they can
be extracted into static utility class like GridTestSupport in order
to reduce GridAbstrac
I vote for any proper solution :)
For now, we have to rollback the deprecation.
On Thu, Feb 7, 2019 at 11:46 AM Павлухин Иван wrote:
> Hi,
>
> AFAIK various startGrid* methods of GridAbstractTest are not tied to
> concrete instance of test class. I think that a we can make them
> static. Also s
Hi Ivan,
For the sake of precision, startGrid() is currently overridden in one of
subclasses of GridAbstractTest. This means that we would have to somehow
handle that when changing this method to static. Same thing is with another
solid candidate to making static, stopAllGrids(boolean), which is a
Oleg,
Still, see beforeTestsStarted is deprecated.
Since we found this deprecation was incorrect, we have to roll it back.
Please fix the issue.
On Thu, Feb 7, 2019 at 5:18 PM oignatenko wrote:
> Hi Ivan,
>
> For the sake of precision, startGrid() is currently overridden in one of
> subclasses
Hi Anton,
I would like to re-check if I correctly understand the plan.
So, we are going to remove deprecation from these two methods - and the
reason for this is that the way recommended instead of these methods makes
it less convenient to start and stop the grid.
Now, regarding the mentioned in
Oleg,
Task creation is not equaled to task in progress.
It means nothing, to be honest.
Are you going to fix this issue?
That's not the first time we have such discussion at the community.
So, now I have a clear vision.
Since you contributed code with problems you are responsible to
- fix them or
Anton,
Could you please provide a link to a section in Ignite development
process document (or alike) stating in what cases "we should avoid a
discussion" and proceed with steps suggested by you? Sincerely, I am
not aware. Sorry if I missed it.
пн, 18 февр. 2019 г. в 11:33, Anton Vinogradov :
>
>
Ivan.
Please, use the quote right: "We should avoid any discussions *this time*."
This means - "We should *fix the issue* as quick as we can and discuss
correct improvement after"
Should we live this long with wrong deprecation?
I don't think so.
пн, 18 февр. 2019 г. в 11:58, Павлухин Иван :
>
Nikolay,
I agree with you and Anton that discussed deprecation is not a good thing.
But it is quite interesting for me personally where our community
declared actions which should be taken against troublesome
contributions.
пн, 18 февр. 2019 г. в 12:11, Nikolay Izhikov :
>
> Ivan.
>
> Please, us
Ivan, I think we should use common sense here.
1. We should keep master consistent.
2. Contributors should try to fix issues appeared with their contribution.
Do you agree with this?
If some contributor can't fix issue quickly, is't completely OK.
But, we should find another contributor, or reve
Nikolay,
I agree with all points. But one thing is very uncertain. What
contribution is really troublesome (and consequently should be fixed
quickly or reverted)? But in fact it is a topic for a separate
discussion.
In current case about deprecation I agree with Nikolay and Anton. It
should be re
Hi Anton,
There you go:
PR to remove deprecation: https://github.com/apache/ignite/pull/6122
JIRA: https://issues.apache.org/jira/browse/IGNITE-11345
If anything there is not as you expected, please let me know.
regards, Oleg
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.co
Oleg,
Every commit should be final.
Comments, TODOs and partial fixes (why @deprecated still at Javadoc?) are
unacceptable.
On Mon, Feb 18, 2019 at 3:23 PM oignatenko wrote:
> Hi Anton,
>
> There you go:
>
> PR to remove deprecation: https://github.com/apache/ignite/pull/6122
> JIRA: https://is
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 recom
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
Anton,
Do you have real questions? Seems like you're trying to state your opinion
related to the fix rather than asking a question.
We've discussed it in the thread related to Failure Handler fix, that whole
community is responsible to make things better. Mostly, contributors, who
care (proof of
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
19 matches
Mail list logo