Re: main-class + module-version

Hi Robert, > > I've started a bit with it, but no success yet: > https://mail.ow2.org/wws/arc/asm/2017-08/msg4.html > > Even after the suggestions from Remi no success yet. > I was hoping for a fast fix, but it'll take more time and other things are > waiting as well. > Would be great if you

Re: ATTN: Maven core build is broken

I'll delete branches bisect-0 through bisect-3 once Robert ACKs my analysis On 29 August 2017 at 16:57, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1 > both fail just for the MNG-6127 integration tests,

Re: ATTN: Maven core build is broken

Ok, looking a the results of the bisect-0 through bisect-3 builds, 0 and 1 both fail just for the MNG-6127 integration tests, bisect-2 adds the fix for MNG-6127, so the build passes... bisect-3 also passes, so the smoking gun is...

Re: ATTN: Maven core build is broken

bisect-0 is the last known good commit with the Jenkinsfile fix to confirm that the failures are not another infra related change On 29 August 2017 at 22:13, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify > the

Re: ATTN: Maven core build is broken

Another build based on master is well failing on all four exec environments: https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6216/4/testReport/junit/org.apache.maven.it/MavenITBootstrapTest/ So clearly the build failure is real On 29 August 2017 at 22:13, Stephen Connolly <

Re: ATTN: Maven core build is broken

