Re: MNG-5868 for 3.5.0

[Anders Hammar]

Didn't we agree on v3.5.0 to be a drop-in replacement for v3.3.9? IMO
fixing MNG-5868 wouldn't fit in that.

I'm sorry to say, but I think we're heading back to where we were before
the reset.

/Anders

On Wed, Feb 1, 2017 at 8:42 AM, Hervé BOUTEMY  wrote:

> https://issues.apache.org/jira/browse/MNG-5868
> Adding serval times the same artifact via MavenProjectHelper
> (attachArtifact)
> does not produce a failure
>
> by reading the Jira entry, I can't understand what has been done and what
> is
> the effective impact: IIUC, Maven core becomes more picky, expectedly to
> help
> users discover unexpected situations by failing instead of silently doing
> something that seems odd. But how many plugins are affected? What will
> users
> get as a result? Are there some plugins versions that are to be upgraded?
>
> not clear from the Jira issue
>
> I need more explanations in Jira before saying if this is the right thing
> to
> do, whatever Maven version we are targetting
>
> Regards,
>
> Hervé
>
> Le mercredi 1 février 2017, 00:05:01 CET Christian Schulte a écrit :
> > Hi,
> >
> > I'd like to make MNG-5868 FIX-3.5.0. There have been plugin issues
> > solved by this. I know Karl-Heinz worked on some of those plugin issues.
> > If this does not get released, those plugin issues may need to be
> > re-opened. Anyone second FIX-3.5.0?
> >
> > Regards,
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5868 for 3.5.0

[Hervé BOUTEMY]

https://issues.apache.org/jira/browse/MNG-5868
Adding serval times the same artifact via MavenProjectHelper (attachArtifact) 
does not produce a failure

by reading the Jira entry, I can't understand what has been done and what is 
the effective impact: IIUC, Maven core becomes more picky, expectedly to help 
users discover unexpected situations by failing instead of silently doing 
something that seems odd. But how many plugins are affected? What will users 
get as a result? Are there some plugins versions that are to be upgraded?

not clear from the Jira issue

I need more explanations in Jira before saying if this is the right thing to 
do, whatever Maven version we are targetting

Regards,

Hervé

Le mercredi 1 février 2017, 00:05:01 CET Christian Schulte a écrit :
> Hi,
> 
> I'd like to make MNG-5868 FIX-3.5.0. There have been plugin issues
> solved by this. I know Karl-Heinz worked on some of those plugin issues.
> If this does not get released, those plugin issues may need to be
> re-opened. Anyone second FIX-3.5.0?
> 
> Regards,



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5981 for 3.5.0?

[Hervé BOUTEMY]

seconded

Regards,

Hervé

Le mercredi 1 février 2017, 05:39:16 CET Christian Schulte a écrit :
> Hi,
> 
> I'd also like to make MNG-5981 part of 3.5.0. It is just an upgrade to a
> dependency needed to fix a bug. Anyone second that?
> 
> Regards,



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MNG-5981 for 3.5.0?

[Christian Schulte]

Hi,

I'd also like to make MNG-5981 part of 3.5.0. It is just an upgrade to a
dependency needed to fix a bug. Anyone second that?

Regards,
-- 
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #100: Spelling non-API change

[jsoref]

Github user jsoref commented on the issue:

https://github.com/apache/maven/pull/100
  
done


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MNG-5868 for 3.5.0

[Christian Schulte]

Hi,

I'd like to make MNG-5868 FIX-3.5.0. There have been plugin issues
solved by this. I know Karl-Heinz worked on some of those plugin issues.
If this does not get released, those plugin issues may need to be
re-opened. Anyone second FIX-3.5.0?

Regards,
-- 
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Christian Schulte]

Am 01/31/17 um 23:23 schrieb Christian Schulte:
> Before the reset I did A. On the branch I did B. Do not ask me why I did
> it differently this time. Maybe because I reviewed the versions in more
> detail this time. While at it: I somehow get the feeling that those ITs
> really should be unit tests. I added the exact same tests to the core as
> unit tests. The unit tests is what gets tagged. We maybe also should
> apply an RTC style process when it comes to changing unit tests as well.
> We never tag the core ITs or create release versions of them. That may
> be the root cause for having to discuss things like this. If someone
> adds an IT with a range of [3.2.2,) and that IT will not be supported by
> 3.2.2, we never notice it. Means we must be doing something wrong.
> 

I mean: You write an IT to test things you cannot test with a unit test
because you are not testing a single unit/module/component but the
assembled application. Most of our ITs could be made unit tests without
us lossing anything.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Christian Schulte]

Before the reset I did A. On the branch I did B. Do not ask me why I did
it differently this time. Maybe because I reviewed the versions in more
detail this time. While at it: I somehow get the feeling that those ITs
really should be unit tests. I added the exact same tests to the core as
unit tests. The unit tests is what gets tagged. We maybe also should
apply an RTC style process when it comes to changing unit tests as well.
We never tag the core ITs or create release versions of them. That may
be the root cause for having to discuss things like this. If someone
adds an IT with a range of [3.2.2,) and that IT will not be supported by
3.2.2, we never notice it. Means we must be doing something wrong.

