2018-05-04 8:32 GMT+02:00 Jan Matèrne (jhm) :
> Changing Ants own test to use JUnit5 does not mean we have to change Ant
> itself and don't have to cut a release.
>
> What do you want to move to "ant-legacy"?
>
You're right, JUnit 5 puts no new requirements on Ant.
Should we continue a "legacy"
2018-05-05 17:58 GMT+02:00 Stefan Bodewig :
> What is the benefit of changing tests that currently pass when neither
> the test itself nor the code under test is changed?
>
That would be avoiding repetitive code => lucidity.
Eg, for every simple executeTarget("test") there are at least 3 more lin
On 2018-05-03, Gintautas Grigelionis wrote:
> 2018-05-03 11:06 GMT+02:00 Stefan Bodewig :
>> I'm still not sure I understand which benefit you see by retrofitting
>> tests that have been written before @Parameterized was invented. They do
>> contain way too many asserts in a single test method, b
Donnerstag, 3. Mai 2018 20:46
> An: Ant Developers List
> Betreff: Re: Parameterized Tests (was Re: ant git commit: Inline
> buildfile names, make search easier)
>
> IMHO that would mean putting parts of Ant core into ant-legacy.jar
>
> Gintas
>
> 2018-05-03 19:03
IMHO that would mean putting parts of Ant core into ant-legacy.jar
Gintas
2018-05-03 19:03 GMT+02:00 Matt Sicker :
> Yes, I'm definitely suggesting/hyping JUnit 5. :)
>
Yes, I'm definitely suggesting/hyping JUnit 5. :)
On 3 May 2018 at 12:01, Gintautas Grigelionis
wrote:
> My focus was on maximising the use of JUnit 4 idioms.
> Are you suggesting a switch to JUnit 5 instead?
> Sounds like Ant 1.11 :-)
>
> Gintas
>
> 2018-05-03 17:12 GMT+02:00 Matt Sicker :
>
>
My focus was on maximising the use of JUnit 4 idioms.
Are you suggesting a switch to JUnit 5 instead?
Sounds like Ant 1.11 :-)
Gintas
2018-05-03 17:12 GMT+02:00 Matt Sicker :
> I've started using JUnit 5 in a personal project and found that it has a
> lot more useful features for test parameters
I've started using JUnit 5 in a personal project and found that it has a
lot more useful features for test parameters. For instance, they now
support parameterized test methods instead of just the class itself. There
are also more convenient ways of injecting test data through annotations
and such.
2018-05-03 11:06 GMT+02:00 Stefan Bodewig :
>
> I'm still not sure I understand which benefit you see by retrofitting
> tests that have been written before @Parameterized was invented. They do
> contain way too many asserts in a single test method, but all of them
> pass, so this is somewhat moot a
On 2018-04-30, Gintautas Grigelionis wrote:
> 2018-04-30 13:13 GMT+00:00 Stefan Bodewig :
>> On 2018-04-30, Gintautas Grigelionis wrote:
>>> the overarching goal, however, is to reduce verbosity, because
>>> verbosity makes it easier to hide mistakes.
>> This is your goal and we should have deci
2018-04-30 13:13 GMT+00:00 Stefan Bodewig :
> On 2018-04-30, Gintautas Grigelionis wrote:
> > the overarching goal, however, is to reduce verbosity, because
> > verbosity makes it easier to hide mistakes.
>
> This is your goal and we should have decided together whether we agree
> on this goal. Th
On 2018-04-30, Gintautas Grigelionis wrote:
> I do realize that some changes might be a subject for discussion;
Gintas, please try to see what the others are saying. Most of the
changes are changes that nobody of those who've spoken up consider
improvements at all - apart from yourself. The outco
2018-04-30 11:20 GMT+00:00 Jan Matèrne (jhm) :
> For that single point I think parametrization is 'good'.
> If I count right, it impacted three test classes.
> Why change all the others?
>
> Starting a discussion before such big changes would also be helpful.
>
Just to pick a nit, there are 9 par
> > In my eyes most of the committers don't like these "code style"
> changes.
> > So please stop these changes and invest your energy more productive.
> >
> > I don't think it would be helpful if another committer starts
> > reverting the changes because of a different preference ...
>
>
> With
2018-04-30 10:45 GMT+00:00 Jan Matèrne (jhm) :
> In my eyes most of the committers don't like these "code style" changes.
> So please stop these changes and invest your energy more productive.
>
> I don't think it would be helpful if another committer starts reverting the
> changes because of a di
2018-04-30 10:43 GMT+00:00 Jaikiran Pai :
>
> On 30/04/18 12:52 PM, Gintautas Grigelionis wrote:
>
>> My apologies for offending anyone; just one last silly question: why
>> uniformity is not a requirement?
>>
> I think it has already been explained in the other thread why it's not a
> necessity f
2018-04-30 10:35 GMT+00:00 Jaikiran Pai :
>
> On 30/04/18 3:52 PM, Gintautas Grigelionis wrote:
>
>> 2018-04-30 9:55 GMT+00:00 Stefan Bodewig :
>>
>> On 2018-04-30, Gintautas Grigelionis wrote:
>>>
>>> My apologies for offending anyone; just one last silly question: why
uniformity is not a re
> > Changes like these are random personal preferences.
>
> Right.
>
> > The fact that these are being done even after the mail discussions we
> > recently had, indicates that the request to not do such changes have
> > been ignored. This is going down the route of a being some kind of a
> > pers
On 30/04/18 12:52 PM, Gintautas Grigelionis wrote:
My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?
I think it has already been explained in the other thread why it's not a
necessity for a project as large and as old as this one, especially w
> Le 30 avr. 2018 à 11:58, Stefan Bodewig a écrit :
>
> On 2018-04-30, Jaikiran Pai wrote:
>
>> Changes like these are random personal preferences.
>
> Right.
>
>> The fact that these are being done even after the mail discussions we
>> recently had, indicates that the request to not do such
On 30/04/18 3:52 PM, Gintautas Grigelionis wrote:
2018-04-30 9:55 GMT+00:00 Stefan Bodewig :
On 2018-04-30, Gintautas Grigelionis wrote:
My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?
Who's uniformity do you pick? There are so many choi
2018-04-30 9:55 GMT+00:00 Stefan Bodewig :
> On 2018-04-30, Gintautas Grigelionis wrote:
>
> > My apologies for offending anyone; just one last silly question: why
> > uniformity is not a requirement?
>
> Who's uniformity do you pick? There are so many choices that only depend
> on taste.
>
> asse
On 2018-04-30, Jaikiran Pai wrote:
> Changes like these are random personal preferences.
Right.
> The fact that these are being done even after the mail discussions we
> recently had, indicates that the request to not do such changes have
> been ignored. This is going down the route of a being s
On 2018-04-30, Gintautas Grigelionis wrote:
> My apologies for offending anyone; just one last silly question: why
> uniformity is not a requirement?
Who's uniformity do you pick? There are so many choices that only depend
on taste.
assertEquals(x, y) vs assertThat(y, equalTo(x)) amd many many s
My apologies for offending anyone; just one last silly question: why
uniformity is not a requirement?
I believe that even one language that espoused TMTOWDI has moved to
TIMTOWTDIBSCINABTE?
Gintas
2018-04-30 5:56 GMT+00:00 Jaikiran Pai :
>
> On 30/04/18 11:12 AM, Gintautas Grigelionis wrote:
>
>
On 30/04/18 11:12 AM, Gintautas Grigelionis wrote:
Names of buildfiles used in tests can be found by "grep configureProject"?
Why is that even a requirement?
I think I am just repeating myself again and again in different mails.
Changes like these are random personal preferences. The fact tha
Names of buildfiles used in tests can be found by "grep configureProject"?
The point is that these names are used exactly once, and need not to be put
in a field which is named inconsistently.
Deviations from this rule of thumb indicate that tests are parameterized in
a manner where each test has i
What purpose is this change serving?
-Jaikiran
On 30/04/18 10:08 AM, gin...@apache.org wrote:
Repository: ant
Updated Branches:
refs/heads/master 0add85310 -> f3dfb7779
Inline buildfile names, make search easier
Project: http://git-wip-us.apache.org/repos/asf/ant/repo
Commit: http://git-
28 matches
Mail list logo