I have pushed bisect-1, bisect-2 and bisect-3 to see if we can identify the problematic commit since the last known good build of master (#123 for commit 4f2a2dba89251d9045fe9944783509a397491da3) On 29 August 2017 at 22:09, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Failure is

ATTN: Maven core build is broken

Failure is in testBootstrap, probably something obvious, here's the problematic build log... you can inspect for yourself at https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/master/128/tests but there is no point in looking at any tests other than testBootstrap as

REQUEST: Can we remove any branches that have been merged or are no longer needed?

Please see https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/branches for the status of the core branches. Please delete branches if they have been merged to master already or if they are no longer relevant Thanks -Stephen

FYI I rebased the MNG-6069 and MNG-6216 to pick up e44c39c

https://github.com/apache/maven/commit/e44c39c2eb5afda9efe60b9dd0ffc32c62501c5f fixes the Jenkinsfile after the changes introduced by JENKINS-43507 so in order to get those two branches to have a realistic integration test result status I have `git push --force-with-lease` these two branches after

Re: Issue Jenkinsfile Pipeline for maven core...

Ok, it's running the integration tests again... we are back in business On 29 August 2017 at 21:51, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > https://builds.apache.org/blue/organizations/jenkins/ > maven-3.x-jenkinsfile/detail/master/128/pipeline more corectly > > On 29 August

Re: Issue Jenkinsfile Pipeline for maven core...

https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/detail/master/128/pipeline more corectly On 29 August 2017 at 21:49, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Let's see how https://builds.apache.org/blue/organizations/jenkins/ >

Re: Issue Jenkinsfile Pipeline for maven core...

Let's see how https://builds.apache.org/blue/organizations/jenkins/maven-3.x-jenkinsfile/branches/ goes now... On 29 August 2017 at 19:40, Karl Heinz Marbaise wrote: > Hi, > > On 29/08/17 20:35, Stephen Connolly wrote: > >> Should support but not require same names

Re: Status check 3.5.1

On Tue, 29 Aug 2017 19:55:50 +0200, Karl Heinz Marbaise wrote: Hi, On 29/08/17 17:00, Stephen Connolly wrote: I am seeing two issues remaining for 3.5.1: https://issues.apache.org/jira/browse/MNG-6216: ArrayIndexOutOfBoundsException when parsing POM This is the only

Re: Issue Jenkinsfile Pipeline for maven core...

Hi, On 29/08/17 20:35, Stephen Connolly wrote: Should support but not require same names integration branch... Yes that was my assumption as well... >likely the Jenkinsfile needs updating after JENKINS-43507 Ah ok... Thanks for clearing up things... Kind regards Karl Heinz Marbaise

Re: Issue Jenkinsfile Pipeline for maven core...

Should support but not require same names integration branch... likely the Jenkinsfile needs updating after JENKINS-43507 On Tue 29 Aug 2017 at 19:17, Karl Heinz Marbaise wrote: > Hi, > > currently I'm observing that I can a branch in Maven Core for example > MNG-6216 but it

Issue Jenkinsfile Pipeline for maven core...

Hi, currently I'm observing that I can a branch in Maven Core for example MNG-6216 but it looks like I need also the same branch in the maven-integration-testing... Currently the configuration lets conclude me that: Checking for first existing branch from [MNG-6216, master]... > git

Re: Status check 3.5.1

Hi, On 29/08/17 17:00, Stephen Connolly wrote: I am seeing two issues remaining for 3.5.1: https://issues.apache.org/jira/browse/MNG-6216: ArrayIndexOutOfBoundsException when parsing POM This is the only which I think should be part of 3.5.1... where the IT's etc had worked but now the

Status check 3.5.1

I am seeing two issues remaining for 3.5.1: https://issues.apache.org/jira/browse/MNG-6216: ArrayIndexOutOfBoundsException when parsing POM and https://issues.apache.org/jira/browse/MNG-5868: Adding serval times the same artifact via MavenProjectHelper (attachArtifact) does not produce a

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

Github user owenfarrell commented on the issue: https://github.com/apache/maven-surefire/pull/157 I don't think that logic would work for my scenario. For example: 1. Create multi-module project with a test runner JAR (a la

Re: [GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

I mean to reorganize the control flow in to this order which should work for both of us: 1. List dependenciesToScan = DependencyScanner.filter( project.getTestArtifacts(), Arrays.asList( getDependenciesToScan() ) ); DependencyScanner scanner = new DependencyScanner( dependenciesToScan,

[GitHub] maven-surefire pull request #164: SUREFIRE-1383: Split IT569 in to multiple ...

GitHub user owenfarrell opened a pull request: https://github.com/apache/maven-surefire/pull/164 SUREFIRE-1383: Split IT569 in to multiple lifecycles @Tibor17 - Based on [your comment](https://github.com/apache/maven-surefire/pull/157#issuecomment-325616922), is this in line with

Re: [GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

This supports classifiers project.getTestArtifacts() If you find the one Artifact in this collection then you can simply ignore it in session.getSortedProjects() If it basically opposite what you have done in your code with the removal. So the old code says to take test dependencies match them

[GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

Github user owenfarrell commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/157#discussion_r135778722 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java --- @@ -847,12 +847,31 @@ private

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @owenfarrell It would be easier for you not to rever 569 in this PR but create a new PR from master. I pushed a new fix to master today. The master will be idle for you. --- If your

[GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/157#discussion_r135766258 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java --- @@ -847,12 +847,31 @@ private

[GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/157#discussion_r135765515 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java --- @@ -847,12 +847,31 @@ private

[GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/157#discussion_r135765205 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java --- @@ -847,12 +847,31 @@ private

[GitHub] maven-surefire pull request #157: SUREFIRE-1383 dependenciesToScan Does Not ...

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/157#discussion_r135765053 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java --- @@ -847,12 +847,31 @@ private

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @owenfarrell I found the root cause. The dependency to scan is examined with outputDirectory, but IT 569 has shources to share in `src/test/java` so the artifact would match but

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

Github user owenfarrell commented on the issue: https://github.com/apache/maven-surefire/pull/157 @Tibor17 - IT569 does not **fail** when introducing my changes. But since the test was written as a single lifecycle, it inadvertently uses the code I've introduced in this PR ([see

[GitHub] maven-surefire issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverag...

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/157 @owenfarrell I built the project. It was ok but then I realized you modified IT 569 which I do not like because this was a feature and I want to guarantee that old tests pass without

Re: main-class + module-version

Hi Plamen, On Tue, 29 Aug 2017 07:46:59 +0200, Plamen Totev wrote: Hi Robert, Thank you for you comments. Also I took a look at the changes in the JDK jar tool and I notice a couple of things that it does: 1. The structure of the jar produced is such that the