Am 01/31/17 um 22:25 schrieb Stephen Connolly:
> Ok so, we'll need to knock this one out and see if there is a consensus.
> 
> My position is that I only have a slight preference for A over B and I
> cannot fully articulate why.
> 
> Michael, do you feel you can present a reasoned argument in favour of A and
> we'll let one of the B proponents present their case and see if either side
> is "converted" to yield a consensus.
> 
> While we are at it, are there any in the C or D camp? Silence assumes we
> are all either A or B
> 
> We'll probably need to vote on this once we think we have a consensus then
> :-(
> 
> - Stephen
> On Tue 31 Jan 2017 at 20:29, Michael Osipov  wrote:
> 
>> Am 2017-01-31 um 20:23 schrieb Stephen Connolly:
>>> Looking like a consensus on B.
>>
>> I am actually in favor of A. How do you want to assure with B that the
>> will be properly handled for current master as you fixed the test for
>> released versions?
>>
>> Michael
>>
>>> On Tue 31 Jan 2017 at 12:51, Anders Hammar  wrote:
>>>
 I favor B.

 /Anders

 On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
 stephen.alan.conno...@gmail.com> wrote:

> We have kind of established a consensus on how to handle the case where
 we
> want to change the specification of how Maven works going forward.
> Specifically, if we decide that the old behaviour of Maven is no longer
> going to be the new behaviour of Maven our procedure in the integration
> tests is as follows:
>
> 1. Mark the existing tests that are affected as range limited where the
> upper bound is the below the version of Maven that the change in
 behaviour
> will land in
> 2. Create tests of the new behaviour (probably copied from the original
> tests but with the assertions modified and using a range limited where
 the
> lower bound is the version of Maven that the change in behaviour will
 land
> in.
>
> An example of such a change is
> https://github.com/apache/maven-integration-testing/commit/
> c4365abe20b58b2cbc174de812e43c7741dc10e1
>
> We now have a more complex case to try and decide how to handle, the
> current attempt to resolve is this diff:
> https://github.com/apache/maven-integration-testing/
> compare/master...MNG-2199
>
> However I am somewhat uncomfortable with how that proposed fix to the
> integration tests works.
>
> So firstly, Christian has identified that the original tests added were
 not
> correctly detecting the failure.
>
> We have a situation therefore where the integration tests have been
 giving
> false positive results against Maven 3.2.2+
>
> Therefore, my view is that we should *fix the broken tests* because a
 false
> positive or a false negative is a bug in the tests.
>
> This would mean that the tests would no longer pass when run against
> 3.2.2-3.3.9, instead they would report the bugs in those versions that
>> we
> shipped due to the bugs in the integration tests.
>
> If we had a need to release - say security fixes - for those lines, we
> would then have to do one of:
> * ACK the continued failing tests;
> * Run with the integration tests forked from the point in time where
>> the
> previous release on the line was cut; OR
> * Back-port the fixes to those lines
>
> (assuming we are supporting those lines for security fixes)
>
> I am fine with any of those three options as those are known issues
>> that
 we
> should really have JIRAs for and be documenting in the release notes,
>> and
> any of those three options would be forcing us to acknowledge the bugs.
>
> An alternative is to say "those bugs were part of the specification of
> Maven and we have changed the specification of Maven again" which is
>> the
> approach that the current MNG-2199 branch takes.
>
> I am not happy with that approach as it is an implicit approval of that
> type of usage for the broken versions of Maven. Users could
>> legitimately
> start filing feature requests to "restore" the previous behaviour
>> because
> "it was part of 

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

[Tibor17]

Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/114
  
@Fuud
We had an internal collision and I tried to recover from this and reverted 
11 commits and now trying to fix them and add the last jira fix and then cut 
the release version. Please try to be patient. We want to continue on this 
project.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5961 for 3.5.0 ?

[Arnaud Héritier]

thx hervé

On Tue, Jan 31, 2017 at 10:34 PM,  wrote:

> seconded for 3.5.0
> yes, basic bug fix
>
> Regards,
>
> Hervé
>
> - Mail original -
> De: "Arnaud Héritier" 
> À: "Maven Developers List" 
> Envoyé: Mardi 31 Janvier 2017 21:44:09
> Objet: MNG-5961 for 3.5.0 ?
>
> Hi,
>
> This is a so easy one I fixed a long time ago in master :
>
> https://issues.apache.org/jira/browse/MNG-5961
>
> I originally sent it as PR on GitHub and now I created a branch MNG-5961 in
> our repo
>
> WDYT?
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: MNG-5961 for 3.5.0 ?

[herve . boutemy]

seconded for 3.5.0
yes, basic bug fix

Regards,

Hervé

- Mail original -
De: "Arnaud Héritier" 
À: "Maven Developers List" 
Envoyé: Mardi 31 Janvier 2017 21:44:09
Objet: MNG-5961 for 3.5.0 ?

Hi,

This is a so easy one I fixed a long time ago in master :

https://issues.apache.org/jira/browse/MNG-5961

I originally sent it as PR on GitHub and now I created a branch MNG-5961 in
our repo

WDYT?

-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[aheritier]

Github user aheritier commented on the issue:

https://github.com/apache/maven/pull/104
  
Cool @michael-o it is exactly what I did
the build is in progress
https://builds.apache.org/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-5961/



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Stephen Connolly]

Ok so, we'll need to knock this one out and see if there is a consensus.

My position is that I only have a slight preference for A over B and I
cannot fully articulate why.

Michael, do you feel you can present a reasoned argument in favour of A and
we'll let one of the B proponents present their case and see if either side
is "converted" to yield a consensus.

While we are at it, are there any in the C or D camp? Silence assumes we
are all either A or B

We'll probably need to vote on this once we think we have a consensus then
:-(

- Stephen
On Tue 31 Jan 2017 at 20:29, Michael Osipov  wrote:

> Am 2017-01-31 um 20:23 schrieb Stephen Connolly:
> > Looking like a consensus on B.
>
> I am actually in favor of A. How do you want to assure with B that the
> will be properly handled for current master as you fixed the test for
> released versions?
>
> Michael
>
> > On Tue 31 Jan 2017 at 12:51, Anders Hammar  wrote:
> >
> >> I favor B.
> >>
> >> /Anders
> >>
> >> On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>> We have kind of established a consensus on how to handle the case where
> >> we
> >>> want to change the specification of how Maven works going forward.
> >>> Specifically, if we decide that the old behaviour of Maven is no longer
> >>> going to be the new behaviour of Maven our procedure in the integration
> >>> tests is as follows:
> >>>
> >>> 1. Mark the existing tests that are affected as range limited where the
> >>> upper bound is the below the version of Maven that the change in
> >> behaviour
> >>> will land in
> >>> 2. Create tests of the new behaviour (probably copied from the original
> >>> tests but with the assertions modified and using a range limited where
> >> the
> >>> lower bound is the version of Maven that the change in behaviour will
> >> land
> >>> in.
> >>>
> >>> An example of such a change is
> >>> https://github.com/apache/maven-integration-testing/commit/
> >>> c4365abe20b58b2cbc174de812e43c7741dc10e1
> >>>
> >>> We now have a more complex case to try and decide how to handle, the
> >>> current attempt to resolve is this diff:
> >>> https://github.com/apache/maven-integration-testing/
> >>> compare/master...MNG-2199
> >>>
> >>> However I am somewhat uncomfortable with how that proposed fix to the
> >>> integration tests works.
> >>>
> >>> So firstly, Christian has identified that the original tests added were
> >> not
> >>> correctly detecting the failure.
> >>>
> >>> We have a situation therefore where the integration tests have been
> >> giving
> >>> false positive results against Maven 3.2.2+
> >>>
> >>> Therefore, my view is that we should *fix the broken tests* because a
> >> false
> >>> positive or a false negative is a bug in the tests.
> >>>
> >>> This would mean that the tests would no longer pass when run against
> >>> 3.2.2-3.3.9, instead they would report the bugs in those versions that
> we
> >>> shipped due to the bugs in the integration tests.
> >>>
> >>> If we had a need to release - say security fixes - for those lines, we
> >>> would then have to do one of:
> >>> * ACK the continued failing tests;
> >>> * Run with the integration tests forked from the point in time where
> the
> >>> previous release on the line was cut; OR
> >>> * Back-port the fixes to those lines
> >>>
> >>> (assuming we are supporting those lines for security fixes)
> >>>
> >>> I am fine with any of those three options as those are known issues
> that
> >> we
> >>> should really have JIRAs for and be documenting in the release notes,
> and
> >>> any of those three options would be forcing us to acknowledge the bugs.
> >>>
> >>> An alternative is to say "those bugs were part of the specification of
> >>> Maven and we have changed the specification of Maven again" which is
> the
> >>> approach that the current MNG-2199 branch takes.
> >>>
> >>> I am not happy with that approach as it is an implicit approval of that
> >>> type of usage for the broken versions of Maven. Users could
> legitimately
> >>> start filing feature requests to "restore" the previous behaviour
> because
> >>> "it was part of the specification"... fine we can probably bat those
> >>> requests away, but is it helping us with code archeology?
> >>>
> >>> So, what do we want to do with the case of a test being identified as
> >>> having either a false positive or a false negative against an already
> >>> released version of Maven?
> >>>
> >>> A. Fix the test and then the test will fail against already released
> >>> versions of Maven
> >>> B. Fix the test, but exclude the broken versions of Maven from the
> range
> >>> with a comment explaining why
> >>> C. Clone the test, leaving the broken test for the old versions of
> Maven
> >>> and the new test for new versions of Maven
> >>> D. Something else
> >>>
> >>> I personally favour A or B (with a slight leaning towards A) and I
> really
> >>> do not like C for the case of the 

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/104
  
Do this:

git checkout master
git checkout -b MNG-5961
git cherry-pick 
git push

Wait for the Jenkins build to finish, get approval

git checkout master
git merge MNG-5961

Delete branch locally and remote.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

MNG-5961 for 3.5.0 ?

[Arnaud Héritier]

Hi,

This is a so easy one I fixed a long time ago in master :

https://issues.apache.org/jira/browse/MNG-5961

I originally sent it as PR on GitHub and now I created a branch MNG-5961 in
our repo

WDYT?

-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[aheritier]

Github user aheritier commented on the issue:

https://github.com/apache/maven/pull/104
  
@michael-o we don't have a CI validation here, thus I have to open a real 
branch on ASF side. Right ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Michael Osipov]

Am 2017-01-31 um 20:23 schrieb Stephen Connolly:

Looking like a consensus on B.


I am actually in favor of A. How do you want to assure with B that the 
will be properly handled for current master as you fixed the test for 
released versions?


Michael


On Tue 31 Jan 2017 at 12:51, Anders Hammar  wrote:


I favor B.

/Anders

On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


We have kind of established a consensus on how to handle the case where

we

want to change the specification of how Maven works going forward.
Specifically, if we decide that the old behaviour of Maven is no longer
going to be the new behaviour of Maven our procedure in the integration
tests is as follows:

1. Mark the existing tests that are affected as range limited where the
upper bound is the below the version of Maven that the change in

behaviour

will land in
2. Create tests of the new behaviour (probably copied from the original
tests but with the assertions modified and using a range limited where

the

lower bound is the version of Maven that the change in behaviour will

land

in.

An example of such a change is
https://github.com/apache/maven-integration-testing/commit/
c4365abe20b58b2cbc174de812e43c7741dc10e1

We now have a more complex case to try and decide how to handle, the
current attempt to resolve is this diff:
https://github.com/apache/maven-integration-testing/
compare/master...MNG-2199

However I am somewhat uncomfortable with how that proposed fix to the
integration tests works.

So firstly, Christian has identified that the original tests added were

not

correctly detecting the failure.

We have a situation therefore where the integration tests have been

giving

false positive results against Maven 3.2.2+

Therefore, my view is that we should *fix the broken tests* because a

false

positive or a false negative is a bug in the tests.

This would mean that the tests would no longer pass when run against
3.2.2-3.3.9, instead they would report the bugs in those versions that we
shipped due to the bugs in the integration tests.

If we had a need to release - say security fixes - for those lines, we
would then have to do one of:
* ACK the continued failing tests;
* Run with the integration tests forked from the point in time where the
previous release on the line was cut; OR
* Back-port the fixes to those lines

(assuming we are supporting those lines for security fixes)

I am fine with any of those three options as those are known issues that

we

should really have JIRAs for and be documenting in the release notes, and
any of those three options would be forcing us to acknowledge the bugs.

An alternative is to say "those bugs were part of the specification of
Maven and we have changed the specification of Maven again" which is the
approach that the current MNG-2199 branch takes.

I am not happy with that approach as it is an implicit approval of that
type of usage for the broken versions of Maven. Users could legitimately
start filing feature requests to "restore" the previous behaviour because
"it was part of the specification"... fine we can probably bat those
requests away, but is it helping us with code archeology?

So, what do we want to do with the case of a test being identified as
having either a false positive or a false negative against an already
released version of Maven?

A. Fix the test and then the test will fail against already released
versions of Maven
B. Fix the test, but exclude the broken versions of Maven from the range
with a comment explaining why
C. Clone the test, leaving the broken test for the old versions of Maven
and the new test for new versions of Maven
D. Something else

I personally favour A or B (with a slight leaning towards A) and I really
do not like C for the case of the false-positive / false-negative tests

If an obvious consensus does not emerge I may have to call a vote, you

have

been warned!

-Stephen






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/104
  
I am fine with this PR. You have to raise the issue on the dev mailing list 
to have at least someone who seconds it. If someone does, after your branch 
passes all tests, go ahead and merge into master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[aheritier]

Github user aheritier commented on the issue:

https://github.com/apache/maven/pull/104
  
I think @stephenc will tell me to push a branch on ASF side :-)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #104: [MNG-5961] Fix the SLF4J logger factory implementation use...

[aheritier]

Github user aheritier commented on the issue:

https://github.com/apache/maven/pull/104
  
cc @michael-o @stephenc 
https://issues.apache.org/jira/browse/MNG-5961


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Progress check for 3.5.0

[Stephen Connolly]

On Tue 31 Jan 2017 at 19:29, Michael Osipov  wrote:

> Am 2017-01-22 um 11:22 schrieb Stephen Connolly:
> > I'm currently waiting on Hervé to start the 1.0.3 release of resolver.
> >
> > Once we get that I'm going to start cutting RCs (I plan 2 a week apart)
> >
> > Once we have a stable RC I will cut the release, and start a clock
> towards
> > 3.5.1 (6 weeks approx)
>
> Two more issue for FIX-3.5.0:
> MNG-6136 Upgrade Maven Wagon to 2.12
> MNG-6137 Clean up duplicate dependencies caused by incomplete Wagon HTTP
> Provider exclusions
>
> both are trivial POM changes, branches pass all tests on Jenkins.
>

Ok
Go for it

>
> Who seconds?
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Progress check for 3.5.0

[Michael Osipov]

Am 2017-01-22 um 11:22 schrieb Stephen Connolly:

I'm currently waiting on Hervé to start the 1.0.3 release of resolver.

Once we get that I'm going to start cutting RCs (I plan 2 a week apart)

Once we have a stable RC I will cut the release, and start a clock towards
3.5.1 (6 weeks approx)


Two more issue for FIX-3.5.0:
MNG-6136 Upgrade Maven Wagon to 2.12
MNG-6137 Clean up duplicate dependencies caused by incomplete Wagon HTTP 
Provider exclusions


both are trivial POM changes, branches pass all tests on Jenkins.

Who seconds?

Michael



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Progress check for 3.5.0

[Michael Osipov]

Am 2017-01-31 um 03:37 schrieb Hervé BOUTEMY:

Le dimanche 29 janvier 2017, 22:11:16 CET Michael Osipov a écrit :

Am 2017-01-29 um 20:47 schrieb Hervé BOUTEMY:

resolver integration is ready in MNG-6110 branch: please review
I'll merge in 48h


I believe that bfc35976e2883bb922ef6e1787917a28215532b7 and
37c936d0ff778967dd4d9f68edfd60c3bea76e17 should be one commit because
they are highly coupled.

yes, they are coupled, but I find it useful to keep 2 visible steps: using the
new component is easy, renaming module to match the new naming is more complex


That's fine as long as both commit links are visible in issue log.


9d94541f7deaf784f3bc2157c1a3c149907538b8 should be merged seperately
because it reflects two distinct changes of the dependency overview, not
necessarily Resolver change.

it is separate: what to you want me to do? A separate branch? Isn't it too
extreme?


No need for a seperate branch, but the update of the drawing included 
SLF4J provider also which is completely unrelated to the resolver 
change. Diametral changes shouldn't simply slip in.





I prepared MNG-5878 branch for "add support for module name != artifactId
in every calculated URLs (project, SCM, site): special project.directory
property"
I'd like to have seconds to merge that branch into 3.5.0


Left come comments.

thanks, done (when agreeing, or discussing when not immediately agreeing :) )


Still working on...


In general, both branches are fine.

on MNG-5878, in addition to the review that you did (thank you), I need an
explicit second to merge into 3.5.0, since this issue was not agreed yet (and
I don't want to fool anybody)


I am secoding both issues for FIX-3.5.0.


Le dimanche 22 janvier 2017, 10:22:26 CET Stephen Connolly a écrit :

I'm currently waiting on Hervé to start the 1.0.3 release of resolver.

Once we get that I'm going to start cutting RCs (I plan 2 a week apart)

Once we have a stable RC I will cut the release, and start a clock
towards
3.5.1 (6 weeks approx)

If you miss the boat, you can catch the next one, but we need to get this
project into a rhythm.

-Stephen

P.S. Hervé if you don't have the time to release resolver this week I let
me know and I'll pick it up


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Stephen Connolly]

Looking like a consensus on B.

Let's lazy this one.

On Tue 31 Jan 2017 at 12:51, Anders Hammar  wrote:

> I favor B.
>
> /Anders
>
> On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > We have kind of established a consensus on how to handle the case where
> we
> > want to change the specification of how Maven works going forward.
> > Specifically, if we decide that the old behaviour of Maven is no longer
> > going to be the new behaviour of Maven our procedure in the integration
> > tests is as follows:
> >
> > 1. Mark the existing tests that are affected as range limited where the
> > upper bound is the below the version of Maven that the change in
> behaviour
> > will land in
> > 2. Create tests of the new behaviour (probably copied from the original
> > tests but with the assertions modified and using a range limited where
> the
> > lower bound is the version of Maven that the change in behaviour will
> land
> > in.
> >
> > An example of such a change is
> > https://github.com/apache/maven-integration-testing/commit/
> > c4365abe20b58b2cbc174de812e43c7741dc10e1
> >
> > We now have a more complex case to try and decide how to handle, the
> > current attempt to resolve is this diff:
> > https://github.com/apache/maven-integration-testing/
> > compare/master...MNG-2199
> >
> > However I am somewhat uncomfortable with how that proposed fix to the
> > integration tests works.
> >
> > So firstly, Christian has identified that the original tests added were
> not
> > correctly detecting the failure.
> >
> > We have a situation therefore where the integration tests have been
> giving
> > false positive results against Maven 3.2.2+
> >
> > Therefore, my view is that we should *fix the broken tests* because a
> false
> > positive or a false negative is a bug in the tests.
> >
> > This would mean that the tests would no longer pass when run against
> > 3.2.2-3.3.9, instead they would report the bugs in those versions that we
> > shipped due to the bugs in the integration tests.
> >
> > If we had a need to release - say security fixes - for those lines, we
> > would then have to do one of:
> > * ACK the continued failing tests;
> > * Run with the integration tests forked from the point in time where the
> > previous release on the line was cut; OR
> > * Back-port the fixes to those lines
> >
> > (assuming we are supporting those lines for security fixes)
> >
> > I am fine with any of those three options as those are known issues that
> we
> > should really have JIRAs for and be documenting in the release notes, and
> > any of those three options would be forcing us to acknowledge the bugs.
> >
> > An alternative is to say "those bugs were part of the specification of
> > Maven and we have changed the specification of Maven again" which is the
> > approach that the current MNG-2199 branch takes.
> >
> > I am not happy with that approach as it is an implicit approval of that
> > type of usage for the broken versions of Maven. Users could legitimately
> > start filing feature requests to "restore" the previous behaviour because
> > "it was part of the specification"... fine we can probably bat those
> > requests away, but is it helping us with code archeology?
> >
> > So, what do we want to do with the case of a test being identified as
> > having either a false positive or a false negative against an already
> > released version of Maven?
> >
> > A. Fix the test and then the test will fail against already released
> > versions of Maven
> > B. Fix the test, but exclude the broken versions of Maven from the range
> > with a comment explaining why
> > C. Clone the test, leaving the broken test for the old versions of Maven
> > and the new test for new versions of Maven
> > D. Something else
> >
> > I personally favour A or B (with a slight leaning towards A) and I really
> > do not like C for the case of the false-positive / false-negative tests
> >
> > If an obvious consensus does not emerge I may have to call a vote, you
> have
> > been warned!
> >
> > -Stephen
> >
>
-- 
Sent from my phone

[GitHub] maven-surefire issue #114: Parallel runner should not drop away runners that...

[Fuud]

Github user Fuud commented on the issue:

https://github.com/apache/maven-surefire/pull/114
  
Any updates?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven issue #100: Spelling non-API change

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven/pull/100
  
Can you rebase your changes and squash into one commit? I want to pull them 
in with 
[MNG-6146](https://issues.apache.org/jira/browse/MNG-6146?src=confmacro).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-indexer issue #12: resolve performance loss due to lucene 4.8.1 - upgr...

[michael-o]

Github user michael-o commented on the issue:

https://github.com/apache/maven-indexer/pull/12
  
Looking at your changes, they are not really related. They all require 
appropriate JIRA issues and seperate PRs.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Anders Hammar]

I favor B.

/Anders

On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We have kind of established a consensus on how to handle the case where we
> want to change the specification of how Maven works going forward.
> Specifically, if we decide that the old behaviour of Maven is no longer
> going to be the new behaviour of Maven our procedure in the integration
> tests is as follows:
>
> 1. Mark the existing tests that are affected as range limited where the
> upper bound is the below the version of Maven that the change in behaviour
> will land in
> 2. Create tests of the new behaviour (probably copied from the original
> tests but with the assertions modified and using a range limited where the
> lower bound is the version of Maven that the change in behaviour will land
> in.
>
> An example of such a change is
> https://github.com/apache/maven-integration-testing/commit/
> c4365abe20b58b2cbc174de812e43c7741dc10e1
>
> We now have a more complex case to try and decide how to handle, the
> current attempt to resolve is this diff:
> https://github.com/apache/maven-integration-testing/
> compare/master...MNG-2199
>
> However I am somewhat uncomfortable with how that proposed fix to the
> integration tests works.
>
> So firstly, Christian has identified that the original tests added were not
> correctly detecting the failure.
>
> We have a situation therefore where the integration tests have been giving
> false positive results against Maven 3.2.2+
>
> Therefore, my view is that we should *fix the broken tests* because a false
> positive or a false negative is a bug in the tests.
>
> This would mean that the tests would no longer pass when run against
> 3.2.2-3.3.9, instead they would report the bugs in those versions that we
> shipped due to the bugs in the integration tests.
>
> If we had a need to release - say security fixes - for those lines, we
> would then have to do one of:
> * ACK the continued failing tests;
> * Run with the integration tests forked from the point in time where the
> previous release on the line was cut; OR
> * Back-port the fixes to those lines
>
> (assuming we are supporting those lines for security fixes)
>
> I am fine with any of those three options as those are known issues that we
> should really have JIRAs for and be documenting in the release notes, and
> any of those three options would be forcing us to acknowledge the bugs.
>
> An alternative is to say "those bugs were part of the specification of
> Maven and we have changed the specification of Maven again" which is the
> approach that the current MNG-2199 branch takes.
>
> I am not happy with that approach as it is an implicit approval of that
> type of usage for the broken versions of Maven. Users could legitimately
> start filing feature requests to "restore" the previous behaviour because
> "it was part of the specification"... fine we can probably bat those
> requests away, but is it helping us with code archeology?
>
> So, what do we want to do with the case of a test being identified as
> having either a false positive or a false negative against an already
> released version of Maven?
>
> A. Fix the test and then the test will fail against already released
> versions of Maven
> B. Fix the test, but exclude the broken versions of Maven from the range
> with a comment explaining why
> C. Clone the test, leaving the broken test for the old versions of Maven
> and the new test for new versions of Maven
> D. Something else
>
> I personally favour A or B (with a slight leaning towards A) and I really
> do not like C for the case of the false-positive / false-negative tests
>
> If an obvious consensus does not emerge I may have to call a vote, you have
> been warned!
>
> -Stephen
>

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Arnaud Héritier]

I would prefer B

On Tue, Jan 31, 2017 at 1:34 PM, Igor Fedorenko  wrote:

> > B. Fix the test, but exclude the broken versions of Maven from the range
> with a comment explaining why
>
> I sometimes rerun integration tests against released versions of Maven
> to validate the tests are still working and I know other developers who
> do that too. Having failures would just mean tests are broken and can be
> ignored IMHO.
>
> --
> Regards,
> Igor
>
> On Tue, Jan 31, 2017, at 06:42 AM, Stephen Connolly wrote:
> > We have kind of established a consensus on how to handle the case where
> > we
> > want to change the specification of how Maven works going forward.
> > Specifically, if we decide that the old behaviour of Maven is no longer
> > going to be the new behaviour of Maven our procedure in the integration
> > tests is as follows:
> >
> > 1. Mark the existing tests that are affected as range limited where the
> > upper bound is the below the version of Maven that the change in
> > behaviour
> > will land in
> > 2. Create tests of the new behaviour (probably copied from the original
> > tests but with the assertions modified and using a range limited where
> > the
> > lower bound is the version of Maven that the change in behaviour will
> > land
> > in.
> >
> > An example of such a change is
> > https://github.com/apache/maven-integration-testing/commit/
> c4365abe20b58b2cbc174de812e43c7741dc10e1
> >
> > We now have a more complex case to try and decide how to handle, the
> > current attempt to resolve is this diff:
> > https://github.com/apache/maven-integration-testing/
> compare/master...MNG-2199
> >
> > However I am somewhat uncomfortable with how that proposed fix to the
> > integration tests works.
> >
> > So firstly, Christian has identified that the original tests added were
> > not
> > correctly detecting the failure.
> >
> > We have a situation therefore where the integration tests have been
> > giving
> > false positive results against Maven 3.2.2+
> >
> > Therefore, my view is that we should *fix the broken tests* because a
> > false
> > positive or a false negative is a bug in the tests.
> >
> > This would mean that the tests would no longer pass when run against
> > 3.2.2-3.3.9, instead they would report the bugs in those versions that we
> > shipped due to the bugs in the integration tests.
> >
> > If we had a need to release - say security fixes - for those lines, we
> > would then have to do one of:
> > * ACK the continued failing tests;
> > * Run with the integration tests forked from the point in time where the
> > previous release on the line was cut; OR
> > * Back-port the fixes to those lines
> >
> > (assuming we are supporting those lines for security fixes)
> >
> > I am fine with any of those three options as those are known issues that
> > we
> > should really have JIRAs for and be documenting in the release notes, and
> > any of those three options would be forcing us to acknowledge the bugs.
> >
> > An alternative is to say "those bugs were part of the specification of
> > Maven and we have changed the specification of Maven again" which is the
> > approach that the current MNG-2199 branch takes.
> >
> > I am not happy with that approach as it is an implicit approval of that
> > type of usage for the broken versions of Maven. Users could legitimately
> > start filing feature requests to "restore" the previous behaviour because
> > "it was part of the specification"... fine we can probably bat those
> > requests away, but is it helping us with code archeology?
> >
> > So, what do we want to do with the case of a test being identified as
> > having either a false positive or a false negative against an already
> > released version of Maven?
> >
> > A. Fix the test and then the test will fail against already released
> > versions of Maven
> > B. Fix the test, but exclude the broken versions of Maven from the range
> > with a comment explaining why
> > C. Clone the test, leaving the broken test for the old versions of Maven
> > and the new test for new versions of Maven
> > D. Something else
> >
> > I personally favour A or B (with a slight leaning towards A) and I really
> > do not like C for the case of the false-positive / false-negative tests
> >
> > If an obvious consensus does not emerge I may have to call a vote, you
> > have
> > been warned!
> >
> > -Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [DISCUSS] How do we want to handle false positives in the integration tests

[Igor Fedorenko]

> B. Fix the test, but exclude the broken versions of Maven from the range
with a comment explaining why

I sometimes rerun integration tests against released versions of Maven
to validate the tests are still working and I know other developers who
do that too. Having failures would just mean tests are broken and can be
ignored IMHO.

-- 
Regards,
Igor

On Tue, Jan 31, 2017, at 06:42 AM, Stephen Connolly wrote:
> We have kind of established a consensus on how to handle the case where
> we
> want to change the specification of how Maven works going forward.
> Specifically, if we decide that the old behaviour of Maven is no longer
> going to be the new behaviour of Maven our procedure in the integration
> tests is as follows:
> 
> 1. Mark the existing tests that are affected as range limited where the
> upper bound is the below the version of Maven that the change in
> behaviour
> will land in
> 2. Create tests of the new behaviour (probably copied from the original
> tests but with the assertions modified and using a range limited where
> the
> lower bound is the version of Maven that the change in behaviour will
> land
> in.
> 
> An example of such a change is
> https://github.com/apache/maven-integration-testing/commit/c4365abe20b58b2cbc174de812e43c7741dc10e1
> 
> We now have a more complex case to try and decide how to handle, the
> current attempt to resolve is this diff:
> https://github.com/apache/maven-integration-testing/compare/master...MNG-2199
> 
> However I am somewhat uncomfortable with how that proposed fix to the
> integration tests works.
> 
> So firstly, Christian has identified that the original tests added were
> not
> correctly detecting the failure.
> 
> We have a situation therefore where the integration tests have been
> giving
> false positive results against Maven 3.2.2+
> 
> Therefore, my view is that we should *fix the broken tests* because a
> false
> positive or a false negative is a bug in the tests.
> 
> This would mean that the tests would no longer pass when run against
> 3.2.2-3.3.9, instead they would report the bugs in those versions that we
> shipped due to the bugs in the integration tests.
> 
> If we had a need to release - say security fixes - for those lines, we
> would then have to do one of:
> * ACK the continued failing tests;
> * Run with the integration tests forked from the point in time where the
> previous release on the line was cut; OR
> * Back-port the fixes to those lines
> 
> (assuming we are supporting those lines for security fixes)
> 
> I am fine with any of those three options as those are known issues that
> we
> should really have JIRAs for and be documenting in the release notes, and
> any of those three options would be forcing us to acknowledge the bugs.
> 
> An alternative is to say "those bugs were part of the specification of
> Maven and we have changed the specification of Maven again" which is the
> approach that the current MNG-2199 branch takes.
> 
> I am not happy with that approach as it is an implicit approval of that
> type of usage for the broken versions of Maven. Users could legitimately
> start filing feature requests to "restore" the previous behaviour because
> "it was part of the specification"... fine we can probably bat those
> requests away, but is it helping us with code archeology?
> 
> So, what do we want to do with the case of a test being identified as
> having either a false positive or a false negative against an already
> released version of Maven?
> 
> A. Fix the test and then the test will fail against already released
> versions of Maven
> B. Fix the test, but exclude the broken versions of Maven from the range
> with a comment explaining why
> C. Clone the test, leaving the broken test for the old versions of Maven
> and the new test for new versions of Maven
> D. Something else
> 
> I personally favour A or B (with a slight leaning towards A) and I really
> do not like C for the case of the false-positive / false-negative tests
> 
> If an obvious consensus does not emerge I may have to call a vote, you
> have
> been warned!
> 
> -Stephen

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[DISCUSS] How do we want to handle false positives in the integration tests

[Stephen Connolly]

We have kind of established a consensus on how to handle the case where we
want to change the specification of how Maven works going forward.
Specifically, if we decide that the old behaviour of Maven is no longer
going to be the new behaviour of Maven our procedure in the integration
tests is as follows:

1. Mark the existing tests that are affected as range limited where the
upper bound is the below the version of Maven that the change in behaviour
will land in
2. Create tests of the new behaviour (probably copied from the original
tests but with the assertions modified and using a range limited where the
lower bound is the version of Maven that the change in behaviour will land
in.

An example of such a change is
https://github.com/apache/maven-integration-testing/commit/c4365abe20b58b2cbc174de812e43c7741dc10e1

We now have a more complex case to try and decide how to handle, the
current attempt to resolve is this diff:
https://github.com/apache/maven-integration-testing/compare/master...MNG-2199

However I am somewhat uncomfortable with how that proposed fix to the
integration tests works.

So firstly, Christian has identified that the original tests added were not
correctly detecting the failure.

We have a situation therefore where the integration tests have been giving
false positive results against Maven 3.2.2+

Therefore, my view is that we should *fix the broken tests* because a false
positive or a false negative is a bug in the tests.

This would mean that the tests would no longer pass when run against
3.2.2-3.3.9, instead they would report the bugs in those versions that we
shipped due to the bugs in the integration tests.

If we had a need to release - say security fixes - for those lines, we
would then have to do one of:
* ACK the continued failing tests;
* Run with the integration tests forked from the point in time where the
previous release on the line was cut; OR
* Back-port the fixes to those lines

(assuming we are supporting those lines for security fixes)

I am fine with any of those three options as those are known issues that we
should really have JIRAs for and be documenting in the release notes, and
any of those three options would be forcing us to acknowledge the bugs.

An alternative is to say "those bugs were part of the specification of
Maven and we have changed the specification of Maven again" which is the
approach that the current MNG-2199 branch takes.

I am not happy with that approach as it is an implicit approval of that
type of usage for the broken versions of Maven. Users could legitimately
start filing feature requests to "restore" the previous behaviour because
"it was part of the specification"... fine we can probably bat those
requests away, but is it helping us with code archeology?

So, what do we want to do with the case of a test being identified as
having either a false positive or a false negative against an already
released version of Maven?

A. Fix the test and then the test will fail against already released
versions of Maven
B. Fix the test, but exclude the broken versions of Maven from the range
with a comment explaining why
C. Clone the test, leaving the broken test for the old versions of Maven
and the new test for new versions of Maven
D. Something else

I personally favour A or B (with a slight leaning towards A) and I really
do not like C for the case of the false-positive / false-negative tests

If an obvious consensus does not emerge I may have to call a vote, you have
been warned!

-Stephen

[GitHub] maven pull request #104: [MNG-5961] Fix the SLF4J logger factory implementat...

[aheritier]

GitHub user aheritier opened a pull request:

https://github.com/apache/maven/pull/104

[MNG-5961] Fix the SLF4J logger factory implementation used for LOG4J2

This is the fix I did in 
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties;h=cd01f9e6bb29cf31371e0e6df04d095430d3ea9b;hp=87418363b1812e85d6a41a63df4486d07227e1d5;hb=202f757af3aba6e1b96631de025e0ba692098009;hpb=5a3332ca347628605bec7d3e9f9309081aaba46c

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/aheritier/maven patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/104.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #104


commit 0055ac0b4b572fa0e8bf699327ea45263ce40e81
Author: Arnaud Heritier 
Date:   2017-01-31T09:26:28Z

[MNG-5961] Fix the SLF4J logger factory implementation used for LOG4J2




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org