[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917313#comment-16917313
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #25
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/25/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917312#comment-16917312 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #25 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/25/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917314#comment-16917314
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #25
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/25/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917311#comment-16917311 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #25 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/25/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917308#comment-16917308
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #32
See
https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/32/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917307#comment-16917307
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #32
See
https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/32/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917306#comment-16917306 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #32 See https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/32/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917305#comment-16917305 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #32 See https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/32/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917298#comment-16917298
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5868 #35
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/35/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917297#comment-16917297 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-5868 #35 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/35/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917299#comment-16917299
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5868 #35
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/35/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917296#comment-16917296 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-5868 #35 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5868/35/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917287#comment-16917287 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MPOM-215 #14 See https://builds.apache.org/job/maven-box/job/maven/job/MPOM-215/14/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917288#comment-16917288
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MPOM-215 #14
See https://builds.apache.org/job/maven-box/job/maven/job/MPOM-215/14/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917289#comment-16917289
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MPOM-215 #14
See https://builds.apache.org/job/maven-box/job/maven/job/MPOM-215/14/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917286#comment-16917286 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MPOM-215 #14 See https://builds.apache.org/job/maven-box/job/maven/job/MPOM-215/14/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917285#comment-16917285
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5567 #34
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5567/34/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917284#comment-16917284
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5567 #34
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5567/34/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917282#comment-16917282 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-5567 #34 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5567/34/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917283#comment-16917283 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-5567 #34 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5567/34/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917267#comment-16917267
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » slf4j-1.8-modules #15
See https://builds.apache.org/job/maven-box/job/maven/job/slf4j-1.8-modules/15/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917268#comment-16917268
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » slf4j-1.8-modules #15
See https://builds.apache.org/job/maven-box/job/maven/job/slf4j-1.8-modules/15/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917266#comment-16917266 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » slf4j-1.8-modules #15 See https://builds.apache.org/job/maven-box/job/maven/job/slf4j-1.8-modules/15/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917265#comment-16917265 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » slf4j-1.8-modules #15 See https://builds.apache.org/job/maven-box/job/maven/job/slf4j-1.8-modules/15/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917261#comment-16917261
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » runITsWithJavaEA #39
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/39/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917260#comment-16917260 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556_MJAR-3.0.0 #7 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556_MJAR-3.0.0/7/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917258#comment-16917258
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » runITsWithJavaEA #39
See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/39/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917262#comment-16917262
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556_MJAR-3.0.0 #7
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556_MJAR-3.0.0/7/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917257#comment-16917257 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » runITsWithJavaEA #39 See https://builds.apache.org/job/maven-box/job/maven/job/runITsWithJavaEA/39/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917263#comment-16917263
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556_MJAR-3.0.0 #7
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556_MJAR-3.0.0/7/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917259#comment-16917259 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556_MJAR-3.0.0 #7 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556_MJAR-3.0.0/7/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917225#comment-16917225
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #23
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/23/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917223#comment-16917223 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #23 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/23/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917222#comment-16917222 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #23 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/23/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917224#comment-16917224
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6551 #23
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/23/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917220#comment-16917220
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #20
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/20/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917218#comment-16917218 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #20 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/20/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917217#comment-16917217 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #20 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/20/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917219#comment-16917219
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6550 #20
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/20/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917212#comment-16917212
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #17
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/17/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917211#comment-16917211
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #17
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/17/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917209#comment-16917209 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #17 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/17/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917210#comment-16917210 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6552 #17 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/17/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917200#comment-16917200
]
Hudson commented on MNG-6731:
-
Build succeeded in Jenkins: Maven TLP » maven » archives #5
See https://builds.apache.org/job/maven-box/job/maven/job/archives/5/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917187#comment-16917187 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #24 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/24/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917188#comment-16917188
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #24
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/24/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917189#comment-16917189
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #24
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/24/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917186#comment-16917186 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6555 #24 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/24/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MDEP-657) Maven - Failing when two modules have same dependency and both trying to download the dependency at the same time when Parallel flag is enabled.
[
https://issues.apache.org/jira/browse/MDEP-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917180#comment-16917180
]
Padma G commented on MDEP-657:
--
You can close the case. Thanks
> Maven - Failing when two modules have same dependency and both trying to
> download the dependency at the same time when Parallel flag is enabled.
>
>
> Key: MDEP-657
> URL: https://issues.apache.org/jira/browse/MDEP-657
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Environment: Maven 3.6.1
>Reporter: Padma G
>Priority: Major
>
> Maven Version 3.6.1
> command : mvn -U -T 2C -DskipTests=true clean install -s settings.xml
> We have several modules with same dependency and it is failing when two are
> downloading same dependency at the same time with below error.
> if we remove parallel flag it will go through. But the build will be very
> long.
> Ideally it should wait and not fail?
> {noformat}
> [ERROR] Failed to execute goal on project content-model: Could not resolve
> dependencies for project com.gehc.ei.zfp:content-model:jar:6011.0.1.8270:
> Failed to collect dependencies at
> com.gehc.ei.zfp:ei-logging-service:jar:6011.0.1.8109 ->
> com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Failed to read artifact
> descriptor for com.gehc.ei.zfp:atna-log-appender:jar:6011.0.1.8109: Could not
> transfer artifact com.gehc.ei.zfp:atna-log-appender:pom:6011.0.1.8109 from/to
> central ([/artifactory/maven-zfp-all|:
> C:\Users\user\.m2\repository\com\gehc\ei\zfp\atna-log-appender\6011.0.1.8109\atna-log-appender-6011.0.1.8109.pom.part.lock
> (The process cannot access the file because it is being used by another
> process) -> [Help 1]
> {noformat}
> Any idea why it is behaving this way?
> Regards,
> Padma
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917171#comment-16917171 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #16 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/16/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917173#comment-16917173
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #16
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/16/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917174#comment-16917174
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #16
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/16/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917172#comment-16917172 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6554 #16 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/16/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917156#comment-16917156
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #22
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/22/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917154#comment-16917154 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #22 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/22/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917157#comment-16917157
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #22
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/22/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917155#comment-16917155 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6556 #22 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/22/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917125#comment-16917125
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » EOL #15
See https://builds.apache.org/job/maven-box/job/maven/job/EOL/15/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917126#comment-16917126
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » EOL #15
See https://builds.apache.org/job/maven-box/job/maven/job/EOL/15/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917124#comment-16917124 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » EOL #15 See https://builds.apache.org/job/maven-box/job/maven/job/EOL/15/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-surefire] jon-bell commented on a change in pull request #245: Surefire-1584: Add option to rerun failing tests for JUnit5
jon-bell commented on a change in pull request #245: Surefire-1584: Add option
to rerun failing tests for JUnit5
URL: https://github.com/apache/maven-surefire/pull/245#discussion_r318304783
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/RunListenerAdapter.java
##
@@ -259,4 +261,50 @@ else if ( testSource.filter(
ClassSource.class::isInstance ).isPresent() )
return new String[] { source, source, display, display };
}
}
+
+public String[] toClassMethodNameWithoutPlan( TestIdentifier
testIdentifier )
Review comment:
@Tibor17 - We've been trying hard to come up with a work around so that the
existing `toClassMethodName` can be used for both cases, but are stumped with
an approach that would be more generic. Do you have any suggestions?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MNG-6725) Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs (by default on Jenkins CI).
[
https://issues.apache.org/jira/browse/MNG-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917101#comment-16917101
]
Hudson commented on MNG-6725:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #17
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/17/
> Skip '.mavenrc' via MAVEN_SKIP_RC=1 and '-Dmaven.skip.rc=true' on child ITs
> (by default on Jenkins CI).
> ---
>
> Key: MNG-6725
> URL: https://issues.apache.org/jira/browse/MNG-6725
> Project: Maven
> Issue Type: Task
> Components: Integration Tests
> Environment: ASF Jenkins CI
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> This is related to the problem with MAVEN_OPTS.
> If Jenkins has global '.mavenrc' then the environment variables are merged
> with local ones and applied in Maven JVM which is controlled by
> $MVN_HOME/bin/mvn
> If you want to isolate the JVM from global '.mavenrc', you have to set
> environment variable to non-zero length value, i.e. MAVEN_SKIP_RC=1.
> This commit controls skipping '.mavenrc' in
> {{AbstractMavenIntegrationTestCase}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6720) MultiThreadedBuilder: wait for parallel running projects when using --fail-fast
[ https://issues.apache.org/jira/browse/MNG-6720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917100#comment-16917100 ] Hudson commented on MNG-6720: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #17 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/17/ > MultiThreadedBuilder: wait for parallel running projects when using > --fail-fast > --- > > Key: MNG-6720 > URL: https://issues.apache.org/jira/browse/MNG-6720 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.4, 3.6.1 >Reporter: Stefan Oehme >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > Time Spent: 40m > Remaining Estimate: 0h > > When a project fails using --fail-fast mode, other projects that are > currently running in parallel are not finished before the "session finished" > event is sent. This leads to issues for extensions that rely on the > documented order of events, which says that "session finished" is only sent > "after all projects have been finished/skipped". > In our case, we close a service on "session finished", and that service is > needed to execute goals. The goals that were running in parallel at that time > then fail, saying that our service was closed, giving our users the > impression that there is a bug in our code. > The relevant line is > [here|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/MultiThreadedBuilder.java#L179]. > Instead of using `poll`, which simply returns when the parallel projects > aren't finished yet, the code should shut down the executor and wait for it > to complete the outstanding parallel work. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-4385) [regression] Custom lifecycle mappings from build extension leak into other projects in the reactor without extension
[ https://issues.apache.org/jira/browse/MNG-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917099#comment-16917099 ] Hudson commented on MNG-4385: - Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #17 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/17/ > [regression] Custom lifecycle mappings from build extension leak into other > projects in the reactor without extension > - > > Key: MNG-4385 > URL: https://issues.apache.org/jira/browse/MNG-4385 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Major > Fix For: 3.0-alpha-3 > > Attachments: MNG-4385.zip > > > A project without any build extensions has erroneously access to the custom > lifecycle mappings from a build extension of another project in the reactor > that was built before. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917102#comment-16917102
]
Hudson commented on MNG-6731:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6169/MNG-6553 #17
See
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/17/
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6581) Maven deploys version metadata multiple times
[ https://issues.apache.org/jira/browse/MNG-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916992#comment-16916992 ] Michael Osipov commented on MNG-6581: - [~eolivelli], no I have merged it as https://github.com/apache/maven/commit/8f1cac0b1c58c5b1ad26d38cbfd963d10f66d92a with a separate issue. I haven't even investigated this one. > Maven deploys version metadata multiple times > - > > Key: MNG-6581 > URL: https://issues.apache.org/jira/browse/MNG-6581 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 >Reporter: Cservenak, Tamas >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > This causes problems like MDEPLOY-221 is. > Problem: > Maven deploys version metadata multiple times. Seems it is triggered by any > plugin that attaches artifact to MavenProject? > This happens with all 2.x m-deploy-p. 3.0.0-M1 fails. > Expected: > Maven deploy version (and any other) metadata only once with proper > timestmaps (those that have the deployed artifacts) whatever count of > attached artifacts are there. > Reproducer: > [https://github.com/cstamas/mvn-md-bug] -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRELEASE-1027) New Release
[ https://issues.apache.org/jira/browse/MRELEASE-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916923#comment-16916923 ] Robert Scholte commented on MRELEASE-1027: -- Short and honest answer: there is nothing planned and based on real hot issues this plugin has to wait for a while. As you're requesting the release of a new feature, I'd strongly advice you to test it first (to prevent possible disappointments once released and the time it takes to fix it). The steps: - fork or download https://github.com/apache/maven-release-plugin - release it with a unique version, e.g. 3.0.0-M1-NickCross Also write feedback in Jira regarding the maven-release-semver-policy. Does it work as expected or not? > New Release > --- > > Key: MRELEASE-1027 > URL: https://issues.apache.org/jira/browse/MRELEASE-1027 > Project: Maven Release Plugin > Issue Type: Task >Reporter: Nick Cross >Priority: Major > > Will there be a new release of the release plugin at any point? The last one > appears to be 4 years ago and is missing > https://github.com/apache/maven-release/blame/master/pom.xml#L44 change. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916833#comment-16916833
]
Abel Salgado Romero commented on MSITE-849:
---
Any idea on this topic?
PS: sorry to be a p**a, I'd really would like to see this progress :%
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MNG-6747) Generalize 'resume from' message when build reactor fails
[ https://issues.apache.org/jira/browse/MNG-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916788#comment-16916788 ] Hudson commented on MNG-6747: - Build succeeded in Jenkins: Maven TLP » maven » master #282 See https://builds.apache.org/job/maven-box/job/maven/job/master/282/ > Generalize 'resume from' message when build reactor fails > - > > Key: MNG-6747 > URL: https://issues.apache.org/jira/browse/MNG-6747 > Project: Maven > Issue Type: Improvement > Components: Bootstrap Build, Reactor and workspace >Affects Versions: 3.6.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6581) Maven deploys version metadata multiple times
[
https://issues.apache.org/jira/browse/MNG-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916771#comment-16916771
]
Enrico Olivelli commented on MNG-6581:
--
[~michael-o] has this issue been fixed by
https://github.com/apache/maven/pull/252 ("upgrade modello") ?
I can't find a direct relation but JIRA links this issue to that PR and that PR
has been committed by you.
> Maven deploys version metadata multiple times
> -
>
> Key: MNG-6581
> URL: https://issues.apache.org/jira/browse/MNG-6581
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
>Reporter: Cservenak, Tamas
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This causes problems like MDEPLOY-221 is.
> Problem:
> Maven deploys version metadata multiple times. Seems it is triggered by any
> plugin that attaches artifact to MavenProject?
> This happens with all 2.x m-deploy-p. 3.0.0-M1 fails.
> Expected:
> Maven deploy version (and any other) metadata only once with proper
> timestmaps (those that have the deployed artifacts) whatever count of
> attached artifacts are there.
> Reproducer:
> [https://github.com/cstamas/mvn-md-bug]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://issues.apache.org/jira/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916744#comment-16916744 ] Niels Basjes commented on MSHADE-36: [~bentat...@nanometrics.ca] : When building a multi module project there will still be problems regarding the dependencies in the other modules. I recently wrote a page about that how I solved that in my own project: [https://yauaa.basjes.nl/NOTES-shading-dependencies.html] Essentially what works for me: * Library has dependencies (shaded into the jar) * Other modules use it as a dependency, exclude the shaded dependencies, re-include the shaded dependencies as 'provided'. > Dependency reduced pom does not replace the packaged META-INF/maven version > --- > > Key: MSHADE-36 > URL: https://issues.apache.org/jira/browse/MSHADE-36 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Mark Hobson >Priority: Major > > The dependency reduced pom needs to replace the packaged pom at: > META-INF/maven///pom.xml > This will allow tools that use this metadata to read the correct shaded > dependencies (e.g. maven-runtime). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (MNG-6747) Generalize 'resume from' message when build reactor fails
[ https://issues.apache.org/jira/browse/MNG-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6747. --- Resolution: Fixed Fixed with [400e7e597902c5c5383abe020579a9a50f3b76f8|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=400e7e597902c5c5383abe020579a9a50f3b76f8]. > Generalize 'resume from' message when build reactor fails > - > > Key: MNG-6747 > URL: https://issues.apache.org/jira/browse/MNG-6747 > Project: Maven > Issue Type: Improvement > Components: Bootstrap Build, Reactor and workspace >Affects Versions: 3.6.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.2 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-shade-plugin] nielsbasjes commented on issue #25: [MSHADE-36] Use reduced dependencies
nielsbasjes commented on issue #25: [MSHADE-36] Use reduced dependencies URL: https://github.com/apache/maven-shade-plugin/pull/25#issuecomment-525251567 I noticed that there will be a conflict with https://github.com/apache/maven-shade-plugin/pull/22 because I moved the creation of the dpr to a slightly different place (more forward instead of more backward). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://issues.apache.org/jira/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916557#comment-16916557 ] Niels Basjes commented on MSHADE-36: I put up a pull request with a proposed fix for this: [https://github.com/apache/maven-shade-plugin/pull/25] > Dependency reduced pom does not replace the packaged META-INF/maven version > --- > > Key: MSHADE-36 > URL: https://issues.apache.org/jira/browse/MSHADE-36 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Mark Hobson >Priority: Major > > The dependency reduced pom needs to replace the packaged pom at: > META-INF/maven///pom.xml > This will allow tools that use this metadata to read the correct shaded > dependencies (e.g. maven-runtime). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-shade-plugin] nielsbasjes opened a new pull request #25: [MSHADE 36] Use reduced dependencies
nielsbasjes opened a new pull request #25: [MSHADE 36] Use reduced dependencies
URL: https://github.com/apache/maven-shade-plugin/pull/25
This is a proposed fix for the issue
https://issues.apache.org/jira/browse/MSHADE-36 which has been open for about 8
years.
The implementation is activated when the setting
"useDependencyReducedPomInJar" is set to true.
It then essentially injects two ResourceTransformers from code
1) Remove the original
"META-INF/maven/${project.groupId}/${project.artifactId}/pom.xml".
2) Include the dependency-reduced-pom.xml under the name of the original
pom.xml into the final jar file.
This includes an integration test to verify this actually happens.
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MSHADE) filed
for the change (usually before you start working on it).
https://issues.apache.org/jira/browse/MSHADE-36
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MSHADE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MSHADE-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please
ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licensed under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven] michael-o commented on issue #165: [MNG-6028] Include current goals in resume suggestion
michael-o commented on issue #165: [MNG-6028] Include current goals in resume suggestion URL: https://github.com/apache/maven/pull/165#issuecomment-525170960 Superceded by MNG-6747. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MNG-6747) Generalize 'resume from' message when build reactor fails
Michael Osipov created MNG-6747: --- Summary: Generalize 'resume from' message when build reactor fails Key: MNG-6747 URL: https://issues.apache.org/jira/browse/MNG-6747 Project: Maven Issue Type: Improvement Components: Bootstrap Build, Reactor and workspace Affects Versions: 3.6.1 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.6.2 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (MNG-6028) When a reactor build fails maven should include current goals in resume suggestion
[
https://issues.apache.org/jira/browse/MNG-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6028.
---
Fix Version/s: (was: 3.6.x-candidate)
(was: wontfix-candidate)
Resolution: Won't Fix
As discussed on the PR, we will write {{}} only. This cannot be solved in
a complete manner.
> When a reactor build fails maven should include current goals in resume
> suggestion
> --
>
> Key: MNG-6028
> URL: https://issues.apache.org/jira/browse/MNG-6028
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Axel Fontaine
>Priority: Major
>
> Start multiproject build at root with mvn clean install
> if module-a fails you currently get
> {noformat}[ERROR] After correcting the problems, you can resume the build
> with the command
> [ERROR] mvn -rf :module-a{noformat}
> to be able to easily copy-paste this it would be much nicer if the goals were
> already filled in:
> {noformat}[ERROR] After correcting the problems, you can resume the build
> with the command
> [ERROR] mvn clean install -rf :module-a{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven] michael-o closed pull request #165: [MNG-6028] Include current goals in resume suggestion
michael-o closed pull request #165: [MNG-6028] Include current goals in resume suggestion URL: https://github.com/apache/maven/pull/165 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRELEASE-1027) New Release
[ https://issues.apache.org/jira/browse/MRELEASE-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916418#comment-16916418 ] Nick Cross commented on MRELEASE-1027: -- [~rfscholte] What is the schedule/timeline for a 3.0.0 release please? > New Release > --- > > Key: MRELEASE-1027 > URL: https://issues.apache.org/jira/browse/MRELEASE-1027 > Project: Maven Release Plugin > Issue Type: Task >Reporter: Nick Cross >Priority: Major > > Will there be a new release of the release plugin at any point? The last one > appears to be 4 years ago and is missing > https://github.com/apache/maven-release/blame/master/pom.xml#L44 change. -- This message was sent by Atlassian Jira (v8.3.2#803003)
