[jira] [Comment Edited] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963003#comment-16963003
]
Anton edited comment on ARCHETYPE-573 at 10/31/19 5:46 AM:
Each new module in archetype-metadata.xml add extra lines to parent pom between
*every* xml tags. For big multi-module archetypes it so weird looking!
For example, for generated maven project with 4 modules:
Head of pom.xml:
{code:xml}
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
{code}
Tail of pom.xml:
{code:xml}
application
backend
helm
docs
{code}
[~rfscholte] Please up the priority of this bug.
was (Author: popalka):
Each new module in archetype-metadata.xml add extra lines to parent pom between
*every* xml tags. For big multi-module archetypes it so weird looking!
[~rfscholte] Please up the priority of this bug.
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963003#comment-16963003
]
Anton edited comment on ARCHETYPE-573 at 10/31/19 5:33 AM:
Each new module in archetype-metadata.xml add extra lines to parent pom between
*every* xml tags. For big multi-module archetypes it so weird looking!
[~rfscholte] Please up the priority of this bug.
was (Author: popalka):
Each new module in archetype-metadata.xml add extra lines to parent pom between
*every* xml tags. For big multi-module archetypes it so weird looking!
Please up the priority of this bug.
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963003#comment-16963003
]
Anton edited comment on ARCHETYPE-573 at 10/31/19 5:32 AM:
Each new module in archetype-metadata.xml add extra lines to parent pom between
*every* xml tags. For big multi-module archetypes it so weird looking!
Please up the priority of this bug.
was (Author: popalka):
Please up the priority of this bug. It's very annoying.
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-wagon] michael-o opened a new pull request #59: [WAGON-573] EntityUtils.consumeQuietly() never called on non-2xx stat…
michael-o opened a new pull request #59: [WAGON-573] EntityUtils.consumeQuietly() never called on non-2xx stat… URL: https://github.com/apache/maven-wagon/pull/59 …us codes @ok2c Please have a look whether this makes sense to properly clean up resources. 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] [Assigned] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx status codes
[ https://issues.apache.org/jira/browse/WAGON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned WAGON-573: Assignee: Michael Osipov > EntityUtils.consumeQuietly() never called on non-2xx status codes > - > > Key: WAGON-573 > URL: https://issues.apache.org/jira/browse/WAGON-573 > Project: Maven Wagon > Issue Type: Bug >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > The reponse body in never properly handled if the response is not successful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx status codes
[ https://issues.apache.org/jira/browse/WAGON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-573: - Summary: EntityUtils.consumeQuietly() never called on non-2xx status codes (was: EntityUtils.consumeQuietly() never called on non-2xx cases) > EntityUtils.consumeQuietly() never called on non-2xx status codes > - > > Key: WAGON-573 > URL: https://issues.apache.org/jira/browse/WAGON-573 > Project: Maven Wagon > Issue Type: Bug >Reporter: Michael Osipov >Priority: Major > > The reponse body in never properly handled if the response is not successful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx cases
[ https://issues.apache.org/jira/browse/WAGON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-573: - Summary: EntityUtils.consumeQuietly() never called on non-2xx cases (was: EntityUtils.consumeQuetly() never called on non-2xx cases) > EntityUtils.consumeQuietly() never called on non-2xx cases > -- > > Key: WAGON-573 > URL: https://issues.apache.org/jira/browse/WAGON-573 > Project: Maven Wagon > Issue Type: Bug >Reporter: Michael Osipov >Priority: Major > > The reponse body in never properly handled if the response is not successful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (WAGON-573) EntityUtils.consumeQuetly() never called on non-2xx cases
[ https://issues.apache.org/jira/browse/WAGON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated WAGON-573: - Summary: EntityUtils.consumeQuetly() never called on non-2xx cases (was: EntityUtils.consume() never called on non-2xx cases) > EntityUtils.consumeQuetly() never called on non-2xx cases > - > > Key: WAGON-573 > URL: https://issues.apache.org/jira/browse/WAGON-573 > Project: Maven Wagon > Issue Type: Bug >Reporter: Michael Osipov >Priority: Major > > The reponse body in never properly handled if the response is not successful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] michael-o commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution
michael-o commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution URL: https://github.com/apache/maven/pull/297#discussion_r340880466 ## File path: apache-maven/src/main/appended-resources/META-INF/LICENSE.vm ## @@ -22,21 +22,18 @@ Apache Maven includes a number of components and libraries with separate copyright notices and license terms. Your use of those components are subject to the terms and conditions of the following licenses: ## -#set ( $apacheLicenseNames = [ "Apache License, Version 2.0", "The Apache Software License, Version 2.0", -"ASLv2", "Apache Public License 2.0", "Apache 2.0" ] ) +#set ( $apacheMavenGroupIds = [ "org.apache.maven", "org.apache.maven.wagon", "org.apache.maven.resolver", +"org.apache.maven.shared" ] ) #set ( $MITLicenseNames = [ "MIT License", "MIT license", "The MIT License" ] ) #foreach ( $project in $projects ) #**##foreach ( $license in $project.licenses) -#* *##if ( !$apacheLicenseNames.contains( $license.name ) ) +#* *##set ( $groupId = $project.artifact.groupId ) +#* *##if ( !$apacheMavenGroupIds.contains( $groupId ) ) #**##set ( $artId = $project.artifact.artifactId ) #**##set ( $url = $license.url ) #**##set ( $spdx = false ) #**##set ( $includeLicense = true ) #**### -#**##if ( $project.artifact.artifactId == "jcl-over-slf4j" ) Review comment: That's bad and needs to be backported to 1.7.x line. 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] hboutemy commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution
hboutemy commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution URL: https://github.com/apache/maven/pull/297#discussion_r340879889 ## File path: apache-maven/src/main/appended-resources/META-INF/LICENSE.vm ## @@ -22,21 +22,18 @@ Apache Maven includes a number of components and libraries with separate copyright notices and license terms. Your use of those components are subject to the terms and conditions of the following licenses: ## -#set ( $apacheLicenseNames = [ "Apache License, Version 2.0", "The Apache Software License, Version 2.0", -"ASLv2", "Apache Public License 2.0", "Apache 2.0" ] ) +#set ( $apacheMavenGroupIds = [ "org.apache.maven", "org.apache.maven.wagon", "org.apache.maven.resolver", +"org.apache.maven.shared" ] ) #set ( $MITLicenseNames = [ "MIT License", "MIT license", "The MIT License" ] ) #foreach ( $project in $projects ) #**##foreach ( $license in $project.licenses) -#* *##if ( !$apacheLicenseNames.contains( $license.name ) ) +#* *##set ( $groupId = $project.artifact.groupId ) +#* *##if ( !$apacheMavenGroupIds.contains( $groupId ) ) #**##set ( $artId = $project.artifact.artifactId ) #**##set ( $url = $license.url ) #**##set ( $spdx = false ) #**##set ( $includeLicense = true ) #**### -#**##if ( $project.artifact.artifactId == "jcl-over-slf4j" ) Review comment: we need to wait for a fixed release to remove the hack that overrides the license: the hack is not so big, we can live with it for now (notice the PR https://github.com/qos-ch/slf4j/pull/226 was merged in 2.0.0-alpha branch only) 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] hboutemy commented on a change in pull request #297: MNG-6771 Fix license issues on binary distribution
hboutemy commented on a change in pull request #297: MNG-6771 Fix license
issues on binary distribution
URL: https://github.com/apache/maven/pull/297#discussion_r340880178
##
File path: apache-maven/src/main/assembly/component.xml
##
@@ -29,6 +29,7 @@ under the License.
false
lib
+
${artifact.artifactId}-${artifact.version}.${artifact.extension}
Review comment:
I don't like this: why do you find it useful?
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] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963406#comment-16963406
]
Tibor Digana commented on SUREFIRE-1631:
we are reporting some errors in the dump files. You can find them in
{{target/surefire-reports}} and the files have date and {{dump}} in the name.
> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?" messages when running unit tests in
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
> * Reboot / Cold boot (happens first thing on Monday morning when I come into
> the office and turn on my PC).
> * More free memory (happens when I only have a single window open). I have
> 16GB of RAM.
> * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
> * Different versions of the Surefire plugin or Maven
> * Different JDK 8 builds
> Things that affect the bug:
> * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
> * Redirecting all log output to a file using logback-test.xml
> * Running Surefire with forkCount=0
> * Running a subset of the tests (-Dtest=...)
> * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker
> and uses a shutdown hook to stop it. So I created a small test project which
> demonstrates that Surefire will sometimes cut off stdout. I think that
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between
> the surefire child VM and main Maven process. ActiveMQ might be worse since
> it stops threads and execution pools (so the output comes slowly with a
> couple of exceptions sprinkled in when one component loses connection because
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies)
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster
> than printing on a terminal. The strange part is that the log file is about
> the same size but 30% of the tests haven't run. Most tests log a lot, do I
> would expect to see a difference of at least a few MB. The Maven part (which
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the
> communication between parent and child would help. Also the parent should
> terminate the child and then read stdout until EOF to we can see anything
> that happens afterwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963403#comment-16963403
]
Tibor Digana commented on SUREFIRE-1631:
Can you try with the development version {{3.0.0-SNAPSHOT}}?
> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1
>Reporter: Aaron Digulla
>Assignee: Tibor Digana
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?" messages when running unit tests in
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
> * Reboot / Cold boot (happens first thing on Monday morning when I come into
> the office and turn on my PC).
> * More free memory (happens when I only have a single window open). I have
> 16GB of RAM.
> * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
> * Different versions of the Surefire plugin or Maven
> * Different JDK 8 builds
> Things that affect the bug:
> * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
> * Redirecting all log output to a file using logback-test.xml
> * Running Surefire with forkCount=0
> * Running a subset of the tests (-Dtest=...)
> * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker
> and uses a shutdown hook to stop it. So I created a small test project which
> demonstrates that Surefire will sometimes cut off stdout. I think that
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between
> the surefire child VM and main Maven process. ActiveMQ might be worse since
> it stops threads and execution pools (so the output comes slowly with a
> couple of exceptions sprinkled in when one component loses connection because
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies)
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster
> than printing on a terminal. The strange part is that the log file is about
> the same size but 30% of the tests haven't run. Most tests log a lot, do I
> would expect to see a difference of at least a few MB. The Maven part (which
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the
> communication between parent and child would help. Also the parent should
> terminate the child and then read stdout until EOF to we can see anything
> that happens afterwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963370#comment-16963370 ] Aaron Digulla commented on SUREFIRE-1631: - Just some notes: # My test doesn't call exit() at any time. I've set a breakpoint at Runtime.exit() which was never hit. # It happens often on Windows (I was using 10). I've seen it on Jenkins but I don't remember if the slave was running Linux or Windows. # I've only seen it with recent versions of Java 8 (after u81, I *think*) # It's a brittle error. Sometimes, you don't get it for weeks. Then every build fails. Sometimes reboot helps, sometimes not. I understand that you closed the bug but I doubt it's fixed. It's probably a weird bug that happens with a combination of Oracle Java 8, Windows and IPC which makes the VM crash/terminate *without* writing any crash logs. It's not related to Spring or Docker and I'm not using either in my project (well, I'm using the Spring JMS template but no application context). I've sunk about a week's worth of time into the bug and I still have no idea what happens. Might be a JIT bug or I don't know. Very frustrating. > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-547965436 @Col-E @Seijan IMO the problem would be in the filter. Maybe the name of test method is `myTest[0]` instead of `myTest`. My guess. Having the IT would show us the root cause in debugger. 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-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-547962196 @Seijan I agree with you that parameterized tests are very important. Would you write an integration test in our project and show us how this feature works together with the parameterized tests? If we see the test result, we can better understand the problem and make a fix. Maybe worth to start with parameterized test first without this feature and then continue with second IT having this feature. And we can see the difference. 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] [Comment Edited] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963114#comment-16963114
]
Michael Osipov edited comment on WAGON-568 at 10/30/19 3:22 PM:
My bad, it should have been BAIS. I cannot fully isolate the issue with the
copy loop, it must be related to the channels and the socket output stream, but
I was able to modiy a Wagon unit test for this. Please check out from the Wagon
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient
blocks for some reason during read and Jetty issues a {{TimeoutException}}
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient
expect to instantly fail with {{Cannot retry non-repeatable request}} as
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.
was (Author: michael-o):
My bad, it should have been BAIS. I cannot fully isolate the issue which the
copy loop, it must be related to the channels and the socket output stream. But
I was able to modiy a Wagon unit test for this. Please check out from the Wagon
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire
output includes complete wire logging.
The input streams are reusing w/o being reset (programming error). HttpClient
blocks for some reason during read and Jetty issues a {{TimeoutException}}
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient
expect to instantly fail with {{Cannot retry non-repeatable request}} as
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963114#comment-16963114
]
Michael Osipov edited comment on WAGON-568 at 10/30/19 3:22 PM:
My bad, it should have been BAIS. I cannot fully isolate the issue with the
copy loop, it must be related to the channels and the socket output stream, but
I was able to modiy a Wagon unit test for this. Please check out from the Wagon
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient
blocks for some reason during read and Jetty issues a {{TimeoutException}}
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient
expect to instantly fail with {{Cannot retry non-repeatable request}} as
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.
Before I fix Wagon code, I want to understand why HttpClient blocks here.
was (Author: michael-o):
My bad, it should have been BAIS. I cannot fully isolate the issue with the
copy loop, it must be related to the channels and the socket output stream, but
I was able to modiy a Wagon unit test for this. Please check out from the Wagon
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient
blocks for some reason during read and Jetty issues a {{TimeoutException}}
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient
expect to instantly fail with {{Cannot retry non-repeatable request}} as
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963114#comment-16963114
]
Michael Osipov commented on WAGON-568:
--
My bad, it should have been BAIS. I cannot fully isolate the issue which the
copy loop, it must be related to the channels and the socket output stream. But
I was able to modiy a Wagon unit test for this. Please check out from the Wagon
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire
output includes complete wire logging.
The input streams are reusing w/o being reset (programming error). HttpClient
blocks for some reason during read and Jetty issues a {{TimeoutException}}
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient
expect to instantly fail with {{Cannot retry non-repeatable request}} as
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963003#comment-16963003
]
Anton commented on ARCHETYPE-573:
--
Please up the priority of this bug. Very annoying.
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963003#comment-16963003
]
Anton edited comment on ARCHETYPE-573 at 10/30/19 1:02 PM:
Please up the priority of this bug. It's very annoying.
was (Author: popalka):
Please up the priority of this bug. Very annoying.
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Seijan commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Seijan commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-547872792 Did you check how this feature works with parameterized tests from JUnit5? I know it's an experimental feature, but we use it quite a lot in our environment. As off now I tried it myself with the latest snapshot version and with a few simple tests, with the results that parameterized tests aren't rerun when they fail, and if one of the tests does succeed the whole test case is marked as a success. This does defy the purpose of the parameterized tests, as they test different behaviours in our case. 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] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4
[
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962847#comment-16962847
]
Oleg Kalnichevski commented on WAGON-568:
-
[~michael-o] BAOS or BAIS? I do not see anything obviously wrong with the bit
of code. Is there any chance to reproduce this issue locally? Can you put
together a test app or a Docker image?
Oleg
> Fail to deploy on Sonatype OSS since maven 3.5.4
>
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum
> files. I have no idea where those would come from, as far as I know, those
> are generated by the maven repository.
>
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @
> async-http-client-project ---
> Uploading to sonatype-nexus-staging:
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
> null{code}
>
>
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
> against Sonatype OSS describing the exact same behavior and stating
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a
> maven regression to me.
> * maven 3.6.2: fails
> * maven 3.5.4: fails
> * maven 3.5.3: works like a charm
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
