GitHub user sverhagen opened a pull request:
https://github.com/apache/maven-surefire/pull/138
SUREFIRE-1309: Clarifying use of regular expressions for inclusion/exclusion
Added clarification to site examples, as discussed in
[SUREFIRE-1309](https://issues.apache.org/jira/browse/SUR
GitHub user michaldo opened a pull request:
https://github.com/apache/maven-plugins/pull/102
MWAR-257 Remove deprecation of dependentWarExcludes, since there is no
alternative on global level
Revert "[MWAR-367] Overlay removes /META-INF/context.xml"
This reverts commit cb25
Am 12/27/16 um 00:57 schrieb Christian Schulte:
> Am 12/26/16 um 23:04 schrieb Stephen Connolly:
>> Well that certainly puts a different light on things
>>
>> With this being a regression introduced in 3.x it should be significantly
>> less contentious to fix.
>>
>> What would be good is to find wh
Am 12/26/16 um 23:04 schrieb Stephen Connolly:
> Well that certainly puts a different light on things
>
> With this being a regression introduced in 3.x it should be significantly
> less contentious to fix.
>
> What would be good is to find when exactly the regression was introduced:
> 3.0.x or 3
Well that certainly puts a different light on things
With this being a regression introduced in 3.x it should be significantly
less contentious to fix.
What would be good is to find when exactly the regression was introduced:
3.0.x or 3.1.x
On Mon 26 Dec 2016 at 21:42, Christian Schulte wrote:
Am 12/26/16 um 21:07 schrieb Stephen Connolly:
> Well a command line switch is useless imho.
+1
>
> Suppose I have a multi-module reactor and one module uses version A of
> plugin X and another module uses version B.
>
> Now A was built against Maven 3.3.3 and the classpath was "fixed" with
> t
> This is not something that the user should be able to control directly
Makes sense, since this only affects plugins, to not expect or enable user
control of this feature.
Thank you for explaining.
(I also do not prefer a CLI switch for this due to the "reproducible
builds" issue, and prefer a s
Well a command line switch is useless imho.
Suppose I have a multi-module reactor and one module uses version A of
plugin X and another module uses version B.
Now A was built against Maven 3.3.3 and the classpath was "fixed" with
tweaks and hacks to ensure the transitive dependencies worked out c
I find the prerequisites idea very intriguing. However, does that mean
it's automatic behavior and no way for user to control it?
(For user to control it, in addition to normal docs, I expect release notes
describing the issue (e.g. links to JIRA) and how to enable/disable the new
breaking feature
Rather than a CLI switch can we use the plugin prerequisites to control the
behaviour?
If prerequisites is < 3.0 or >= 3.4 then apply the fix otherwise replicate
the bug.
That way if the plugin was built and tested against 2.x (which presumably
doesn't have the bug) or against 3.4+ you get the. O
Am 2016-12-26 um 16:48 schrieb Tibor Digana:
No objections to
error( "Errors: " ),
failure( "Failures: "
What about having "Flakes: "?
That's consistent. I change my local staging area.
On Mon, Dec 26, 2016 at 2:14 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n5890019...@n5.nabble.
No objections to
error( "Errors: " ),
failure( "Failures: "
What about having "Flakes: "?
On Mon, Dec 26, 2016 at 2:14 PM, Michael Osipov-2 [via Maven] <
ml-node+s40175n5890019...@n5.nabble.com> wrote:
> Am 2016-12-26 um 14:02 schrieb Hervé BOUTEMY:
> > I'm ok with "flacky tests" vs "flack
Am 12/26/16 um 11:36 schrieb Robert Scholte:
> This is becoming a bug versus feature discussion.
It shouldn't.
> Up until now you've made
> changes which might change the resolution because you've marked them as a
> bug which must be fixed. However, what is 'the truth': the documentation
>
Am 2016-12-26 um 14:02 schrieb Hervé BOUTEMY:
I'm ok with "flacky tests" vs "flacked tests"
I'm ok that "tests in error" is not the best description, but "erroneous
tests" does not convince me...
If I look at how JUnit itself report issues, which is IMHO the origin of this
description, JUnit 3 m
I'm ok with "flacky tests" vs "flacked tests"
I'm ok that "tests in error" is not the best description, but "erroneous
tests" does not convince me...
If I look at how JUnit itself report issues, which is IMHO the origin of this
description, JUnit 3 made the distinction between "failures" and "er
remember Aether was written to:
1. improve resolution by extracting code, to ease future evolution
2. keep Maven 3 not break what was working with Maven 2
Keeping the right balance between cleaner resolution management and eventually
"bug for bug" compatibility was not so easy to do: I suppose tha
This is becoming a bug versus feature discussion. Up until now you've made
changes which might change the resolution because you've marked them as a
bug which must be fixed. However, what is 'the truth': the documentation
or the code? The answer is: in the end it is the code. And if you want
17 matches
Mail list logo
