On 1/6/2014, 11:35, Stephen Connolly wrote:
I think once we release 3.2.0 then we can revert back to just 3.2.0 and not
the version range
This was my plan. Sorry I didn't communicate this better.
--
Regards,
Igor
On 6 January 2014 16:16, Jason van Zyl wrote:
In this particular case
I think once we release 3.2.0 then we can revert back to just 3.2.0 and not
the version range
On 6 January 2014 16:16, Jason van Zyl wrote:
> In this particular case once we release 3.2.0 then [3.2.0,) will be
> sufficient and not need to be changed.
>
> On Jan 6, 2014, at 10:51 AM, Stephen Con
In this particular case once we release 3.2.0 then [3.2.0,) will be sufficient
and not need to be changed.
On Jan 6, 2014, at 10:51 AM, Stephen Connolly
wrote:
> I looked into that... the issue here is that the code does not promise to
> be able to give you a version of Maven, IOW there are so
I looked into that... the issue here is that the code does not promise to
be able to give you a version of Maven, IOW there are some cases where the
test harness will just give up and say "Oh the maven version is null
because I can't figure it out... I'll ignore all skips now... good luck"...
Othe
We don't really have an easy way to specify an interim version that needs to be
tested. Once 3.2 is release it can be updated and locked down. If we always
want to test the version exercised by the ITs we'll have to figure that out.
Maybe as simple as exposing a property we can interpolate into
The issue was he had hard-coded 3.1.2-SNAPSHOT in the test resource. I
changed that to [3.1.2-SNAPSHOT,) which gets 3.2.0-SNAPSHOT working for
now... but is still hacky...
On 6 January 2014 15:36, Jason van Zyl wrote:
>
> On Jan 6, 2014, at 9:07 AM, Stephen Connolly <
> stephen.alan.conno...@gm
Yup, I agree.
On Jan 6, 2014, at 10:39 AM, Stephen Connolly
wrote:
> yes but keep the dash between the mng and the mng number
>
>
> On 6 January 2014 15:24, Jason van Zyl wrote:
>
>> +1 On the original name
>>
>> I just made another IT and it's definitely much clearer with the JIRA id
>> a
yes but keep the dash between the mng and the mng number
On 6 January 2014 15:24, Jason van Zyl wrote:
> +1 On the original name
>
> I just made another IT and it's definitely much clearer with the JIRA id
> and a short blurb. I see this as an improvement.
>
> On Jan 6, 2014, at 7:51 AM, Igor F
On Jan 6, 2014, at 9:07 AM, Stephen Connolly
wrote:
> The test name was not the issue, though not keeping with the pattern is,
> e.g. `mng-5530-blah-blah-blah` if you must but not `mng5530-blah-blah-blah`
> as all the other tests start with `mng-` so they are sorted consistently
Sure, that's a
+1 On the original name
I just made another IT and it's definitely much clearer with the JIRA id and a
short blurb. I see this as an improvement.
On Jan 6, 2014, at 7:51 AM, Igor Fedorenko wrote:
> Stephen,
>
> I would prefer to keep the original test name, i.e.
> mng5530-mojo-execution-scope
The test name was not the issue, though not keeping with the pattern is,
e.g. `mng-5530-blah-blah-blah` if you must but not `mng5530-blah-blah-blah`
as all the other tests start with `mng-` so they are sorted consistently
The real issue was that the test case itself broke when I switched the
Maven
Stephen,
I would prefer to keep the original test name, i.e.
mng5530-mojo-execution-scope. Having both the JIRA issue id and short
description of the test makes it much easier to understand what the test
is supposed to do and still be able to find any additional information
if needed.
Can you ex
12 matches
Mail list logo
