Can we disable emails to commits@ for branches?

Hi, subject says it all. I find it useless to have emails send out for every commit not to master. Currently we do not have to maintain any release branches. The only commit emails of interest would be the commits merged to master. Can we just disable all those emails to commits@ for everything

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

Github user jsoref commented on the issue: https://github.com/apache/maven/pull/100 Updated --- 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

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

Am 02/02/17 um 01:35 schrieb Stephen Connolly: > Well we want that test the other way, we want it to pass everywhere except > the buggy releases 3.3.0 and 3.3.9 Ok. Means I do not need to change anything about that test and can leave it the way it was. I just need a way to indicate the expected

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

Well we want that test the other way, we want it to pass everywhere except the buggy releases 3.3.0 and 3.3.9 Having a test to cover broken behaviour is exactly not what we want imho On Wed 1 Feb 2017 at 23:15, Christian Schulte wrote: > Am 02/02/17 um 00:10 schrieb Stephen

Re: Fwd: [jira] [Resolved] (MNG-5971) Imported dependencies should be available to inheritance processing

Am 02/02/17 um 00:35 schrieb Christian Schulte: > Am 02/01/17 um 13:33 schrieb Anders Hammar: >> I don't understand. Why is this marked as fixed (with no commit reference) >> if it's on the 3.6.0-candidate list? There have been several similar cases >> just recently; has there been some incorrect

Re: Fwd: [jira] [Resolved] (MNG-5971) Imported dependencies should be available to inheritance processing

Am 02/01/17 um 13:33 schrieb Anders Hammar: > I don't understand. Why is this marked as fixed (with no commit reference) > if it's on the 3.6.0-candidate list? There have been several similar cases > just recently; has there been some incorrect jira update? > > /Anders The issue is not closed.

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

Am 02/02/17 um 00:10 schrieb Stephen Connolly: > Sorry we want the inverse, > > "(,3.3.0),(3.3.0,3.3.9),(3.3.9,)" > > If the test is expected to fail on everything except 3.3.0 and 3.3.9 but > such a test is not the usecase for this tool That's what I was looking for. I have that use case for

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user jonenst commented on the issue: https://github.com/apache/maven-surefire/pull/110 @Tibor17 thanks for sharing. Your work is much appreciated. I hope everything works out with this person. --- If your project is set up for it, you can reply to this email and have your

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

Sorry we want the inverse, "(,3.3.0),(3.3.0,3.3.9),(3.3.9,)" If the test is expected to fail on everything except 3.3.0 and 3.3.9 but such a test is not the usecase for this tool On Wed 1 Feb 2017 at 23:09, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > With the range

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

With the range "[3.3.0],[3.3.9]" On Wed 1 Feb 2017 at 23:04, Christian Schulte wrote: > Out of curiosity: How would I specify the test to fail on all Maven > versions but 3.3.0 and 3.3.9? > > > - > To

Re: Question on how to manage the various branches.

Let's take things slower for everything after 3.5.0 The only one to put speed on is 3.5.0... and I even fear we are going too fast there On Wed 1 Feb 2017 at 22:50, Christian Schulte wrote: > Am 02/01/17 um 23:41 schrieb Stephen Connolly: > > On 1 February 2017 at 21:20,

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

Out of curiosity: How would I specify the test to fail on all Maven versions but 3.3.0 and 3.3.9? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question on how to manage the various branches.

Am 02/01/17 um 23:41 schrieb Stephen Connolly: > On 1 February 2017 at 21:20, Christian Schulte wrote: > >> Am 02/01/17 um 22:13 schrieb Stephen Connolly: >>> 1.2.0 will not be in Maven 3.5.0 >>> >>> Let's get 3.5.0 out the door first >> >> Yes. That's why I updated the version

Re: Question on how to manage the various branches.

On 1 February 2017 at 21:20, Christian Schulte wrote: > Am 02/01/17 um 22:13 schrieb Stephen Connolly: > > 1.2.0 will not be in Maven 3.5.0 > > > > Let's get 3.5.0 out the door first > > Yes. That's why I updated the version in the poms to match the ranges > from the ITs.

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

https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=92a11a96 (not using annotations because our integration tests are JUnit 3.8.x style) On 1 February 2017 at 20:03, Christian Schulte wrote: > Am 02/01/17 um 20:05 schrieb Stephen Connolly: > > I

