[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[ https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839834#comment-17839834 ] Rocher Suchard edited comment on MWRAPPER-133 at 4/22/24 8:28 PM: -- {quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote} I will try to see what wrapper script really receive (I assume it should contains something like {{-s }} but if this was really duplicated on our jenkins, I would have no need for this issue (I don't have access to the Jenkins plugin version). was (Author: rocher.suchard): {quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote} I will try to see what wrapper script really receive (I assume it should MAVEN_CONFIG contains something like {{-s }} but if this was really duplicated on our jenkins, I would have no need for this issue (I don't have access to the Jenkins plugin version). > MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read, > --- > > Key: MWRAPPER-133 > URL: https://issues.apache.org/jira/browse/MWRAPPER-133 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.0 >Reporter: Rocher Suchard >Priority: Major > > Hello, > Due to an update by Renovate in one of our project, I've seen some error > related to internal dependencies not being picked up by Maven : while we were > using a custom settings, it did not use it and was using Central instead of > our Artifactory. > Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG > environnement variable here : > https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400 > The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and > I've played around with the default value and type: > {code:bash} > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 > # use scripts-only > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > # nothing > $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 > # use bin > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% % > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin > ... > [INFO] Unpacked bin type wrapper distribution > org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0 > [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6 > and download from https://repo.maven.apache.org/maven2 > ... > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %* > {code} > Is there a way to do the same for the script-only if this is to be the > default ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[ https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839834#comment-17839834 ] Rocher Suchard commented on MWRAPPER-133: - {quote}so data from MAVEN_CONFIG will be duplicated on cmd by old wrapper{quote} I will try to see what wrapper script really receive (I assume it should MAVEN_CONFIG contains something like {{-s }} but if this was really duplicated on our jenkins, I would have no need for this issue (I don't have access to the Jenkins plugin version). > MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read, > --- > > Key: MWRAPPER-133 > URL: https://issues.apache.org/jira/browse/MWRAPPER-133 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.0 >Reporter: Rocher Suchard >Priority: Major > > Hello, > Due to an update by Renovate in one of our project, I've seen some error > related to internal dependencies not being picked up by Maven : while we were > using a custom settings, it did not use it and was using Central instead of > our Artifactory. > Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG > environnement variable here : > https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400 > The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and > I've played around with the default value and type: > {code:bash} > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 > # use scripts-only > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > # nothing > $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 > # use bin > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% % > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin > ... > [INFO] Unpacked bin type wrapper distribution > org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0 > [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6 > and download from https://repo.maven.apache.org/maven2 > ... > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %* > {code} > Is there a way to do the same for the script-only if this is to be the > default ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[ https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839808#comment-17839808 ] Rocher Suchard edited comment on MWRAPPER-133 at 4/22/24 6:16 PM: -- [~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven Wrapper but the MAVEN_CONFIG is not something from Maven, but something found in the wrapper script directly (I do not check the cmd part because even as a Windows user, I loath to use batch and cmd file :)) : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} versus {code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6} exec_maven() { unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || : exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec $MAVEN_HOME/bin/$MVN_CMD" } {code} As show above, {{$MAVEN_CONFIG}} is not there but it is present in the wrapper script in 3.2.0 : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint, removing MAVEN_CONFIG is forcing user to 1) either stay with maven wrapper 3.2.0 2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) = complicated. was (Author: rocher.suchard): [~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven Wrapper but the MAVEN_CONFIG is not something from Maven, but something found in the wrapper script directly (I do not check the cmd part because even as a Windows user, I loath to use batch and cmd file :)) : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} versus {code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6} exec_maven() { unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || : exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec $MAVEN_HOME/bin/$MVN_CMD" } {code} The {{$MAVEN_CONFIG}} is not there but it is present in the wrapper script in 3.2.0 : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint, removing MAVEN_CONFIG is forcing user to 1) either stay with maven wrapper 3.2.0 2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) = complicated. > MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read, > --- > > Key: MWRAPPER-133 > URL: https://issues.apache.org/jira/browse/MWRAPPER-133 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.0 >Reporter: Rocher Suchard >Priority: Major > > Hello, > Due to an update by Renovate in one of our project, I've seen some error > related to internal dependencies not being picked up by Maven : while we were > using a custom settings, it did not use it and was using Central instead of > our Artifactory. > Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG > environnement variable here : > https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400 > The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and > I've played around with the default value and type: > {code:bash} > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 > # use scripts-only > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > # nothing > $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 > # use bin > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPE
[jira] [Commented] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
[ https://issues.apache.org/jira/browse/MWRAPPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839808#comment-17839808 ] Rocher Suchard commented on MWRAPPER-133: - [~sjaranowski] I don't know the history behind Jenkins Maven Pipeline and Maven Wrapper but the MAVEN_CONFIG is not something from Maven, but something found in the wrapper script directly (I do not check the cmd part because even as a Windows user, I loath to use batch and cmd file :)) : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=bin} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} versus {code:bash|title=mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6} exec_maven() { unset MVNW_VERBOSE MVNW_USERNAME MVNW_PASSWORD MVNW_REPOURL || : exec "$MAVEN_HOME/bin/$MVN_CMD" "$@" || die "cannot exec $MAVEN_HOME/bin/$MVN_CMD" } {code} The {{$MAVEN_CONFIG}} is not there but it is present in the wrapper script in 3.2.0 : {code:bash|title=mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 -Dtype=script} # shellcheck disable=SC2086 # safe args exec "$JAVACMD" \ $MAVEN_OPTS \ $MAVEN_DEBUG_OPTS \ -classpath "$MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar" \ "-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \ ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" {code} If there is a maven alternative (MAVEN_ARGS) why not, but from user standpoint, removing MAVEN_CONFIG is forcing user to 1) either stay with maven wrapper 3.2.0 2) either upgrade Jenkins or its maven pipeline (or other kind of pipeline) = complicated. > MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read, > --- > > Key: MWRAPPER-133 > URL: https://issues.apache.org/jira/browse/MWRAPPER-133 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.3.0 >Reporter: Rocher Suchard >Priority: Major > > Hello, > Due to an update by Renovate in one of our project, I've seen some error > related to internal dependencies not being picked up by Maven : while we were > using a custom settings, it did not use it and was using Central instead of > our Artifactory. > Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG > environnement variable here : > https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400 > The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and > I've played around with the default value and type: > {code:bash} > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 > # use scripts-only > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > # nothing > $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 > # use bin > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% % > $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin > ... > [INFO] Unpacked bin type wrapper distribution > org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0 > [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6 > and download from https://repo.maven.apache.org/maven2 > ... > $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ > mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" > mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" > mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %* > {code} > Is there a way to do the same for the script-only if this is to be the > default ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-133) MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read,
Rocher Suchard created MWRAPPER-133: --- Summary: MAVEN_CONFIG populated by Jenkins Maven Pipeline is no longer read, Key: MWRAPPER-133 URL: https://issues.apache.org/jira/browse/MWRAPPER-133 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Scripts Affects Versions: 3.3.0 Reporter: Rocher Suchard Hello, Due to an update by Renovate in one of our project, I've seen some error related to internal dependencies not being picked up by Maven : while we were using a custom settings, it did not use it and was using Central instead of our Artifactory. Upon analysis, it seems that Maven Pipeline define a MAVEN_CONFIG environnement variable here : https://github.com/jenkinsci/pipeline-maven-plugin/blob/8cfaff9c021c971d19e5469c553a86d954c05387/pipeline-maven/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L400 The MAVEN_CONFIG variables was used in our Maven 3.2.0 Wrapper script and I've played around with the default value and type: {code:bash} $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 # use scripts-only $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ # nothing $ mvn wrapper:3.2.0:wrapper -Dmaven=3.9.6 # use bin $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% % $ mvn wrapper:3.3.0:wrapper -Dmaven=3.9.6 -Dtype=bin ... [INFO] Unpacked bin type wrapper distribution org.apache.maven.wrapper:maven-wrapper-distribution:zip:bin:3.3.0 [INFO] Configuring .mvn/wrapper/maven-wrapper.properties to use Maven 3.9.6 and download from https://repo.maven.apache.org/maven2 ... $ grep -r MAVEN_CONFIG mvnw mvnw.cmd .mvn/ mvnw:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $*" mvnw: ${WRAPPER_LAUNCHER} $MAVEN_CONFIG "$@" mvnw.cmd: %WRAPPER_LAUNCHER% %MAVEN_CONFIG% %* {code} Is there a way to do the same for the script-only if this is to be the default ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-973) Please keep the property performRelease or provide an alternative for it
[ https://issues.apache.org/jira/browse/MRELEASE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467415#comment-17467415 ] Rocher Suchard commented on MRELEASE-973: - Hello, I'd like first to comment this was not my issue: I simply commented with the fact that [~rfscholte] reply can't work due to MRELEASE-1038 As I'm using the to enable gpg plugin, I can say this alternative work and that I no longer have the "The requested profile "pom.xml" could not be activated because it does not exist.". => For me, not from [~o.b.fischer] view point, the MRELEASE-1038 is fixed and this one is fixed due to that. Rocher > Please keep the property performRelease or provide an alternative for it > > > Key: MRELEASE-973 > URL: https://issues.apache.org/jira/browse/MRELEASE-973 > Project: Maven Release Plugin > Issue Type: Wish > Components: perform >Affects Versions: 3.0.0-M1 >Reporter: Oliver B. Fischer >Priority: Critical > Labels: compatibility, feature > Fix For: waiting-for-feedback > > > MRELEASE-896 deprecates the {{useReleaseProfile}} and changed its default > value from {{true}} to {{false}}. > Unfortunately this disabled also the setting of the property > {{performRelease}} which we use to enable multiple profiles during the > release process. > At least we need a possibility to enable multiple, sometimes different, > profiles during a release and its preparation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MCOMPILER-478) testCompile with specific module-info.java partially copy target/classes to target/test-classes
[ https://issues.apache.org/jira/browse/MCOMPILER-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rocher Suchard updated MCOMPILER-478: - Description: Hello, I am trying to understand how I can fix this particular bug that occurs while compiling test sources with {{src/test/java/module-info.java}} (or {{src/test/jpms/module-info.java}} in my case because this would make Eclipse fails, due to having two module-info.java). The {{module-info}} that I put in {{src/test/jpms}} is more or less the same as {{{}src/main/jpms{}}}, but with some test modules (like {{{}org.opentest4j{}}}, {{{}org.junit.jupiter.api{}}}, and {{{}org.assertj.core{}}}). This is pretty much what is explained here at the end of page: [https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html#]. When I try to run tests, maven-surefire-plugin fails: the JVM is not happy about a package not found. {code:java} # Created at 2021-12-26T23:43:40.644 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Error occurred during initialization of boot layer'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'java.lang.module.FindException: Error reading module:'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream '...\target\test-classes'. # Created at 2021-12-26T23:43:40.648 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Caused by: java.lang.module.InvalidModuleDescriptorException:'. # Created at 2021-12-26T23:43:40.649 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Package org.acme.functions not found in module'. {code} At first, I thought it was something related to maven-surefire-plugin and I wanted to create a SUREFIRE JIRA issue, but I discovered that something - I presume maven-compiler-plugin - is copying used classes from {{target/classes}} to {{target/test-classes}} during test compilation. In the case of my interface, it is not used and I presume the "something" that I speak about do partial copy of used files during compilation. If we edit the src\main\java\org\acme\impl\AImpl.java to use the interface (should be commented in the attached ZIP): {code:java} public class AImpl implements A { @Override public void doSomethingCool() { org.acme.functions.BooleanConsumer bc = v -> {}; throw new UnsupportedOperationException("no doing something cool"); } } {code} The class file is copied and surefire does not fail. The attached ZIP file exhibit the problem : If we simply compile with tests: {{{}mvn install{}}}: {{maven-surefire-plugin}} will fails to execute test because of missing package. I could probably remove the offending package from test/module-info but I don't think I should tinker to much : the test/module-info should really "extends" the main/module-info and only add packages/modules. If we skip test : {{{}mvn install -DskipTests{}}}: {{maven-jar-plugin}} will fails to execute to process due to a jar error {_}(jar: Package org.acme.functions missing from ModulePackages class file attribute{_}){_}.{_} A solution to both issues would be to create dedicated tests project, with its own module-info.java and another module name (eg: org.acme.tests) but that would no longer be a (modular) white box testing. *Note :* the attached project requires Maven 3.8.4 (there is a maven wrapper inside) and Java 17. I don't know if this fail with Java 11. was: Hello, I am trying to understand how I can fix this particular bug that occurs while compiling test sources with {{src/test/java/module-info.java}} (or {{src/test/jpms/module-info.java}} in my case because this would make Eclipse fails, due to having two module-info.java). The {{module-info}} that I put in {{src/test/jpms}} is more or less the same as {{{}src/main/jpms{}}}, but with some test modules (like {{{}org.opentest4j{}}}, {{{}org.junit.jupiter.api{}}}, and {{{}org.assertj.core{}}}). This is pretty much what is explained here at the end of page: [https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html#]. When I try to run tests, maven-surefire-plugin fails: the JVM is not happy about a package not found. {code:java} # Created at 2021-12-26T23:43:40.644 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Error occurred during initialization of boot layer'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'java.lang.module.FindException: Error reading module:'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream '...\target\test-classes'. # Created at 2021-12-26T23:43:40.648 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Str
[jira] [Created] (MCOMPILER-478) testCompile with specific module-info.java partially copy target/classes to target/test-classes
Rocher Suchard created MCOMPILER-478: Summary: testCompile with specific module-info.java partially copy target/classes to target/test-classes Key: MCOMPILER-478 URL: https://issues.apache.org/jira/browse/MCOMPILER-478 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.8.1 Reporter: Rocher Suchard Attachments: surefire-empty-packages.zip Hello, I am trying to understand how I can fix this particular bug that occurs while compiling test sources with {{src/test/java/module-info.java}} (or {{src/test/jpms/module-info.java}} in my case because this would make Eclipse fails, due to having two module-info.java). The {{module-info}} that I put in {{src/test/jpms}} is more or less the same as {{{}src/main/jpms{}}}, but with some test modules (like {{{}org.opentest4j{}}}, {{{}org.junit.jupiter.api{}}}, and {{{}org.assertj.core{}}}). This is pretty much what is explained here at the end of page: [https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html#]. When I try to run tests, maven-surefire-plugin fails: the JVM is not happy about a package not found. {code:java} # Created at 2021-12-26T23:43:40.644 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Error occurred during initialization of boot layer'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'java.lang.module.FindException: Error reading module:'. # Created at 2021-12-26T23:43:40.647 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream '...\target\test-classes'. # Created at 2021-12-26T23:43:40.648 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Caused by: java.lang.module.InvalidModuleDescriptorException:'. # Created at 2021-12-26T23:43:40.649 Corrupted STDOUT by directly writing to native stream in forked JVM 1. Stream 'Package org.acme.functions not found in module'. {code} At first, I thought it was something related to maven-surefire-plugin and I wanted to create a SUREFIRE JIRA issue, but I discovered that something - I presume maven-compiler-plugin - is copying used classes from {{target/classes}} to {{target/test-classes}} during test compilation. In the case of my interface, it is not used and I presume the "something" that I speak about do partial copy of used files during compilation. If we edit the src\main\java\org\acme\impl\AImpl.java to use the interface (should be commented in the attached ZIP): {code:java} public class AImpl implements A { @Override public void doSomethingCool() { org.acme.functions.BooleanConsumer bc = v -> {}; throw new UnsupportedOperationException("no doing something cool"); } } {code} The class file is copied and surefire does not fail. The attached ZIP file exhibit the problem : If we simply compile with tests: {{{}mvn install{}}}: {{maven-surefire-plugin}} will fails to execute test because of missing package. I could probably remove the offending package from test/module-info but I don't think I should tinker to much : the test/module-info should really "extends" the main/module-info and only add packages/modules. If we skip test : {{{}mvn install -DskipTests{}}}: {{maven-jar-plugin}} will fails to execute to process due to a jar error {_}(jar: Package org.acme.functions missing from ModulePackages class file attribute{_}){_}.{_} A solution to both issues would be to create dedicated tests project, with its own module-info.java and another module name (eg: org.acme.tests). *Note :* the attached project requires Maven 3.8.4 (there is a maven wrapper inside) and Java 17. I don't know if this fail with Java 11. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MCOMPILER-435) Plugin does not report actual error from ErrorProne when toolchain is used
Rocher Suchard created MCOMPILER-435: Summary: Plugin does not report actual error from ErrorProne when toolchain is used Key: MCOMPILER-435 URL: https://issues.apache.org/jira/browse/MCOMPILER-435 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.8.1 Environment: Windows, Maven 3.6.3 Reporter: Rocher Suchard Attachments: maven-compiler-plugin-3.8.1-error-prone.zip Hello, I followed ErrorProne installation ([http://errorprone.info/docs/installation] and [http://errorprone.info/docs/patching]) but I did not provide a {{-XepPatchCheck}} which result in an error that {{maven-compiler-plugin}} fails to report when a toolchain is used: Without a toolchain, I get this error which is what I expect, eg: something that helps! {code:java} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project maven-compiler-plugin-error-prone: Fatal error compiling: -XepPatchChecks and -XepPatchLocation must be specif ied together -> [Help 1] {code} With a JDK 11 toolchain, the error won't help, neither the (huge) stacktrace when using {{-e}}. {code:java} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project maven-compiler-plugin-error-prone: Compilation failure -> [Help 1] {code} {{maven-compiler-plugin}} is unable to report correctly the {{com.google.errorprone.InvalidCommandLineOptionException}} thrown by ErrorProne when a toolchain is used (in this case, the toolchain is useless, but I have profile with Java 15). The attached file contains a sample project: - To test the case when it reports the ErrorProne exception, simply do {{./mvnw clean install}} - To test the case with a JDK 11 toolchain, simply do {{./mvnw -Puse-toolchain clean install}} Java 11 is both required to build, and as a toolchain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRELEASE-973) Please keep the property performRelease or provide an alternative for it
[ https://issues.apache.org/jira/browse/MRELEASE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024761#comment-17024761 ] Rocher Suchard commented on MRELEASE-973: - [~rfscholte]: for this alternative to work, the MRELEASE-1038 must be fixed before. Which is not, at least it is not available as 3.0.0-M2 :) > Please keep the property performRelease or provide an alternative for it > > > Key: MRELEASE-973 > URL: https://issues.apache.org/jira/browse/MRELEASE-973 > Project: Maven Release Plugin > Issue Type: Wish > Components: perform >Affects Versions: 3.0.0-M1 >Reporter: Oliver B. Fischer >Priority: Critical > Labels: compatibility, feature > Fix For: 3.0.0 > > > MRELEASE-896 deprecates the {{useReleaseProfile}} and changed its default > value from {{true}} to {{false}}. > Unfortunately this disabled also the setting of the property > {{performRelease}} which we use to enable multiple profiles during the > release process. > At least we need a possibility to enable multiple, sometimes different, > profiles during a release and its preparation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRELEASE-1038) releaseProfiles get overriden by exec.pomFileName
[ https://issues.apache.org/jira/browse/MRELEASE-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17024760#comment-17024760 ] Rocher Suchard commented on MRELEASE-1038: -- The fact that the {{performRelease}} was removed and this issue is problematic: I was using the {{performRelease}} to trigger the {{maven-gpg-plugin}}. The alternative does not work and is pretty annoying due to this message: {code:java} [INFO] [WARNING] The requested profile "pom.xml" could not be activated because it does not exist. {code} For those interested in testing maven-release-plugin 3.0.0.M1, this can be fixed like this: {code:xml} org.apache.maven.plugins maven-release-plugin 3.0.0-M1 v@{project.version} true -Prelease-sign-artifacts {code} However the plugin will get executed in the verify phase of the release:prepare as well. > releaseProfiles get overriden by exec.pomFileName > - > > Key: MRELEASE-1038 > URL: https://issues.apache.org/jira/browse/MRELEASE-1038 > Project: Maven Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 3.0.0-M1 >Reporter: Benoit MESSAGER >Priority: Minor > > Profiles specified in . are overrided by the > pom file name. > This come from : org.apache.maven.shared.release.config.ReleaseUtils line 130 > : > {code:java} > if ( properties.containsKey( "exec.activateProfiles" ) ) > { > builder.setActivateProfiles( Arrays.asList( properties.getProperty( > "exec.pomFileName" ).split( "," ) ) ); > } > {code} > this look like a failed copy/paste > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5811) Display the time of execution for each participant of the build
[ https://issues.apache.org/jira/browse/MNG-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837637#comment-16837637 ] Rocher Suchard commented on MNG-5811: - Hello, I did try https://github.com/jcgay/maven-profiler and it works like a charm. The report is in HTML, not in the terminal, but that probably for the best: I often clean my terminal or reuse it, loosing all that timing. By the way, the author of this extension also made https://github.com/jcgay/maven-notifier : while I did not try it yet, it propose to send a notification when the build is done. Thanks, You may close this ticket (I don't have access to it). > Display the time of execution for each participant of the build > --- > > Key: MNG-5811 > URL: https://issues.apache.org/jira/browse/MNG-5811 > Project: Maven > Issue Type: Improvement > Components: General >Affects Versions: 3.2.5, 3.3.1 >Reporter: Rocher Suchard >Priority: Minor > Labels: features > > Hello, > When working with projet with a lots of plugins bundled in different phase, > I'd find rather interesting to have the execution time of such plugin, like > you have the execution time of each project in a multi module project. > The major use of such feature is to determine the plugins that takes too much > time in the build process and possibly to correct them. > For an example of what I want, compare the two output : > - default log (on any project, this is not relevant here) : > {code} > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Application ... SUCCESS [ 0.768 s] > [INFO] apps-common ... SUCCESS [ 3.649 s] > [INFO] apps-template-plugin .. SUCCESS [ 6.665 s] > [INFO] apps-general .. SUCCESS [ 12.627 s] > [INFO] apps-console .. SUCCESS [ 0.384 s] > [INFO] GUI Tools . SUCCESS [ 1.059 s] > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 25.330 s > [INFO] Finished at: 2015-04-27T22:46:54+02:00 > [INFO] Final Memory: 47M/613M > [INFO] > > {code} > - "enhanced" logs : > {code} > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Application > ... SUCCESS [ 0.768 > s] > [INFO] apps-common > ... SUCCESS [ 3.649 > s] > [INFO] apps-template-plugin > .. SUCCESS [ 6.665 s] > [INFO] apps-general > .. SUCCESS [ 12.627 s] > [INFO] apps-console > .. SUCCESS [ 0.384 s] > [INFO] GUI Tools > . SUCCESS [ > 1.059 s] > [INFO] - maven-clean-plugin:2.6.1:clean > ... SUCCESS [ 1.000 s] > [INFO] - maven-resources-plugin:2.6:resources (default-resources) > ... SUCCESS [ 1.000 s] > [INFO] - maven-compiler-plugin:2.0.2:compile (default-compile) > ... SUCCESS [ 1.000 s] > [INFO] - maven-resources-plugin:2.6:testResources (default-testResources) > ... SUCCESS [ 1.000 s] > [INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile) > ... SUCCESS [ 1.000 s] > [INFO] - maven-surefire-plugin:2.12.4:test (default-test) > ... SUCCESS [ 1.000 s] > [INFO] - maven-jar-plugin:2.4:jar (default-jar) > ... SUCCESS [ 1.000 s] > [INFO] - maven-install-plugin:2.4:install (default-install) > ... SUCCESS [ 1.000 s] > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 25.330 s > [INFO] Finished at: 2015-04-27T22:46:54+02:00 > [INFO] Final Memory: 47M/613M > [INFO] > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-5811) Display the time of execution for each participant of the build
[ https://issues.apache.org/jira/browse/MNG-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837637#comment-16837637 ] Rocher Suchard edited comment on MNG-5811 at 5/10/19 9:51 PM: -- Hello, I did try https://github.com/jcgay/maven-profiler and it works like a charm. The report is in HTML, not in the terminal, but that probably for the best: I often clean my terminal or reuse it, loosing all that timing. By the way, the author of this extension also made https://github.com/jcgay/maven-notifier : while I did not try it yet, it propose to send a notification when the build is done. Thanks, You may close this ticket (I don't have access to it). Regards, Rocher S. was (Author: rocher.suchard): Hello, I did try https://github.com/jcgay/maven-profiler and it works like a charm. The report is in HTML, not in the terminal, but that probably for the best: I often clean my terminal or reuse it, loosing all that timing. By the way, the author of this extension also made https://github.com/jcgay/maven-notifier : while I did not try it yet, it propose to send a notification when the build is done. Thanks, You may close this ticket (I don't have access to it). > Display the time of execution for each participant of the build > --- > > Key: MNG-5811 > URL: https://issues.apache.org/jira/browse/MNG-5811 > Project: Maven > Issue Type: Improvement > Components: General >Affects Versions: 3.2.5, 3.3.1 >Reporter: Rocher Suchard >Priority: Minor > Labels: features > > Hello, > When working with projet with a lots of plugins bundled in different phase, > I'd find rather interesting to have the execution time of such plugin, like > you have the execution time of each project in a multi module project. > The major use of such feature is to determine the plugins that takes too much > time in the build process and possibly to correct them. > For an example of what I want, compare the two output : > - default log (on any project, this is not relevant here) : > {code} > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Application ... SUCCESS [ 0.768 s] > [INFO] apps-common ... SUCCESS [ 3.649 s] > [INFO] apps-template-plugin .. SUCCESS [ 6.665 s] > [INFO] apps-general .. SUCCESS [ 12.627 s] > [INFO] apps-console .. SUCCESS [ 0.384 s] > [INFO] GUI Tools . SUCCESS [ 1.059 s] > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > [INFO] Total time: 25.330 s > [INFO] Finished at: 2015-04-27T22:46:54+02:00 > [INFO] Final Memory: 47M/613M > [INFO] > > {code} > - "enhanced" logs : > {code} > [INFO] > > [INFO] Reactor Summary: > [INFO] > [INFO] Application > ... SUCCESS [ 0.768 > s] > [INFO] apps-common > ... SUCCESS [ 3.649 > s] > [INFO] apps-template-plugin > .. SUCCESS [ 6.665 s] > [INFO] apps-general > .. SUCCESS [ 12.627 s] > [INFO] apps-console > .. SUCCESS [ 0.384 s] > [INFO] GUI Tools > . SUCCESS [ > 1.059 s] > [INFO] - maven-clean-plugin:2.6.1:clean > ... SUCCESS [ 1.000 s] > [INFO] - maven-resources-plugin:2.6:resources (default-resources) > ... SUCCESS [ 1.000 s] > [INFO] - maven-compiler-plugin:2.0.2:compile (default-compile) > ... SUCCESS [ 1.000 s] > [INFO] - maven-resources-plugin:2.6:testResources (default-testResources) > ... SUCCESS [ 1.000 s] > [INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile) > ... SUCCESS [ 1.000 s] > [INFO] - maven-surefire-plugin:2.12.4:test (default-test) > ... SUCCESS [ 1.000 s] > [INFO] - maven-jar-plugin:2.4:jar (default-jar) > ... SUCCESS [ 1.000 s] > [INFO] - maven-install-plugin:2.4:install (default-install) > ... SUCCESS [ 1.000 s] > [INFO] >
[jira] [Created] (MNG-5811) Display the time of execution for each participant of the build
Rocher Suchard created MNG-5811: --- Summary: Display the time of execution for each participant of the build Key: MNG-5811 URL: https://issues.apache.org/jira/browse/MNG-5811 Project: Maven Issue Type: Improvement Components: General Affects Versions: 3.3.1, 3.2.5 Reporter: Rocher Suchard Priority: Minor Hello, When working with projet with a lots of plugins bundled in different phase, I'd find rather interesting to have the execution time of such plugin, like you have the execution time of each project in a multi module project. The major use of such feature is to determine the plugins that takes too much time in the build process and possibly to correct them. For an example of what I want, compare the two output : - default log (on any project, this is not relevant here) : {code} [INFO] [INFO] Reactor Summary: [INFO] [INFO] Application ... SUCCESS [ 0.768 s] [INFO] apps-common ... SUCCESS [ 3.649 s] [INFO] apps-template-plugin .. SUCCESS [ 6.665 s] [INFO] apps-general .. SUCCESS [ 12.627 s] [INFO] apps-console .. SUCCESS [ 0.384 s] [INFO] GUI Tools . SUCCESS [ 1.059 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 25.330 s [INFO] Finished at: 2015-04-27T22:46:54+02:00 [INFO] Final Memory: 47M/613M [INFO] {code} - "enhanced" logs : {code} [INFO] [INFO] Reactor Summary: [INFO] [INFO] Application ... SUCCESS [ 0.768 s] [INFO] apps-common ... SUCCESS [ 3.649 s] [INFO] apps-template-plugin .. SUCCESS [ 6.665 s] [INFO] apps-general .. SUCCESS [ 12.627 s] [INFO] apps-console .. SUCCESS [ 0.384 s] [INFO] GUI Tools . SUCCESS [ 1.059 s] [INFO] - maven-clean-plugin:2.6.1:clean ... SUCCESS [ 1.000 s] [INFO] - maven-resources-plugin:2.6:resources (default-resources) ... SUCCESS [ 1.000 s] [INFO] - maven-compiler-plugin:2.0.2:compile (default-compile)... SUCCESS [ 1.000 s] [INFO] - maven-resources-plugin:2.6:testResources (default-testResources) ... SUCCESS [ 1.000 s] [INFO] - maven-compiler-plugin:2.0.2:testCompile (default-testCompile)... SUCCESS [ 1.000 s] [INFO] - maven-surefire-plugin:2.12.4:test (default-test) ... SUCCESS [ 1.000 s] [INFO] - maven-jar-plugin:2.4:jar (default-jar) ... SUCCESS [ 1.000 s] [INFO] - maven-install-plugin:2.4:install (default-install) ... SUCCESS [ 1.000 s] [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 25.330 s [INFO] Finished at: 2015-04-27T22:46:54+02:00 [INFO] Final Memory: 47M/613M [INFO] {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)