[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=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=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=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: ${WRAPPER_LAUNCHER}
[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=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=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.
[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=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=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=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=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]
>
> [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)