Re: maven-integration-testing git commit: Provide a mechanism whereby tests can indicate versions of Maven expected to fail

An example of use would be: diff --git > a/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5958LifecyclePhaseBinaryCompat.java > b/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5958LifecyclePhaseBinaryCompat.java > index 3ee3fe10..370bdf37 100644 > --- >

Re: MNG-5868 for 3.5.0

Hi, On 01/02/17 21:15, Christian Schulte wrote: @Karl Heinz: Consider the MNG-5868 branch yours :-) I take it ...Thanks. Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For

Re: Question on how to manage the various branches.

Am 02/01/17 um 22:13 schrieb Stephen Connolly: > 1.2.0 will not be in Maven 3.5.0 > > Let's get 3.5.0 out the door first Yes. That's why I updated the version in the poms to match the ranges from the ITs. The order of the branches already reflects the versions from the roadmap cause the ranges

Re: Next Maven Resolver Version

Am 02/01/17 um 22:16 schrieb Michael Osipov: > Am 2017-02-01 um 21:48 schrieb Christian Schulte: >> Am 02/01/17 um 20:25 schrieb Michael Osipov: >>> Hi folks, >>> >>> how are we going to proceed with the next version 1.1? What shall be >>> included? I have several pending issued I'd like to apply.

Re: Next Maven Resolver Version

Am 02/01/17 um 22:14 schrieb Stephen Connolly: > On 1 February 2017 at 20:48, Christian Schulte wrote: > >> Am 02/01/17 um 20:25 schrieb Michael Osipov: >>> Hi folks, >>> >>> how are we going to proceed with the next version 1.1? What shall be >>> included? I have several

Re: Next Maven Resolver Version

Am 2017-02-01 um 21:48 schrieb Christian Schulte: Am 02/01/17 um 20:25 schrieb Michael Osipov: Hi folks, how are we going to proceed with the next version 1.1? What shall be included? I have several pending issued I'd like to apply. Are we going the same route as with Maven master? I think

Re: Next Maven Resolver Version

On 1 February 2017 at 20:48, Christian Schulte wrote: > Am 02/01/17 um 20:25 schrieb Michael Osipov: > > Hi folks, > > > > how are we going to proceed with the next version 1.1? What shall be > > included? I have several pending issued I'd like to apply. Are we going > > the

Re: Question on how to manage the various branches.

1.2.0 will not be in Maven 3.5.0 Let's get 3.5.0 out the door first On 1 February 2017 at 20:42, Christian Schulte wrote: > Hi, > > regarding the last comment on MNG-5600 by Michael Osipov asking for the > branch the issue has landed in maybe someone please take a look at the

Re: Next Maven Resolver Version

Am 02/01/17 um 20:25 schrieb Michael Osipov: > Hi folks, > > how are we going to proceed with the next version 1.1? What shall be > included? I have several pending issued I'd like to apply. Are we going > the same route as with Maven master? I think this is really necessary. I'd like the

Question on how to manage the various branches.

Hi, regarding the last comment on MNG-5600 by Michael Osipov asking for the branch the issue has landed in maybe someone please take a look at the branches I pushed to the core repository and tell me what I should be doing differently. It's quite time consuming to get the commits from the

Re: MNG-5868 for 3.5.0

@Karl Heinz: Consider the MNG-5868 branch yours :-) - 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

Am 02/01/17 um 20:05 schrieb Stephen Connolly: > I would rather modify verifier to allow recording versions we expect to > fail vs versions we expect to pass. +1 On method level instead of class level. Maybe by employing annotations one can add to methods like @SupportedBy.

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/110 @jonenst I was about to finish the last one and suddenly we had internal collision and now we reverted 11 commits. I am going to fix them but the procedure will be that we have to

Re: Next Maven Resolver Version

Am 2017-02-01 um 20:35 schrieb Robert Scholte: Yes please, and we might even need an extra approver because resolution and dependency management are the heart of Maven. It must be clear what will change compared to the current implementation and why this is better. And try to use avoid strong

Re: Next Maven Resolver Version

Yes please, and we might even need an extra approver because resolution and dependency management are the heart of Maven. It must be clear what will change compared to the current implementation and why this is better. And try to use avoid strong words like 'wrong'; the current resolution is

Next Maven Resolver Version

Hi folks, how are we going to proceed with the next version 1.1? What shall be included? I have several pending issued I'd like to apply. Are we going the same route as with Maven master? I think this is really necessary. Michael

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

Am 2017-02-01 um 20:05 schrieb Stephen Connolly: I would rather modify verifier to allow recording versions we expect to fail vs versions we expect to pass. I'll see if I can code it up. That would at least give us the verification of the failure on the broken and the verification of the fix

Re: MNG-5868 for 3.5.0

Am 02/01/17 um 11:22 schrieb Stephen Connolly: > On 1 February 2017 at 10:15, Karl Heinz Marbaise wrote: > >> Hi, >> >> On 01/02/17 10:50, Stephen Connolly wrote: >> >>> But doesn't the shade plugin want to do exactly that... namely attach >>> the shaded jar *to replace* the

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

I would rather modify verifier to allow recording versions we expect to fail vs versions we expect to pass. I'll see if I can code it up. That would at least give us the verification of the failure on the broken and the verification of the fix without the duplication and consequent risk that

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

Am 2017-01-31 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

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

Github user stephenc commented on the issue: https://github.com/apache/maven/pull/104 > we don't have a CI validation here Yep waiting to get SCM API 2.0.x back into the uc and then pester infra to upgrade --- If your project is set up for it, you can reply to this email

[GitHub] maven-surefire issue #110: SUREFIRE-1216: TEST-*.xml files generated by Sure...

Github user jonenst commented on the issue: https://github.com/apache/maven-surefire/pull/110 Hi @Tibor17 "54 of 55 issues have been resolved" on the roadmap, when can we expect a release ...? Is there something I can do to help with the release ? Cheers, Jon --- If

Fwd: [jira] [Resolved] (MNG-5971) Imported dependencies should be available to inheritance processing

I don't understand. Why is this marked as fixed (with no commit reference) if it's on the 3.6.0-candidate list? There have been several similar cases just recently; has there been some incorrect jira update? /Anders -- Forwarded message -- From: Christian Schulte (JIRA)

Re: MNG-5868 for 3.5.0

On 1 February 2017 at 10:34, Karl Heinz Marbaise wrote: > Hi Stephen, > > On 01/02/17 11:22, Stephen Connolly wrote: > >> >> >> On 1 February 2017 at 10:15, Karl Heinz Marbaise > > wrote: >> >> Hi, >> >> On 01/02/17 10:50,

Re: MNG-5868 for 3.5.0

Hi Stephen, On 01/02/17 11:22, Stephen Connolly wrote: On 1 February 2017 at 10:15, Karl Heinz Marbaise > wrote: Hi, On 01/02/17 10:50, Stephen Connolly wrote: But doesn't the shade plugin want to do exactly that... namely

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

Github user michael-o commented on the issue: https://github.com/apache/maven/pull/100 Testing your PR, two issues: 1. Please resolve the marked conflicts from above 2. One test fails because you missed to rename a directory:

Re: MNG-5868 for 3.5.0

On 1 February 2017 at 10:15, Karl Heinz Marbaise wrote: > Hi, > > On 01/02/17 10:50, Stephen Connolly wrote: > >> But doesn't the shade plugin want to do exactly that... namely attach >> the shaded jar *to replace* the jar attached by the jar plugin? >> > > Yes but if the

Re: MNG-5868 for 3.5.0

Hi, On 01/02/17 10:50, Stephen Connolly wrote: But doesn't the shade plugin want to do exactly that... namely attach the shaded jar *to replace* the jar attached by the jar plugin? Yes but if the maven-source-plugin does the same and attach a source package which means you have two artifacts

Re: MNG-5868 for 3.5.0

But doesn't the shade plugin want to do exactly that... namely attach the shaded jar *to replace* the jar attached by the jar plugin? On 1 February 2017 at 08:51, Karl Heinz Marbaise wrote: > Hi, > > fixing this issue will produce a WARNING in cases where different plugins

Re: MNG-5868 for 3.5.0

Hi, fixing this issue will produce a WARNING in cases where different plugins attach the same artifact multiple times which gives a hint on a wrong build configuration... Examples: maven-sources-plugin attaches a jar and another plugin will do the same thing...which results in complains

Re: MNG-5961 for 3.5.0 ?

The build failed : Caused by: java.io.IOException: There is not enough space on the disk Because of an infrastructure issue: Caused by: java.io.IOException: There is not enough space on the disk Is there something I can do on my side ? On Tue, Jan 31, 2017 at 9:44 PM, Arnaud Héritier