[jira] [Created] (MCLEAN-104) Fast mode causes NullPointerException when building in quiet mode (-q)
Falko Modler created MCLEAN-104:
---
Summary: Fast mode causes NullPointerException when building in
quiet mode (-q)
Key: MCLEAN-104
URL: https://issues.apache.org/jira/browse/MCLEAN-104
Project: Maven Clean Plugin
Issue Type: Bug
Affects Versions: 3.2.0
Reporter: Falko Modler
{{mvn clean -q -Dmaven.clean.fast}}
{noformat}
[ERROR] Internal error: java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null
at org.apache.maven.plugins.clean.Cleaner$BackgroundCleaner.doSessionEnd
(Cleaner.java:541)
at org.apache.maven.plugins.clean.Cleaner$BackgroundCleaner.sessionEnd
(Cleaner.java:420)
at org.apache.maven.plugins.clean.Cleaner$SpyInvocationHandler.invoke
(Cleaner.java:571)
at jdk.proxy2.$Proxy24.sessionEnded (Unknown Source)
at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire
(DefaultExecutionEventCatapult.java:64)
at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire
(DefaultExecutionEventCatapult.java:42)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:137)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/InternalErrorException
fmo@rdde02kx:~/work/egbr/register/dev3 (dev *)$ mvn -q -Dquick -T1
# Thanks for using OpenAPI Generator. #
# Please consider donation to help us maintain this project 🙏 #
# https://opencollective.com/openapi_generator/donate #
# Thanks for using OpenAPI Generator. #
# Please consider donation to help us maintain
[jira] [Updated] (MCLEAN-104) Fast mode causes NullPointerException when building in quiet mode (-q)
[
https://issues.apache.org/jira/browse/MCLEAN-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCLEAN-104:
Description:
{{mvn clean -q -Dmaven.clean.fast}}
{noformat}
[ERROR] Internal error: java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null
at org.apache.maven.plugins.clean.Cleaner$BackgroundCleaner.doSessionEnd
(Cleaner.java:541)
at org.apache.maven.plugins.clean.Cleaner$BackgroundCleaner.sessionEnd
(Cleaner.java:420)
at org.apache.maven.plugins.clean.Cleaner$SpyInvocationHandler.invoke
(Cleaner.java:571)
at jdk.proxy2.$Proxy24.sessionEnded (Unknown Source)
at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire
(DefaultExecutionEventCatapult.java:64)
at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire
(DefaultExecutionEventCatapult.java:42)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:137)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
{noformat}
Seems the following call is missing a nullcheck:
https://github.com/apache/maven-clean-plugin/blob/maven-clean-plugin-3.2.0/src/main/java/org/apache/maven/plugins/clean/Cleaner.java#L541
Compare with:
https://github.com/apache/maven-clean-plugin/blob/maven-clean-plugin-3.2.0/src/main/java/org/apache/maven/plugins/clean/Cleaner.java#L121
was:
{{mvn clean -q -Dmaven.clean.fast}}
{noformat}
[ERROR] Internal error: java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException: Cannot invoke
"org.apache.maven.plugins.clean.Cleaner$Logger.log(java.lang.CharSequence)"
because the return value of
"org.apache.maven.plugins.clean.Cleaner.access$700(org.apache.maven.plugins.clean.Cleaner)"
is null
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at o
[jira] [Created] (MRELEASE-1114) Broken interaction of maven-gpg-plugin with Gpg4win Kleopatra since 3.0.0-M6
Falko Modler created MRELEASE-1114:
--
Summary: Broken interaction of maven-gpg-plugin with Gpg4win
Kleopatra since 3.0.0-M6
Key: MRELEASE-1114
URL: https://issues.apache.org/jira/browse/MRELEASE-1114
Project: Maven Release Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M7, 3.0.0-M6
Reporter: Falko Modler
Before https://github.com/apache/maven-release/pull/125, when gpg-plugin runs,
it triggered the cert password prompt window of Kleopatra but now it fails
right away with {{no pinentry}}.
See also
https://github.com/apache/maven-release/pull/125#issuecomment-1160398620 and
the following comments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
Falko Modler created SUREFIRE-2258:
--
Summary: Wrongly complains about system property overwritten by
user property when using placeholder
Key: SUREFIRE-2258
URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.4.0
Environment: Apache Maven 3.9.9
(8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
Java version: 21.0.4, vendor: BellSoft, runtime:
/home/fmo/.sdkman/candidates/java/21.0.4-librca
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
Reporter: Falko Modler
After SUREFIRE-1385 the plugin is complaining with:
{quote}
[WARNING] System property [sha1] overwritten by user properties from Maven
session
{quote}
when using:
{code:xml}
${sha1}
{code}
This warning looks wrong to me in this case because I'm explicitly using a
placeholder, not a static value.
For context, I'm setting as project version:
{code:xml}
${revision}.${changelist}${sha1}
{code}
and in project properties:
{code:xml}
{code}
And in direnv {{.envrc}} I have:
{code}
export MAVEN_ARGS="-Dsha1=-dev1"
{code}
(or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877189#comment-17877189
]
Falko Modler commented on SUREFIRE-1385:
FWIW, this check is a bit overzealous when using placeholders: SUREFIRE-2258
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.4.0
>
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
> on SUREFIRE-1385 branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
[
https://issues.apache.org/jira/browse/SUREFIRE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-2258:
---
Description:
After SUREFIRE-1385 the plugin is complaining with:
{quote}[WARNING] System property [sha1] overwritten by user properties from
Maven session
{quote}
when using:
{code:xml}
${sha1}
{code}
This warning looks wrong to me in this case because I'm explicitly using a
placeholder, not a static value.
For context, I'm setting as project version:
{code:xml}
${revision}.${changelist}${sha1}
{code}
and in project properties:
{code:xml}
{code}
And in [direnv|https://direnv.net/] {{.envrc}} I have:
{code:java}
export MAVEN_ARGS="-Dsha1=-dev1"
{code}
(or dev2, dev3 etc., depending on the clone)
was:
After SUREFIRE-1385 the plugin is complaining with:
{quote}
[WARNING] System property [sha1] overwritten by user properties from Maven
session
{quote}
when using:
{code:xml}
${sha1}
{code}
This warning looks wrong to me in this case because I'm explicitly using a
placeholder, not a static value.
For context, I'm setting as project version:
{code:xml}
${revision}.${changelist}${sha1}
{code}
and in project properties:
{code:xml}
{code}
And in direnv {{.envrc}} I have:
{code}
export MAVEN_ARGS="-Dsha1=-dev1"
{code}
(or dev2, dev3 etc., depending on the clone)
> Wrongly complains about system property overwritten by user property when
> using placeholder
> ---
>
> Key: SUREFIRE-2258
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.9.9
> (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
> Java version: 21.0.4, vendor: BellSoft, runtime:
> /home/fmo/.sdkman/candidates/java/21.0.4-librca
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
>Reporter: Falko Modler
>Priority: Major
>
> After SUREFIRE-1385 the plugin is complaining with:
> {quote}[WARNING] System property [sha1] overwritten by user properties from
> Maven session
> {quote}
> when using:
> {code:xml}
>
>
> ${sha1}
>
> {code}
> This warning looks wrong to me in this case because I'm explicitly using a
> placeholder, not a static value.
> For context, I'm setting as project version:
> {code:xml}
> ${revision}.${changelist}${sha1}
> {code}
> and in project properties:
> {code:xml}
>
> {code}
> And in [direnv|https://direnv.net/] {{.envrc}} I have:
> {code:java}
> export MAVEN_ARGS="-Dsha1=-dev1"
> {code}
> (or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
[
https://issues.apache.org/jira/browse/SUREFIRE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-2258:
---
Description:
After SUREFIRE-1385 the plugin is complaining with:
{quote}[WARNING] System property [sha1] overwritten by user properties from
Maven session
{quote}
when using:
{code:xml}
${sha1}
{code}
This warning looks wrong to me in this case because I'm explicitly using a
placeholder, not a static value.
For context, I'm setting as project version (["CI
friendly"|https://maven.apache.org/maven-ci-friendly.html]):
{code:xml}
${revision}.${changelist}${sha1}
{code}
and in project properties:
{code:xml}
{code}
And in [direnv|https://direnv.net/] {{.envrc}} I have:
{code:java}
export MAVEN_ARGS="-Dsha1=-dev1"
{code}
(or dev2, dev3 etc., depending on the clone)
was:
After SUREFIRE-1385 the plugin is complaining with:
{quote}[WARNING] System property [sha1] overwritten by user properties from
Maven session
{quote}
when using:
{code:xml}
${sha1}
{code}
This warning looks wrong to me in this case because I'm explicitly using a
placeholder, not a static value.
For context, I'm setting as project version:
{code:xml}
${revision}.${changelist}${sha1}
{code}
and in project properties:
{code:xml}
{code}
And in [direnv|https://direnv.net/] {{.envrc}} I have:
{code:java}
export MAVEN_ARGS="-Dsha1=-dev1"
{code}
(or dev2, dev3 etc., depending on the clone)
> Wrongly complains about system property overwritten by user property when
> using placeholder
> ---
>
> Key: SUREFIRE-2258
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.9.9
> (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
> Java version: 21.0.4, vendor: BellSoft, runtime:
> /home/fmo/.sdkman/candidates/java/21.0.4-librca
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
>Reporter: Falko Modler
>Priority: Major
>
> After SUREFIRE-1385 the plugin is complaining with:
> {quote}[WARNING] System property [sha1] overwritten by user properties from
> Maven session
> {quote}
> when using:
> {code:xml}
>
>
> ${sha1}
>
> {code}
> This warning looks wrong to me in this case because I'm explicitly using a
> placeholder, not a static value.
> For context, I'm setting as project version (["CI
> friendly"|https://maven.apache.org/maven-ci-friendly.html]):
> {code:xml}
> ${revision}.${changelist}${sha1}
> {code}
> and in project properties:
> {code:xml}
>
> {code}
> And in [direnv|https://direnv.net/] {{.envrc}} I have:
> {code:java}
> export MAVEN_ARGS="-Dsha1=-dev1"
> {code}
> (or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2259) test-jar includes/excludes are not respected when running "mvn test"
Falko Modler created SUREFIRE-2259:
--
Summary: test-jar includes/excludes are not respected when running
"mvn test"
Key: SUREFIRE-2259
URL: https://issues.apache.org/jira/browse/SUREFIRE-2259
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 3.4.0
Environment: Apache Maven 3.9.8
(36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /home/famod/.sdkman/candidates/maven/current
Java version: 21.0.4, vendor: Eclipse Adoptium, runtime:
/home/moldowan/.sdkman/candidates/java/21.0.4-tem
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.15.153.1-microsoft-standard-wsl2", arch: "amd64",
family: "unix"
Reporter: Falko Modler
Attachments: q_testjar-properties.zip
Imagine a multi-module project consisting of two modules:
* module A provides a test-jar
* module B is running tests and depends on the test-jar of A
Module A builds the test-jar like this:
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
3.2.2
test-jar
application.properties
org/acme/**
{code}
So it includes classes under org/acme and application.properties, but that
module also has src/test/resources/application*-test*.properties that is not
included in test-jar.
Now, if running tests in module B (that uses the test-jar of A),
{{application-test.properties}} ist _not_ on the test classpath when running
(from the project root, with our without "clean"):
- mvn install
- mvn package
- mvn test -f B
This is all as expected.
But if just running "mvn test" the {{application-test.properties}} is suddenly
on the classpath, which means that in that case includes/excludes are not
respected.
I've attached a reproducer that I originally built for
[https://github.com/quarkusio/quarkus/issues/42580] which is also where this
issue in surefire was spotted.
In that reproducer, module A is "core" and module B is "dist".
Relevant for this issue is {{SomeTest}} which fails only for "mvn test".
{{SomeQuarkusTest}} is not relevant here.
I'm aware that "test" phase comes before the "package" phase but this is a
nasty inconsistency nonetheless.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
[
https://issues.apache.org/jira/browse/SUREFIRE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877311#comment-17877311
]
Falko Modler commented on SUREFIRE-2258:
Couldn't you consult the raw model and if it's a placeholder don't log the
warning?
> Wrongly complains about system property overwritten by user property when
> using placeholder
> ---
>
> Key: SUREFIRE-2258
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.9.9
> (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
> Java version: 21.0.4, vendor: BellSoft, runtime:
> /home/fmo/.sdkman/candidates/java/21.0.4-librca
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
>Reporter: Falko Modler
>Priority: Major
>
> After SUREFIRE-1385 the plugin is complaining with:
> {quote}[WARNING] System property [sha1] overwritten by user properties from
> Maven session
> {quote}
> when using:
> {code:xml}
>
>
> ${sha1}
>
> {code}
> This warning looks wrong to me in this case because I'm explicitly using a
> placeholder, not a static value.
> For context, I'm setting as project version (["CI
> friendly"|https://maven.apache.org/maven-ci-friendly.html]):
> {code:xml}
> ${revision}.${changelist}${sha1}
> {code}
> and in project properties:
> {code:xml}
>
> {code}
> And in [direnv|https://direnv.net/] {{.envrc}} I have:
> {code:java}
> export MAVEN_ARGS="-Dsha1=-dev1"
> {code}
> (or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
[
https://issues.apache.org/jira/browse/SUREFIRE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878535#comment-17878535
]
Falko Modler edited comment on SUREFIRE-2258 at 9/2/24 9:41 AM:
[~kwin] thanks for the link.
However, I do need to pass {{systemProperties}} explicitly for the following
cases:
- {{-D...}} in {{.mvn/jvm.config}}
- or property only defined in {{pom.xml}} (e.g. a default value that shall be
overridable)
{{-D...}} directly on the command line or via {{MAVEN_ARGS}} do both work
without {{systemProperties}}, as you say.
So if I want to cover all cases I have to use the placeholder approach, no?
was (Author: famod):
[~kwin] thanks for the link.
However, I do need to pass properties explicitly for the following cases:
- {{-D...}} in {{.mvn/jvm.config}}
- or property only defined in {{pom.xml}} (e.g. a default value that shall be
overridable)
{{-D...}} directly on the command line or via {{MAVEN_ARGS}} do both work
without {{systemProperties}}, as you say.
So if I want to cover all cases I have to use the placeholder approach, no?
> Wrongly complains about system property overwritten by user property when
> using placeholder
> ---
>
> Key: SUREFIRE-2258
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.9.9
> (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
> Java version: 21.0.4, vendor: BellSoft, runtime:
> /home/fmo/.sdkman/candidates/java/21.0.4-librca
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
>Reporter: Falko Modler
>Priority: Major
>
> After SUREFIRE-1385 the plugin is complaining with:
> {quote}[WARNING] System property [sha1] overwritten by user properties from
> Maven session
> {quote}
> when using:
> {code:xml}
>
>
> ${sha1}
>
> {code}
> This warning looks wrong to me in this case because I'm explicitly using a
> placeholder, not a static value.
> For context, I'm setting as project version (["CI
> friendly"|https://maven.apache.org/maven-ci-friendly.html]):
> {code:xml}
> ${revision}.${changelist}${sha1}
> {code}
> and in project properties:
> {code:xml}
>
> {code}
> And in [direnv|https://direnv.net/] {{.envrc}} I have:
> {code:java}
> export MAVEN_ARGS="-Dsha1=-dev1"
> {code}
> (or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2258) Wrongly complains about system property overwritten by user property when using placeholder
[
https://issues.apache.org/jira/browse/SUREFIRE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878535#comment-17878535
]
Falko Modler commented on SUREFIRE-2258:
[~kwin] thanks for the link.
However, I do need to pass properties explicitly for the following cases:
- {{-D...}} in {{.mvn/jvm.config}}
- or property only defined in {{pom.xml}} (e.g. a default value that shall be
overridable)
{{-D...}} directly on the command line or via {{MAVEN_ARGS}} do both work
without {{systemProperties}}, as you say.
So if I want to cover all cases I have to use the placeholder approach, no?
> Wrongly complains about system property overwritten by user property when
> using placeholder
> ---
>
> Key: SUREFIRE-2258
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2258
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.9.9
> (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
> Maven home: /home/famod/.sdkman/candidates/maven/3.9.9
> Java version: 21.0.4, vendor: BellSoft, runtime:
> /home/fmo/.sdkman/candidates/java/21.0.4-librca
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-119-generic", arch: "amd64", family: "unix"
>Reporter: Falko Modler
>Priority: Major
>
> After SUREFIRE-1385 the plugin is complaining with:
> {quote}[WARNING] System property [sha1] overwritten by user properties from
> Maven session
> {quote}
> when using:
> {code:xml}
>
>
> ${sha1}
>
> {code}
> This warning looks wrong to me in this case because I'm explicitly using a
> placeholder, not a static value.
> For context, I'm setting as project version (["CI
> friendly"|https://maven.apache.org/maven-ci-friendly.html]):
> {code:xml}
> ${revision}.${changelist}${sha1}
> {code}
> and in project properties:
> {code:xml}
>
> {code}
> And in [direnv|https://direnv.net/] {{.envrc}} I have:
> {code:java}
> export MAVEN_ARGS="-Dsha1=-dev1"
> {code}
> (or dev2, dev3 etc., depending on the clone)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804814#comment-17804814 ] Falko Modler commented on MCOMPILER-391: Heads-up: m2e in Eclipse IDE needs an adjustment to be able to cope with such annotationProcessorPaths without version: https://github.com/eclipse-m2e/m2e-core/issues/1644 > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Assignee: Slawomir Jaranowski >Priority: Blocker > Fix For: 3.12.0 > > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
Falko Modler created MENFORCER-271:
--
Summary: Dependency convergence rule is very slow in larger
projects
Key: MENFORCER-271
URL: https://issues.apache.org/jira/browse/MENFORCER-271
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.4.1
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: C:\Program Files\apache-maven-3.3.9
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: C:\Develop\jdk1.8.0_102\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
Reporter: Falko Modler
Attachments: visualvm.PNG, visualvm_settings.PNG
I noticed that DependencyConvergence can take up to 10 seconds or even more in
modules with almost 300 direct and transitive dependencies (reported by
{{dependency:tree}}).
These modules are part of a JEE project based on JBoss EAP 6.4 which imports a
couple of EAP BOMs. Unfortunately I am not allowed to share this project.
I profiled the rule via VisualVM and these are the top 5 hotspots:
!visualvm.PNG!
The number of {{parseVersion}} calls seems excessive.
See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: visualvm_settings.PNG
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: visualvm.PNG
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-271:
---
Attachment: (was: visualvm.PNG)
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MRRESOURCES-102) Filtering of non-.vm files
Falko Modler created MRRESOURCES-102: Summary: Filtering of non-.vm files Key: MRRESOURCES-102 URL: https://issues.apache.org/jira/browse/MRRESOURCES-102 Project: Maven Remote Resources Plugin Issue Type: New Feature Affects Versions: 1.5 Reporter: Falko Modler It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (which would require some other plugin) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MRRESOURCES-102) Filtering of non-.vm files
[ https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Falko Modler updated MRRESOURCES-102: - Description: It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (fixing this would require some other plugin) was: It would be a very welcomed addition if the plugin would also filter non-verlocity (.vm) files. See also: MRRESOURCES-83 Renaming the files in question to *.vm is not an option for me because: - MRRESOURCES-94 - the module _providing_ the file(s) also needs them _without_ .vm suffix (which would require some other plugin) > Filtering of non-.vm files > -- > > Key: MRRESOURCES-102 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-102 > Project: Maven Remote Resources Plugin > Issue Type: New Feature >Affects Versions: 1.5 >Reporter: Falko Modler > > It would be a very welcomed addition if the plugin would also filter > non-verlocity (.vm) files. > See also: MRRESOURCES-83 > Renaming the files in question to *.vm is not an option for me because: > - MRRESOURCES-94 > - the module _providing_ the file(s) also needs them _without_ .vm suffix > (fixing this would require some other plugin) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
Falko Modler created MENFORCER-314:
--
Summary: DependencyConvergence fails sporadically with a null
message
Key: MENFORCER-314
URL: https://issues.apache.org/jira/browse/MENFORCER-314
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.4.1
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Java version: 1.8.0_162, vendor: Oracle Corporation
Reporter: Falko Modler
Our Jenkins builds fail sporadically without providing a message:
{noformat}
17:08:28 [WARNING] Rule 4:
org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
17:08:28 null
{noformat}
Looking at the code, I suspect that this can happen [on line 132 of the
rule|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java#L132]
when some underlying exception is caught which itself does not provide a
(localized) message.
As the plugin [does not include the
cause|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/EnforceMojo.java#L212]
(unless {{failFast}} is set), you will just see a null message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MENFORCER-317) RequireFileChecksum ignores configured message
Falko Modler created MENFORCER-317:
--
Summary: RequireFileChecksum ignores configured message
Key: MENFORCER-317
URL: https://issues.apache.org/jira/browse/MENFORCER-317
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0-M2
Reporter: Falko Modler
The [documentation for RequireFileChecksum
|https://maven.apache.org/enforcer/enforcer-rules/requireFileChecksum.html]
says, that you can set a {{message}} that is used for a violation message.
However, this configuable attribute coming from
{{AbstractStandardEnforcerRule}} is simply ignored/not evaluated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-106) ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory for big projects
[
https://issues.apache.org/jira/browse/MRRESOURCES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625246#comment-16625246
]
Falko Modler commented on MRRESOURCES-106:
--
[~hboutemy] I don't think my fix for MRRESOURCES-94 is going to help here:
The OP is actually using a velocity template which does use
{{projectsSortedByOrganization}}, so the (expensive) lookup will still kick in,
only at a later point.
> ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory
> for big projects
> --
>
> Key: MRRESOURCES-106
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-106
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Thomas Mortagne
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> At XWiki we are using the remote resource plugin to generate a NOTICE files
> we put in the META-INF of all jars. The file can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-tools/xwiki-commons-tool-license-resources/src/main/resources/META-INF/NOTICE.vm.
> We have a lot of memory issues and we kept increasing the max memory but it
> was starting to be a bit insane (we now get a OOM with -Xmx2500m) so I
> finally took a profiler to try to figure out where all this memory goes.
> We did noticed for a while that remote resource plugin is taking longer and
> longer to execute during the build so I had my doubts already.
> What Yourkit is telling me is that almost half of the memory (400MB here
> because I reduced the max memory for it to fail earlier) is retained by an
> ArrayList of MavenProject instances located in
> ProcessRemoteResourcesMojo#getProjects().
> It can be reproduced by building https://github.com/xwiki/xwiki-platform (you
> will need to add some repositories in your settings.xml, you can find them on
> http://dev.xwiki.org/xwiki/bin/view/Community/Building/#HInstallingMaven).
> Also I can probably put the memory dump I have somewhere if someone wants to
> download it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625247#comment-16625247
]
Falko Modler commented on MRRESOURCES-94:
-
I'd like to point out that the fix that has just been merged is only a solution
for those who *don't* use {{projects}} / {{projectsSortedByOrganization}} or
who don't even use velocity templates.
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
Falko Modler created MNG-6105:
-
Summary:
properties.internal.SystemProperties.addSystemProperties() is not really
thread-safe
Key: MNG-6105
URL: https://issues.apache.org/jira/browse/MNG-6105
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.3.9
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Maven home: /usr/maven/default
Java version: 1.8.0_102, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_102/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64", family:
"unix"
Reporter: Falko Modler
We got a rather large Maven project with a couble of modules that execute
{{maven-assembly-plugin}}. Our builds runs in parallel mode via {{-Tx}}.
>From time to time we are seeing following execption causing the respective
>build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
assembly-zip of goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at
org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
at
org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:286)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveTransitively(DefaultDependencyResolver.java:253)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencySets(DefaultDependencyResolver.java:169)
at
org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase
[jira] [Updated] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MNG-6105:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{maven-assembly-plugin}}. Our builds run in parallel mode via {{-Tx}}.
>From time to time we are seeing following execption causing the respective
>build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
assembly-zip of goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at
org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
at
org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:286)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveTransitively(DefaultDependencyResolver.java:253)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencySets(DefaultDependencyResolver.java:169)
at
org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:94)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:178)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read th
[jira] [Updated] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MNG-6105:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
>From time to time we are seeing following execption causing the respective
>build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
assembly-zip of goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at
org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
at
org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:286)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveTransitively(DefaultDependencyResolver.java:253)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencySets(DefaultDependencyResolver.java:169)
at
org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:94)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:178)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read th
[jira] [Updated] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MNG-6105:
--
Description:
We got a rather large Maven project with a couble of modules that execute
{{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
>From time to time we are seeing following exception causing the respective
>build to fail:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
project some-module: Execution assembly-zip of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
assembly-zip of goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single
failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 11 more
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at
org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
at
org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:321)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:286)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveTransitively(DefaultDependencyResolver.java:253)
at
org.apache.maven.plugin.assembly.artifact.DefaultDependencyResolver.resolveDependencySets(DefaultDependencyResolver.java:169)
at
org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:94)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:178)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 12 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read th
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15576647#comment-15576647
]
Falko Modler commented on MNG-6105:
---
I still don't know what is removing system properties. There is a similar
problem with cxf-codegen: CXF-7083
We do set system properties in tests but that is happening in a forked JVM
(started by surefire-plugin).
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
>
[jira] [Commented] (MNG-6105) properties.internal.SystemProperties.addSystemProperties() is not really thread-safe
[
https://issues.apache.org/jira/browse/MNG-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758981#comment-15758981
]
Falko Modler commented on MNG-6105:
---
Sorry for not replying. I did not have the time to test the fix (and it is very
hard to reproduce).
I will create a new ticket in case to problem pops up again with Maven 3.4.0+.
> properties.internal.SystemProperties.addSystemProperties() is not really
> thread-safe
>
>
> Key: MNG-6105
> URL: https://issues.apache.org/jira/browse/MNG-6105
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.3.9
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: /usr/maven/default
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: /usr/java/jdk1.8.0_102/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "2.6.32-431.29.2.el6.x86_64", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Assignee: Guillaume Boué
> Fix For: 3.4.0
>
>
> We got a rather large Maven project with a couble of modules that execute
> {{maven-assembly-plugin}}. Our build runs in parallel mode via {{-Tx}}.
> From time to time we are seeing following exception causing the respective
> build to fail:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip) on
> project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.6:single (assembly-zip)
> on project some-module: Execution assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> assembly-zip of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at
> org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
> at
> org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
> at
> org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:493)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:348)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342)
> at
[jira] [Commented] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111090#comment-17111090
]
Falko Modler commented on MCOMPILER-414:
Could it be that the root cause is MCOMPILER-413?
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-413) Parameters does not work when only release is specified
[
https://issues.apache.org/jira/browse/MCOMPILER-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1716#comment-1716
]
Falko Modler commented on MCOMPILER-413:
Thanks for documenting the workaround. This does also resolve MCOMPILER-414.
> Parameters does not work when only release is specified
> ---
>
> Key: MCOMPILER-413
> URL: https://issues.apache.org/jira/browse/MCOMPILER-413
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Arch Linux, OpenJDK 11.0.6.u10, Maven 3.6.3
>Reporter: Jiri Kraml
>Priority: Minor
>
> Compiling a project with the following maven-compiler-plugin configuration
> does not produce parameter name metadata in the class files:
> {{<{color:#0033b3}configuration{color}>}}
> {{ <{color:#0033b3}release{color}>9}}
> {{
> <{color:#0033b3}parameters{color}>true}}
> {{}}
> I believe this is a mistake, because
> {{javac --release 9 -parameters Test.java}}
> will produce the metadata.
> This behavior is due to dependency
> {{org.codehaus.plexus:plexus-compiler-javac:2.8.4}}, where in
> {{org.codehaus.plexus.compiler.javac.JavacCompiler}}, line 312, the function
> {{isPreJava18}} is called. This function does not evaluate the release
> property, only source and compilerVersion.
> Available workarounds in {{pom.xml}} are additionally specifying {{source}}
> or explicitly specifying the {{-parameters}} parameter in the plugin
> configuration.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1719#comment-1719
]
Falko Modler commented on MCOMPILER-414:
To quote myself:
{quote}
Could it be that the root cause is MCOMPILER-413?
{quote}
Indeed it is!
The {{compilerArgs}} workaround did not work for me, btw (but the one from
MCOMPILER-413 does).
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1800) SurefireForkChannel binds to wrong IP
Falko Modler created SUREFIRE-1800:
--
Summary: SurefireForkChannel binds to wrong IP
Key: SUREFIRE-1800
URL: https://issues.apache.org/jira/browse/SUREFIRE-1800
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 3.0.0-M5
Environment: $ mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Develop\some-project\middleware\_develop\maven\default
Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
C:\Develop\some-project\middleware\_develop\java\default
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Reporter: Falko Modler
I was really looking forward to the new TCP process communication (thanks for
that!) but it seems it has a fundamental issue in non-trivial network setups:
After adding:
{code:xml}
{code}
my test executions are getting stuck at:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
{noformat}
{{-X}} reveals:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 15428
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath: [omitted]
[DEBUG] boot(compact) classpath: [omitted]
[DEBUG] Forking command line: cmd.exe /X /C
"C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar
C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1
surefire6381289732609561853tmp surefire_02272472648642066547tmp"
{noformat}
The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only
network adapters. So that won't work.
I would have expected 127.0.0.1 at this point.
I debugged the constructor of {{SurefireForkChannel}} and there
{{Inet4Address.getLocalHost()}} is returning the wrong IP.
At this point I am asking myself why {{SurefireForkChannel}} isn't simply using
{{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
Alternatively a {{bindAddress}} parameter would come in handy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1800) SurefireForkChannel binds to wrong IP
[
https://issues.apache.org/jira/browse/SUREFIRE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-1800:
---
Description:
I was really looking forward to the new TCP process communication (thanks for
that!) but it seems it has a fundamental issue in non-trivial network setups:
After adding:
{code:xml}
{code}
my test executions are getting stuck at:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
{noformat}
{{-X}} reveals:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 15428
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath: [omitted]
[DEBUG] boot(compact) classpath: [omitted]
[DEBUG] Forking command line: cmd.exe /X /C
"C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar
C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1
surefire6381289732609561853tmp surefire_02272472648642066547tmp"
{noformat}
The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only
network adapters. So that won't work.
>From my naive perspective, I would have expected 127.0.0.1.
I debugged the constructor of {{SurefireForkChannel}} and there
{{Inet4Address.getLocalHost()}} is returning the wrong IP.
At this point I am asking myself why {{SurefireForkChannel}} isn't simply
using {{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
Alternatively a {{bindAddress}} parameter would come in handy.
was:
I was really looking forward to the new TCP process communication (thanks for
that!) but it seems it has a fundamental issue in non-trivial network setups:
After adding:
{code:xml}
{code}
my test executions are getting stuck at:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
{noformat}
{{-X}} reveals:
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 15428
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath: [omitted]
[DEBUG] boot(compact) classpath: [omitted]
[DEBUG] Forking command line: cmd.exe /X /C
"C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar
C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1
surefire6381289732609561853tmp surefire_02272472648642066547tmp"
{noformat}
The problem here is that 192.168.99.1 is a IP of one of my VirtualBox Host-Only
network adapters. So that won't work.
I would have expected 127.0.0.1 at this point.
I debugged the constructor of {{SurefireForkChannel}} and there
{{Inet4Address.getLocalHost()}} is returning the wrong IP.
At this point I am asking myself why {{SurefireForkChannel}} isn't simply using
{{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
Alternatively a {{bindAddress}} parameter would come in handy.
> SurefireForkChannel binds to wrong IP
> -
>
> Key: SUREFIRE-1800
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1800
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
> Environment: $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Develop\some-project\middleware\_develop\maven\default
> Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
> C:\Develop\some-project\middleware\_develop\java\default
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Major
>
> I was really looking forward to the new TCP process communication (thanks for
> that!) but it seems it has a fundamental issue in non-trivial network setups:
> After adding:
> {code:xml}
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
> {code}
> my test executions are getting stuck at:
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> {noformat}
> {{-X}} re
[jira] [Commented] (SUREFIRE-1800) SurefireForkChannel binds to wrong IP
[
https://issues.apache.org/jira/browse/SUREFIRE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139536#comment-17139536
]
Falko Modler commented on SUREFIRE-1800:
When I disable both VirtualBox Host-Only network adapters it works. But this
not a valid workaround for me since I need VirtualBox VMs for my daily work.
> SurefireForkChannel binds to wrong IP
> -
>
> Key: SUREFIRE-1800
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1800
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
> Environment: $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Develop\some-project\middleware\_develop\maven\default
> Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
> C:\Develop\some-project\middleware\_develop\java\default
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Major
>
> I was really looking forward to the new TCP process communication (thanks for
> that!) but it seems it has a fundamental issue in non-trivial network setups:
> After adding:
> {code:xml}
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
> {code}
> my test executions are getting stuck at:
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> {noformat}
> {{-X}} reveals:
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [DEBUG] Determined Maven Process ID 15428
> [DEBUG] Fork Channel [1] connection string 'tcp://192.168.99.1:51401' for the
> implementation class
> org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
> [DEBUG] boot classpath: [omitted]
> [DEBUG] boot(compact) classpath: [omitted]
> [DEBUG] Forking command line: cmd.exe /X /C
> "C:\Develop\some-project\middleware\_develop\java\default\bin\java -jar
> C:\Develop\Temp\surefire2701709940583667253\surefirebooter12465325576730119938.jar
> C:\Develop\Temp\surefire2701709940583667253 2020-06-18T17-33-41_288-jvmRun1
> surefire6381289732609561853tmp surefire_02272472648642066547tmp"
> {noformat}
> The problem here is that 192.168.99.1 is a IP of one of my VirtualBox
> Host-Only network adapters. So that won't work.
> From my naive perspective, I would have expected 127.0.0.1.
> I debugged the constructor of {{SurefireForkChannel}} and there
> {{Inet4Address.getLocalHost()}} is returning the wrong IP.
> At this point I am asking myself why {{SurefireForkChannel}} isn't simply
> using {{InetAddress.getLoopbackAddress()}} (which returns 127.0.0.1)?
> Alternatively a {{bindAddress}} parameter would come in handy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1801) New TCP communication mode defers "Listening for transport" debug message
Falko Modler created SUREFIRE-1801:
--
Summary: New TCP communication mode defers "Listening for
transport" debug message
Key: SUREFIRE-1801
URL: https://issues.apache.org/jira/browse/SUREFIRE-1801
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 3.0.0-M5
Environment: $ mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Develop\some-project\middleware\_develop\maven\default
Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
C:\Develop\some-project\middleware\_develop\java\default
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Reporter: Falko Modler
When using
{code:xml}
{code}
and {{-Dmaven.surefire.debug}} you see the message
{noformat}
Listening for transport dt_socket at address: 5005
{noformat}
_only after_ you have connected the debugger, which defeats the whole point of
this message and leaves the user under the impression that test execution is
stuck before opening the debug port.
In "legacy" mode the message is displayed as expected (before connecting the
debugger).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1806) Site: Link to "TCP/IP Communication between Forks" is broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Falko Modler updated SUREFIRE-1806: --- Description: This link: !image-2020-06-21-18-24-34-260.png! yields: !image-2020-06-21-18-25-49-558.png! was: This link: !image-2020-06-21-18-24-34-260.png|thumbnail! yields: !image-2020-06-21-18-25-49-558.png|thumbnail! > Site: Link to "TCP/IP Communication between Forks" is broken > > > Key: SUREFIRE-1806 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1806 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Affects Versions: 3.0.0-M5 > Environment: Firefox 77.0.1 >Reporter: Falko Modler >Priority: Minor > Attachments: image-2020-06-21-18-24-34-260.png, > image-2020-06-21-18-25-49-558.png > > > This link: > !image-2020-06-21-18-24-34-260.png! > yields: > !image-2020-06-21-18-25-49-558.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1806) Site: Link to "TCP/IP Communication between Forks" is broken
Falko Modler created SUREFIRE-1806: -- Summary: Site: Link to "TCP/IP Communication between Forks" is broken Key: SUREFIRE-1806 URL: https://issues.apache.org/jira/browse/SUREFIRE-1806 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 3.0.0-M5 Environment: Firefox 77.0.1 Reporter: Falko Modler Attachments: image-2020-06-21-18-24-34-260.png, image-2020-06-21-18-25-49-558.png This link: !image-2020-06-21-18-24-34-260.png|thumbnail! yields: !image-2020-06-21-18-25-49-558.png|thumbnail! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1805) New config `bindAddress` and `connectionAddress` in SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141527#comment-17141527
]
Falko Modler commented on SUREFIRE-1805:
[~tibordigana] I had a brief look at this and some questions arise:
- Why do we need {{connectionAddress}}? Shall it override
{{server.getLocalAddress()}}?
- Do we want to set port numbers via these two properties? If yes:
-- How would that work with multipe forks?
-- Is a combined string ({{":port"}}) sufficient?
A few more questions can be discussed via a PR.
> New config `bindAddress` and `connectionAddress` in SurefireForkNodeFactory
> ---
>
> Key: SUREFIRE-1805
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1805
> Project: Maven Surefire
> Issue Type: New Feature
> Components: documentation, Maven Failsafe Plugin, Maven Surefire
> Plugin, process forking
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
[
https://issues.apache.org/jira/browse/SUREFIRE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154503#comment-17154503
]
Falko Modler commented on SUREFIRE-1068:
Another workaround (double dollar):
{code:xml}
$${surefire.forkNumber}
{code}
But watch out: IntelliJ will then pass {{-Dsurefire.forkNumber=$1}} to mvn.
> forkNumber in systemPropertyVariables requires prefix
> -
>
> Key: SUREFIRE-1068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Eric Pederson
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0
>
>
> The {{$\{surefire.forkNumber\}}} placeholder cannot be used alone in a
> {{systemPropertyVariable}}. The workaround is to prefix the value.
> For example, this doesn't work (the {{surefire.forkNumber}} system property
> does not exist when running the test).
> {code:xml}
>
> ${surefire.forkNumber}
>
> {code}
> But this does:
> {code:xml}
>
> 0${surefire.forkNumber}
>
> {code}
> (note the leading *0*)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
[
https://issues.apache.org/jira/browse/MENFORCER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1137#comment-1137
]
Falko Modler commented on MENFORCER-314:
I've sent to PRs to improve output for such a case to figure out what is going
on.
> DependencyConvergence fails sporadically with a null message
>
>
> Key: MENFORCER-314
> URL: https://issues.apache.org/jira/browse/MENFORCER-314
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_162, vendor: Oracle Corporation
>Reporter: Falko Modler
>Priority: Major
>
> Our Jenkins builds fail sporadically without providing a message:
> {noformat}
> 17:08:28 [WARNING] Rule 4:
> org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
> 17:08:28 null
> {noformat}
> Looking at the code, I suspect that this can happen [on line 132 of the
> rule|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java#L132]
> when some underlying exception is caught which itself does not provide a
> (localized) message.
> As the plugin [does not include the
> cause|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/EnforceMojo.java#L212]
> (unless {{failFast}} is set), you will just see a null message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
[
https://issues.apache.org/jira/browse/MENFORCER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MENFORCER-314:
---
Affects Version/s: 3.0.0-M1
> DependencyConvergence fails sporadically with a null message
>
>
> Key: MENFORCER-314
> URL: https://issues.apache.org/jira/browse/MENFORCER-314
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_162, vendor: Oracle Corporation
>Reporter: Falko Modler
>Priority: Major
>
> Our Jenkins builds fail sporadically without providing a message:
> {noformat}
> 17:08:28 [WARNING] Rule 4:
> org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
> 17:08:28 null
> {noformat}
> Looking at the code, I suspect that this can happen [on line 132 of the
> rule|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java#L132]
> when some underlying exception is caught which itself does not provide a
> (localized) message.
> As the plugin [does not include the
> cause|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/EnforceMojo.java#L212]
> (unless {{failFast}} is set), you will just see a null message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1240#comment-1240 ] Falko Modler commented on MNG-6311: --- [~fbricon] Since this ticket has been closed I think you should raise your (very plausible) concerns in a new ticket? > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
[
https://issues.apache.org/jira/browse/MENFORCER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668424#comment-16668424
]
Falko Modler commented on MENFORCER-314:
[~khmarbaise] Any chance to have one of the PRs integrated into 3.0.0? :)
> DependencyConvergence fails sporadically with a null message
>
>
> Key: MENFORCER-314
> URL: https://issues.apache.org/jira/browse/MENFORCER-314
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_162, vendor: Oracle Corporation
>Reporter: Falko Modler
>Priority: Major
>
> Our Jenkins builds fail sporadically without providing a message:
> {noformat}
> 17:08:28 [WARNING] Rule 4:
> org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
> 17:08:28 null
> {noformat}
> Looking at the code, I suspect that this can happen [on line 132 of the
> rule|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DependencyConvergence.java#L132]
> when some underlying exception is caught which itself does not provide a
> (localized) message.
> As the plugin [does not include the
> cause|https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M2/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/EnforceMojo.java#L212]
> (unless {{failFast}} is set), you will just see a null message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
Falko Modler created MNG-6511:
-
Summary: Option -pl ! foo should not fail if foo does not exist
Key: MNG-6511
URL: https://issues.apache.org/jira/browse/MNG-6511
Project: Maven
Issue Type: Improvement
Affects Versions: 3.6.0, 3.3.9
Reporter: Falko Modler
While I completely understand why Maven throws an error when
{{\-pl/--projects}} defines/contains a non-existing project, I don't really see
why the negation of a non-existing project yields the same error, e.g.:
{noformat}
c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
[INFO] Scanning for projects...
[ERROR] [ERROR] Could not find the selected project in the reactor: foo @
[ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
{noformat}
I'd say that at most this should be a warning, not an error.
This change would come in handy to reuse scripts with certain default options
(e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682455#comment-16682455
]
Falko Modler commented on MNG-6511:
---
Improving help output is a good idea!
{quote}
why do you want these modules to be excluded? Can it be solved with profiles?
{quote}
Me and my developer colleagues have our own scripts to quickly build a 90+
modules project. These scripts contain options that _could_ be defined by
profiles like {{-Dcheckstyle.skip=true}} and {{-Denforcer.skip=true}} but also
options like {{-T4}} which cannot be defined by profiles.
That project has a couple of modules that you don't want to and also don't need
rebuild all the time, like a final big assembly of everything. I admit that the
project structure might not be ideal but with a more flexible {{-pl}}, people
could just use for (instance) {{-pl ! final-assembly}} in their "quick build"
script and wouldn't need to worry on which level their are invoking that script.
Excluding modules with profiles is pretty verbose, especially since you cannot
say in root pom that you want to exclude one or more modules two or more levels
deeper. You would end up with "module exclusion profiles" scattered all over
the project and that's not something I want to do.
In the end I am just asking for a litte more flexibility of {{-pl ! ...}}. I
mean when I say {{-pl ! foo}} I just don't want that module to be built. At
that point I don't care if it exists or not.
{quote}
However, there's an issue that wants make this more strict, just to ensure you
haven't made a typo or that you accidentally excluded one. For that reason I
tend to say -1 for this proposal.
{quote}
For me this is not the same. When you specify a non-existing profile (which
just issues a warning) you _don't get_ what you wanted (which might be pretty
bad) but when I _don't want_ something then IMHO it is irrelevant whether this
is "achieved" by non-existence or due to being disabled/excluded.
Am I making sense?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682596#comment-16682596
]
Falko Modler commented on MNG-6511:
---
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunalety.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682596#comment-16682596
]
Falko Modler edited comment on MNG-6511 at 11/10/18 9:20 PM:
-
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunately.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
was (Author: famod):
{quote}
In general that means strict is better to match the expected result.
{quote}
I'd still say that a user first and foremost just expects the given module not
to be built.
Anyhow, we have different opinons and it's of course up to you to decide
(otherwise).
{quote}
Since it seems you're already using scripts, maybe mavenrc is an option or the
Maven Project options introduced with MNG-5767 which seems to be porely
documented.
{quote}
You can't put {{-pl ! ...}} in {{.mvn/maven.config}} because it kicks in
regardless of which level you are operating on in your multi module project.
{{mvn}} will thus fail if you change the working directory or use {{-f}} in
such a way that one of the negated modules is not part of the reactor anymore.
I guess the same happens with mavenrc.
Anyway, I would _not_ put {{-pl ! ...}} in either of these files because that
would be like a permanent filter for the entire project causing those modules
never to be built.
Instead, I would put {{-pl ! ...}} into my "quick build" script (and maybe
other variants of that script) which lives happily next to my "pre push" script
which doesn't exclude anything (or just use {{mvn clean install}} or whatever).
For me the bottom line of this discussion is that the current behaviour won't
be changed, unfortunalety.
I see one possible extension of {{-pl}}, though:
What if you could define something like {{-pl !?foo}}, meaning "exclude foo, if
exists"? And Wildcard or even Regex support would be even more flexible...
WDYT?
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682926#comment-16682926
]
Falko Modler commented on MNG-6511:
---
Ok, sounds good!
While not directly related to the scope of this ticket, what do you think about
wildcards like {{*-somesuffix}}, {{?*-somesuffix}}, {{someprefix-*}},
{{?someprefix-*}} etc.?
I actually did have the need for such wildcards more often than not.
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682926#comment-16682926
]
Falko Modler edited comment on MNG-6511 at 11/11/18 4:28 PM:
-
Ok, sounds good!
While not directly related to the scope of this ticket, what do you think about
wildcards like:
- {{\*\-somesuffix}}
- {{?\*\-somesuffix}}
- {{someprefix-\*}}
- {{?someprefix-\*}}
etc.?
I actually did have the need for such wildcards more often than not.
was (Author: famod):
Ok, sounds good!
While not directly related to the scope of this ticket, what do you think about
wildcards like {{*-somesuffix}}, {{?*-somesuffix}}, {{someprefix-*}},
{{?someprefix-*}} etc.?
I actually did have the need for such wildcards more often than not.
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-568) dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx
[ https://issues.apache.org/jira/browse/MDEP-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16697383#comment-16697383 ] Falko Modler commented on MDEP-568: --- [PR #2|https://github.com/apache/maven-dependency-plugin/pull/2] also seems to fix MDEP-358 which was auto-closed in 2016. > dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts > in the excluded group > -- > > Key: MDEP-568 > URL: https://issues.apache.org/jira/browse/MDEP-568 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline, resolve >Affects Versions: 2.3, 3.0.0 > Environment: windows / cygwin xp64 bit / bash / maven 3.0.3 >Reporter: Archimedes Trajano >Priority: Major > Attachments: MDEP-568-maven-dependency-plugin.patch, > go-offline_copy-dependencies_patch_sample.zip, test.tgz > > > see thread: > http://mail-archives.apache.org/mod_mbox/maven-users/201109.mbox/%3c0B02C46601D44673A4A2DF4C4F907E9E@black%3e > in attached sample pom structure: > mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:go-offline > -DexcludeGroupIds=us.pdinc.foo.maven.test > fails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies
[
https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712145#comment-16712145
]
Falko Modler commented on MASSEMBLY-675:
This fix also improves runtime dramatically when you have many dependencies and
{{true}}!
Can you please release 3.1.1, [~olamy] / [~hboutemy] / [~rfscholte] /
[~khmarbaise]? Thanks!
> Maven Assembly packaging wildcard-excluded dependencies
> ---
>
> Key: MASSEMBLY-675
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-675
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.4
> Environment: Apache Maven 3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>Reporter: Frank Wilson
>Assignee: Guillaume Boué
>Priority: Major
> Fix For: 3.1.1
>
> Attachments: massembly-675.zip
>
>
> Version 2.4 ignores wildcard exclusions in POM dependencies
> Example (perhaps contrived - but easy to setup):
> When a pom declares a dependency such as closure-compiler and for some reason
> we do not want to pull its dependencies in we could declare this in our POM,
> without having to know what those dependencies are:
>
>
> com.google.javascript
> closure-compiler
> v20131014
>
>
> *
> *
>
>
>
>
> This is a valid use of the exclusion feature as per [Maven
> Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies],
> [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about
> wildcards were
> [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5]
> in Git about 10 days ago
> Here is the assembly descriptor:
>
> bin
>
> dir
>
> false
>
>
>
>
> We expect to only find the current project artifact and the closure-compiler
> JAR in our directory assembly. However the assembly plugin ignores our POM
> directive and includes the closure-compilers dependencies anyway!
> Steps to reproduce are:
> $ unzip massembly-675.zip
> $ cd massembly-675
> $ mvn clean install
> $ ls target/massembly-675-1-bin
> args4j-2.0.16.jar json-20090211.jar
> protobuf-java-2.4.1.jar
> closure-compiler-v20131014.jar jsr305-1.3.9.jar
> guava-15.0.jar massembly-675-1.jar
> *Notice that the excluded jars are included in the assembly*
> I would expect to only see the following JARs.
> * closure-compiler-v20131014.jar
> * massembly-675-1.jar
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-314) DependencyConvergence fails sporadically with a null message
[
https://issues.apache.org/jira/browse/MENFORCER-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741971#comment-16741971
]
Falko Modler commented on MENFORCER-314:
After running some weeks with a custom build of the plugin incorporating PR
#44, the problem finally struck and the output now reveals the underlying cause:
{noformat}
11:13:47 [WARNING] Rule 4:
org.apache.maven.plugins.enforcer.DependencyConvergence failed with message:
11:13:47 org.apache.maven.enforcer.rule.api.EnforcerRuleException
11:13:47at
org.apache.maven.plugins.enforcer.DependencyConvergence.execute(DependencyConvergence.java:132)
11:13:47at
org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:204)
11:13:47at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
11:13:47at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
11:13:47at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
11:13:47at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
11:13:47at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
11:13:47at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
11:13:47at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
11:13:47at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11:13:47at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
11:13:47at java.util.concurrent.FutureTask.run(FutureTask.java:266)
11:13:47at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
11:13:47at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
11:13:47at java.lang.Thread.run(Thread.java:748)
11:13:47 Caused by: java.lang.NullPointerException
11:13:47at java.util.Hashtable.put(Hashtable.java:460)
11:13:47at
org.apache.maven.properties.internal.SystemProperties.addSystemProperties(SystemProperties.java:38)
11:13:47at
org.apache.maven.project.artifact.MavenMetadataSource.getSystemProperties(MavenMetadataSource.java:756)
11:13:47at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:574)
11:13:47at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:190)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:532)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:584)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:144)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:100)
11:13:47at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:782)
11:13:47at
org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:118)
11:13:47at
org.apache.maven.plugins.enforcer.DependencyConvergence.getNode(DependencyConvergence.java:86)
11:13:47at
org.apache.maven.plugins.enforcer.DependencyConvergence.execute(DependencyConvergence.java:114)
11:13:47... 14 more
{noformat}
So in this case it was MNG-6105 (we are still on Maven 3.3.9).
> DependencyConvergence fails sporadically with a null message
>
>
> Key: MENFORCER-314
> URL: https://issues.apache.org/jira/browse/MENFORCER-314
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1, 3.0.0-M1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T1
[jira] [Commented] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[ https://issues.apache.org/jira/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920182#comment-16920182 ] Falko Modler commented on MENFORCER-195: I am not entirely sure whether the following issue is related with this ticket but I do guess so: With Maven 3.6.1 and Enforcer Plugin 3.0.0-M2, wildcard-exclusions for artifactId _do work for me_. But with the soon to be released Maven 3.6.2 (https://lists.apache.org/thread.html/b892c3a9a4250dcc439f80e9b44b9c01b8e4edf5317d175a2e1cb7cc@%3Cdev.maven.apache.org%3E), DependencyConvergence fails, as if it doesn't properly evaluate the the exclusions anymore. dependency:tree is identical to 3.6.1, though... PS, scenario: I have a few transitive dependencies bringing in an old version of javassist which I need to override with a newer one. > Dependency convergence does not support wildcard exclusions > --- > > Key: MENFORCER-195 > URL: https://issues.apache.org/jira/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them dependencyConvergence wrongly complains about conflicting > transitive dependencies. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[ https://issues.apache.org/jira/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920182#comment-16920182 ] Falko Modler edited comment on MENFORCER-195 at 8/31/19 5:19 PM: - I am not entirely sure whether the following issue is related with this ticket but I do guess so: With Maven 3.6.1 and Enforcer Plugin 3.0.0-M2, wildcard-exclusions for artifactId _do work for me_. But with the soon to be released Maven 3.6.2 (https://lists.apache.org/thread.html/b892c3a9a4250dcc439f80e9b44b9c01b8e4edf5317d175a2e1cb7cc@%3Cdev.maven.apache.org%3E), DependencyConvergence fails, as if it doesn't properly evaluate the the exclusions anymore. dependency:tree is identical to 3.6.1, though... PS, scenario: I have a few transitive dependencies bringing in an old version of javassist which I need to override with a newer one. The actual version of javassist comes from a BOM that is imported in the root pom of my project. was (Author: famod): I am not entirely sure whether the following issue is related with this ticket but I do guess so: With Maven 3.6.1 and Enforcer Plugin 3.0.0-M2, wildcard-exclusions for artifactId _do work for me_. But with the soon to be released Maven 3.6.2 (https://lists.apache.org/thread.html/b892c3a9a4250dcc439f80e9b44b9c01b8e4edf5317d175a2e1cb7cc@%3Cdev.maven.apache.org%3E), DependencyConvergence fails, as if it doesn't properly evaluate the the exclusions anymore. dependency:tree is identical to 3.6.1, though... PS, scenario: I have a few transitive dependencies bringing in an old version of javassist which I need to override with a newer one. > Dependency convergence does not support wildcard exclusions > --- > > Key: MENFORCER-195 > URL: https://issues.apache.org/jira/browse/MENFORCER-195 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.3.1 > Environment: Maven 3.2.1 >Reporter: Tomaz Cerar >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Maven 3.2 introduced wildcard exclusions for dependencies. > But if you use them dependencyConvergence wrongly complains about conflicting > transitive dependencies. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[
https://issues.apache.org/jira/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920214#comment-16920214
]
Falko Modler commented on MENFORCER-195:
[~rfscholte]:
I did some more testing and I think I can confirm that wildcard exclusions are
indeed not working for my setup either way (3.6.1 and 3.6.2).
The surprising thing is that this:
{code:xml}
some.group.id
common-test
test
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
org.javassist
javassist
${version.javassist}
test
{code}
yields the expected enforcer result (ok) with Maven 3.6.1 but it _fails_ with
Maven 3.6.2!
With Maven 3.6.2 I have to move the {{javassist}} exclusion to the top (before
{{weld}} and {{hibernate}}) to make it work.
{code:xml}
some.group.id
common-test
test
org.javassist
javassist
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
${version.javassist}
test
{code}
Does that make sense?
I mean in the end, if Maven 3.6.2 only leads to this strange effect in
enforcer-plugin (which needs adjustment anyway) then ok.
I just want to make sure Maven 3.6.2 did not introduce some strange general
side-effect...
> Dependency convergence does not support wildcard exclusions
> ---
>
> Key: MENFORCER-195
> URL: https://issues.apache.org/jira/browse/MENFORCER-195
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.3.1
> Environment: Maven 3.2.1
>Reporter: Tomaz Cerar
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Maven 3.2 introduced wildcard exclusions for dependencies.
> But if you use them dependencyConvergence wrongly complains about conflicting
> transitive dependencies.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[
https://issues.apache.org/jira/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920214#comment-16920214
]
Falko Modler edited comment on MENFORCER-195 at 8/31/19 9:02 PM:
-
[~rfscholte]:
I did some more testing and I think I can confirm that wildcard exclusions are
indeed not working for my setup either way (3.6.1 and 3.6.2).
The surprising thing is that this:
{code:xml}
some.group.id
common-test
test
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
org.javassist
javassist
${version.javassist}
test
{code}
yields the expected enforcer result (ok) with Maven 3.6.1 but it _fails_ with
Maven 3.6.2!
With Maven 3.6.2 I have to move the {{javassist}} exclusion to the top (before
{{weld}} and {{hibernate}}) to make it work:
{code:xml}
some.group.id
common-test
test
org.javassist
javassist
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
${version.javassist}
test
{code}
Does that make sense?
I mean in the end, if Maven 3.6.2 only leads to this strange effect in
enforcer-plugin (which needs adjustment anyway) then ok.
I just want to make sure Maven 3.6.2 did not introduce some strange general
side-effect...
PS: The reasoning behind the exclusion of {{hibernate}} and {{weld}} is to
prevent the usage of these Frameworks with the newer and thus possibly
incompatible {{javassist}} version.
was (Author: famod):
[~rfscholte]:
I did some more testing and I think I can confirm that wildcard exclusions are
indeed not working for my setup either way (3.6.1 and 3.6.2).
The surprising thing is that this:
{code:xml}
some.group.id
common-test
test
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
org.javassist
javassist
${version.javassist}
test
{code}
yields the expected enforcer result (ok) with Maven 3.6.1 but it _fails_ with
Maven 3.6.2!
With Maven 3.6.2 I have to move the {{javassist}} exclusion to the top (before
{{weld}} and {{hibernate}}) to make it work.
{code:xml}
some.group.id
common-test
test
org.javassist
javassist
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
${version.javassist}
test
{code}
Does that make sense?
I mean in the end, if Maven 3.6.2 only leads to this strange effect in
enforcer-plugin (which needs adjustment anyway) then ok.
I just want to make sure Maven 3.6.2 did not introduce some strange general
side-effect...
PS: The reasoning behind the exclusion of {{hibernate}} and {{weld}} is to
prevent the usage of these Frameworks with the newer and thus possibly
incompatible {{javassist}} version.
> Dependency convergence does not support wildcard exclusions
> ---
>
> Key: MENFORCER-195
> URL: https://issues.apache.org/jira/browse/MENFORCER-195
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.3.1
> Environment: Maven 3.2.1
>Reporter: Tomaz Cerar
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Maven 3.2 introduced wildcard exclusions for dependencies.
> But if you use them dependencyConvergence wrongly complains about conflicting
> transitive dependencies.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MENFORCER-195) Dependency convergence does not support wildcard exclusions
[
https://issues.apache.org/jira/browse/MENFORCER-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920214#comment-16920214
]
Falko Modler edited comment on MENFORCER-195 at 8/31/19 9:02 PM:
-
[~rfscholte]:
I did some more testing and I think I can confirm that wildcard exclusions are
indeed not working for my setup either way (3.6.1 and 3.6.2).
The surprising thing is that this:
{code:xml}
some.group.id
common-test
test
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
org.javassist
javassist
${version.javassist}
test
{code}
yields the expected enforcer result (ok) with Maven 3.6.1 but it _fails_ with
Maven 3.6.2!
With Maven 3.6.2 I have to move the {{javassist}} exclusion to the top (before
{{weld}} and {{hibernate}}) to make it work.
{code:xml}
some.group.id
common-test
test
org.javassist
javassist
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
${version.javassist}
test
{code}
Does that make sense?
I mean in the end, if Maven 3.6.2 only leads to this strange effect in
enforcer-plugin (which needs adjustment anyway) then ok.
I just want to make sure Maven 3.6.2 did not introduce some strange general
side-effect...
PS: The reasoning behind the exclusion of {{hibernate}} and {{weld}} is to
prevent the usage of these Frameworks with the newer and thus possibly
incompatible {{javassist}} version.
was (Author: famod):
[~rfscholte]:
I did some more testing and I think I can confirm that wildcard exclusions are
indeed not working for my setup either way (3.6.1 and 3.6.2).
The surprising thing is that this:
{code:xml}
some.group.id
common-test
test
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
org.javassist
javassist
${version.javassist}
test
{code}
yields the expected enforcer result (ok) with Maven 3.6.1 but it _fails_ with
Maven 3.6.2!
With Maven 3.6.2 I have to move the {{javassist}} exclusion to the top (before
{{weld}} and {{hibernate}}) to make it work.
{code:xml}
some.group.id
common-test
test
org.javassist
javassist
org.hibernate
*
org.jboss.weld
*
org.javassist
javassist
${version.javassist}
test
{code}
Does that make sense?
I mean in the end, if Maven 3.6.2 only leads to this strange effect in
enforcer-plugin (which needs adjustment anyway) then ok.
I just want to make sure Maven 3.6.2 did not introduce some strange general
side-effect...
> Dependency convergence does not support wildcard exclusions
> ---
>
> Key: MENFORCER-195
> URL: https://issues.apache.org/jira/browse/MENFORCER-195
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.3.1
> Environment: Maven 3.2.1
>Reporter: Tomaz Cerar
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Maven 3.2 introduced wildcard exclusions for dependencies.
> But if you use them dependencyConvergence wrongly complains about conflicting
> transitive dependencies.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
[
https://issues.apache.org/jira/browse/MJAVADOC-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920464#comment-16920464
]
Falko Modler commented on MJAVADOC-602:
---
[~rfscholte]: It is `mvn validate -build-delivery-javadoc`. Full profile:
{code:xml}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
> "Aggregating Javadocs For Multi-Projects" code snippet is garbled and
> tag example is missing
> -
>
> Key: MJAVADOC-602
> URL: https://issues.apache.org/jira/browse/MJAVADOC-602
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Falko Modler
>Priority: Major
> Attachments: javadoc-aggregation-doc-formatting.PNG
>
>
> After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
> aggregation setup to 3.1.0.
> It seems [the respective
> documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
> was extended with the info of [this JIRA
> comment|https://issues.apache.org/jira/browse/MJAVADOC-134?focusedCommentId=16724514&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16724514],
> but something went wrong with the formatting:
> !javadoc-aggregation-doc-formatting.PNG!
> The other issue is that this bit doesn't cover the {{}} tag approach
> so I was fiddling around with this and ended up with:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
> true
>
>
>
> aggregate-javadoc
>
> aggregate-no-fork
>
> false
>
> false
>
>
>
>
>
>
> {code}
> Notes: {{mvn -N ...}} does not work, but I don't want a separate aggregation
> for each module. So I skip the plugin in general/for all modules by _not_
> inheriting {{false}}.
> This (or some better solution) should be added to the docs.
> PS: A flag/property to just skip the individual aggregations per module would
> be very much appreciated!
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
[
https://issues.apache.org/jira/browse/MJAVADOC-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920464#comment-16920464
]
Falko Modler edited comment on MJAVADOC-602 at 9/1/19 5:21 PM:
---
[~rfscholte]: It is {{mvn validate -build-delivery-javadoc}}.
{code:xml|title=Full profile}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
was (Author: famod):
[~rfscholte]: It is `mvn validate -build-delivery-javadoc`. Full profile:
{code:xml}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
> "Aggregating Javadocs For Multi-Projects" code snippet is garbled and
> tag example is missing
> -
>
> Key: MJAVADOC-602
> URL: https://issues.apache.org/jira/browse/MJAVADOC-602
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Falko Modler
>Priority: Major
> Attachments: javadoc-aggregation-doc-formatting.PNG
>
>
> After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
> aggregation setup to 3.1.0.
> It seems [the respective
> documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
> was extended with the info of [this
[jira] [Comment Edited] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920468#comment-16920468
]
Falko Modler edited comment on MENFORCER-271 at 9/1/19 5:25 PM:
New numbers:
- Maven 3.6.1: ~10s
- Maven 3.6.2: ~7s
was (Author: famod):
New numbers:
- 3.6.1: ~10s
- 3.6.2: ~7s
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
>Priority: Major
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920468#comment-16920468
]
Falko Modler commented on MENFORCER-271:
New numbers:
- 3.6.1: ~10s
- 3.6.2: ~7s
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
>Priority: Major
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
[
https://issues.apache.org/jira/browse/MJAVADOC-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16920464#comment-16920464
]
Falko Modler edited comment on MJAVADOC-602 at 9/2/19 9:20 AM:
---
[~rfscholte]: It is {{mvn validate -Pbuild-delivery-javadoc}}.
{code:xml|title=Full profile}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
was (Author: famod):
[~rfscholte]: It is {{mvn validate -build-delivery-javadoc}}.
{code:xml|title=Full profile}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
> "Aggregating Javadocs For Multi-Projects" code snippet is garbled and
> tag example is missing
> -
>
> Key: MJAVADOC-602
> URL: https://issues.apache.org/jira/browse/MJAVADOC-602
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Falko Modler
>Priority: Major
> Attachments: javadoc-aggregation-doc-formatting.PNG
>
>
> After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
> aggregation setup to 3.1.0.
> It seems [the respective
> documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
> was extended with the info
[jira] [Created] (MENFORCER-346) RequireSnapshotVersion not compatible with CI Friendly Versions (${revision})
Falko Modler created MENFORCER-346:
--
Summary: RequireSnapshotVersion not compatible with CI Friendly
Versions (${revision})
Key: MENFORCER-346
URL: https://issues.apache.org/jira/browse/MENFORCER-346
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0-M3, 1.4.1
Environment: Apache Maven 3.6.2
(40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
Java version: 1.8.0_202, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Reporter: Falko Modler
Following https://maven.apache.org/maven-ci-friendly.html by using
{code:xml}
${revision}
{code}
and for instance
{code:xml}
1.0-SNAPSHOT
{code}
together with {{RequireSnapshotVersion}} yields:
{noformat}
[INFO] --- maven-enforcer-plugin:3.0.0-M3:enforce (default-cli) @ some-module
---
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireSnapshotVersion
failed with message:
Parent cannot be a release: some.group:some-root:pom:${revision}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
Falko Modler created SUREFIRE-1728:
--
Summary: maven.test.failure.ignore: differentiate between test
failure and timeout
Key: SUREFIRE-1728
URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
Project: Maven Surefire
Issue Type: Improvement
Affects Versions: 3.0.0-M3, 2.22.2
Environment: Maven 3.6.2
Reporter: Falko Modler
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-1728:
---
Description:
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
was:
On a build server like Jenkins, people typically set
{{-Dmaven.test.failure.ignore=true}} to get the maximum number of test results
instead of failing the build after the first module with test failures.
Unfortunately, timeouts are also ignored when this property is activated,
leaving the Jenkins JUnit plugin no chance to detect that something went wrong
(because a timeout is not reported in a txt or xml report).
See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
The two cases should be differentiated.
Due to backward compatibility reasons, I am not sure whether it would be wise
to simply exclude timeout cases.
One backward compatible solution might be to extend the value range of
{{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
like:
{{true}}/{{all}} XOR {{failure}} XOR {{false}}.
The alternative would be to introduce yet another property...
> maven.test.failure.ignore: differentiate between test failure and timeout
> -
>
> Key: SUREFIRE-1728
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.22.2, 3.0.0-M3
> Environment: Maven 3.6.2
>Reporter: Falko Modler
>Priority: Major
>
> On a build server like Jenkins, people typically set
> {{-Dmaven.test.failure.ignore=true}} to get the maximum number of test
> results instead of failing the build after the first module with test
> failures.
> Unfortunately, timeouts are also ignored when this property is activated,
> leaving the Jenkins JUnit plugin no chance to detect that something went
> wrong (because a timeout is not reported in a txt or xml report).
> See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
> The two cases should be differentiated.
> Due to backward compatibility reasons, I am not sure whether it would be wise
> to simply exclude timeout cases.
> One backward compatible solution might be to extend the value range of
> {{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
> like:
> {{true}}/{{all}} XOR {{failure}} XOR {{false}}.
> The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985582#comment-16985582
]
Falko Modler commented on SUREFIRE-1728:
[~tibordigana] There seems to be a misunderstanding: This issue is _not_ about
the wording of the message (that you have just modified in the linked commit)!
Instead we'd need a mode in surefire which causes a "hard error" in case of a
timeout when {{maven.test.failure.ignore}} is activated, but without changing
the behaviour for failing tests.
Therefore I don't see how this is fixed. This ticket should be reopened.
> maven.test.failure.ignore: differentiate between test failure and timeout
> -
>
> Key: SUREFIRE-1728
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.22.2, 3.0.0-M3
> Environment: Maven 3.6.2
>Reporter: Falko Modler
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> On a build server like Jenkins, people typically set
> {{-Dmaven.test.failure.ignore=true}} to get the maximum number of test
> results instead of failing the build after the first module with test
> failures.
> Unfortunately, timeouts are also ignored when this property is activated,
> leaving the Jenkins JUnit plugin no chance to detect that something went
> wrong (because a timeout is not reported in a txt or xml report).
> See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
> The two cases should be differentiated.
> Due to backward compatibility reasons, I am not sure whether it would be wise
> to simply exclude timeout cases.
> One backward compatible solution might be to extend the value range of
> {{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
> like:
> {{true}}/{{all}} XOR {{failure}} XOR {{false}}.
> The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1728) maven.test.failure.ignore: differentiate between test failure and timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985711#comment-16985711
]
Falko Modler commented on SUREFIRE-1728:
{quote}
you want to express an error or failure message in the XML or TXT report.
{quote}
Not necessarily. I mean yes, this would be one option but I was thinking more
whether the plugin could just cause a build failure like _without_
{{maven.test.failure.ignore}}.
In short:
# {{maven.test.failure.ignore=true}} + timeout: build failure, test results up
to the point of the timeout can be parsed from the reports
# {{maven.test.failure.ignore=true}} + test failure: _no_ build failure, all
results can be parsed from the reports
# {{maven.test.failure.ignore=false}} + timeout: same as 1.
# {{maven.test.failure.ignore=false}} + test failure: build failure, test
results can be parsed from the reports
In case scenario/variant 1. is too much of a "breaking change", the value for
{{maven.test.failure.ignore}} could be extended to something like {{true/all}}
| {{failures}} | {{false/none}}.
Just a thought...
> maven.test.failure.ignore: differentiate between test failure and timeout
> -
>
> Key: SUREFIRE-1728
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1728
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 2.22.2, 3.0.0-M3
> Environment: Maven 3.6.2
>Reporter: Falko Modler
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
>
> On a build server like Jenkins, people typically set
> {{-Dmaven.test.failure.ignore=true}} to get the maximum number of test
> results instead of failing the build after the first module with test
> failures.
> Unfortunately, timeouts are also ignored when this property is activated,
> leaving the Jenkins JUnit plugin no chance to detect that something went
> wrong (because a timeout is not reported in a txt or xml report).
> See also [JENKINS-46553|https://issues.jenkins-ci.org/browse/JENKINS-46553].
> The two cases should be differentiated.
> Due to backward compatibility reasons, I am not sure whether it would be wise
> to simply exclude timeout cases.
> One backward compatible solution might be to extend the value range of
> {{maven.test.failure.ignore}} from just {{true}} XOR {{false}} to something
> like:
> {{true}}/{{all}} XOR {{failure}} XOR {{false}}.
> The alternative would be to introduce yet another property...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-311) enforce-dependency-rules performance dropdown for maven 3.5.x
[ https://issues.apache.org/jira/browse/MENFORCER-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987285#comment-16987285 ] Falko Modler commented on MENFORCER-311: [~petrhribal] did you (re)try this with Maven 3.6.2 oder 3.6.3? There have been numerous performance fixes in Maven 3.6.x. > enforce-dependency-rules performance dropdown for maven 3.5.x > - > > Key: MENFORCER-311 > URL: https://issues.apache.org/jira/browse/MENFORCER-311 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin, Standard Rules >Affects Versions: 1.4.1 > Environment: Linux OS, Debian Jessie, 64bit > Oracle Java 1.8.0_144 > Maven 3.5.4 >Reporter: Petr Hribal >Priority: Critical > Attachments: logs.339.zip, logs.zip > > > Hi guys, since we have started using Maven 3.5.x (3.5.0, 3.5.2, 3.5.4) on our > project, we're experiencing significant performance dropdown of our build > process. It is mainly caused by maven-enforcer-plugin, which we use to > enforce dependency rules. > I run the maven with -X debug option and based on that, I can say it spends > all the time analyzing project dependencies. > See the attached logs. > The build on Maven 3.3.9 takes round about 30s, but on 3.5.x it is almost > 7mins. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRELEASE-932) ReleaseFailureException of an artefact wich version as a property
[
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16327209#comment-16327209
]
Falko Modler commented on MRELEASE-932:
---
This is still a problem.
Our usecase: Keeping a JBoss EAP distribution up to date with patches from
RedHat (e.g. 6.4.0 -> 6.4.10 -> 6.4.18 etc.).
For this we need to reference the previous distribution as a dependency.
> ReleaseFailureException of an artefact wich version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
>Priority: Major
> Labels: bug
>
> After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
> the following exception:
> {quote}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
> project ping-parent: The artifact (com.mycompagny.myapp:myapp-client)
> requires a different version (15.4.0) than what is found (12.2.1) for the
> expression (version.client.tested) in the project
> (com.mycompagny.myapp:myapp-client).
> cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
> version (15.4.0) than what is found (12.2.1) for the expression
> (version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare
> (default-cli) on project ping-parent: The artifact
> (fr.generali.gael.ping:ping-injection-client) requires a different version
> (15.4.1-git) than what is found (15.4.0) for the expression
> (version.client.tested) in the project
> (fr.generali.gael.ping:ping-client-test).
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java
> {quote}
> This error happens in a multi-module application.
> For testing purpose, we depends from an older version of an artefact of the
> same application.
> When the artefact version is an expression (ie. $\{version.client.tested\}),
> the
> [AbstractRewritePomsPhase|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java/#545]
> class do a chek.
> If we don't use the expression (i.e. properties), the release is working.
> Maven configuration that fails:
> {code}
>
> 12.1.0
>
>
> ${project.groupId}
> myapp-client
> ${version.client.tested}
>
> {code}
> Maven configuration that is working:
> {code}
>
> ${project.groupId}
> myapp-client
> 12.1.0
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJDEPS-3) Can't handle long classpath
[ https://issues.apache.org/jira/browse/MJDEPS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16404527#comment-16404527 ] Falko Modler commented on MJDEPS-3: --- Same here with version 3.1.1. > Can't handle long classpath > --- > > Key: MJDEPS-3 > URL: https://issues.apache.org/jira/browse/MJDEPS-3 > Project: Maven JDeps Plugin > Issue Type: Bug > Environment: Java version: 1.8.0_131, vendor: Oracle Corporation > Java home: C:\java\jdk8\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Clas Forsberg >Priority: Critical > Attachments: error.txt > > > When running I got this error > Cannot run program "C:\java\jdk8\jre\..\bin\jdeps.exe": CreateProcess > error=206, The filename or extension is too long > Mavan debug log attached -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6382) JANSI fails frequently with NumberFormatException when building in parallel
Falko Modler created MNG-6382:
-
Summary: JANSI fails frequently with NumberFormatException when
building in parallel
Key: MNG-6382
URL: https://issues.apache.org/jira/browse/MNG-6382
Project: Maven
Issue Type: Bug
Components: Logging
Affects Versions: 3.5.3
Reporter: Falko Modler
After upgrading from 3.3.9 to 3.5.4 my parallel Maven build fail frequently
with:
{noformat}
java.lang.NumberFormatException: For input string: "34m"
at
java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Integer.parseInt(Integer.java:652)
at java.base/java.lang.Integer.(Integer.java:1096)
at org.fusesource.jansi.AnsiPrintStream.filter(AnsiPrintStream.java:129)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:97)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107)
at
org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:161)
at
org.slf4j.impl.MavenSimpleLogger.writeThrowable(MavenSimpleLogger.java:81)
at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:319)
at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
at org.slf4j.impl.SimpleLogger.error(SimpleLogger.java:593)
at
org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:309)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{noformat}
This seems to have been [fixed in JANSI master
branch|https://github.com/fusesource/jansi/commit/e45e4665538ba9234f5ee5d7b06d78d6a03deda3]
but it has not yet been released. There is already a request for a bugfix
release, see [issue 114 ("Need 1.17.1
release")|https://github.com/fusesource/jansi/issues/114].
Maven 3.5.4 should therefore upgrade to JANSI 1.17.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6382) JANSI fails frequently with NumberFormatException when building in parallel
[
https://issues.apache.org/jira/browse/MNG-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MNG-6382:
--
Environment:
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T20:49:05+01:00)
Maven home: C:\Develop\_tools\apache-maven-3.5.3\bin\..
Java version: 10, vendor: Oracle Corporation
Java home: C:\Develop\_tools\jdk-10.0.0
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
PS: Added "Environment" info (it also happens with JDK 9.0.4 and JDK8u162).
> JANSI fails frequently with NumberFormatException when building in parallel
> ---
>
> Key: MNG-6382
> URL: https://issues.apache.org/jira/browse/MNG-6382
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.5.3
> Environment: Apache Maven 3.5.3
> (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: C:\Develop\_tools\apache-maven-3.5.3\bin\..
> Java version: 10, vendor: Oracle Corporation
> Java home: C:\Develop\_tools\jdk-10.0.0
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Major
>
> After upgrading from 3.3.9 to 3.5.4 my parallel Maven build fail frequently
> with:
> {noformat}
> java.lang.NumberFormatException: For input string: "34m"
> at
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.base/java.lang.Integer.parseInt(Integer.java:652)
> at java.base/java.lang.Integer.(Integer.java:1096)
> at
> org.fusesource.jansi.AnsiPrintStream.filter(AnsiPrintStream.java:129)
> at
> org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:97)
> at
> org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107)
> at
> org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:161)
> at
> org.slf4j.impl.MavenSimpleLogger.writeThrowable(MavenSimpleLogger.java:81)
> at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:319)
> at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
> at org.slf4j.impl.SimpleLogger.error(SimpleLogger.java:593)
> at
> org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:309)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {noformat}
> This seems to have been [fixed in JANSI master
> branch|https://github.com/fusesource/jansi/commit/e45e4665538ba9234f5ee5d7b06d78d6a03deda3]
> but it has not yet been released. There is already a request for a bugfix
> release, see [issue 114 ("Need 1.17.1
> release")|https://github.com/fusesource/jansi/issues/114].
> Maven 3.5.4 should therefore upgrade to JANSI 1.17.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-311) Bad exclusions in dependency-reduced-pom.xml
[
https://issues.apache.org/jira/browse/MSHADE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007479#comment-17007479
]
Falko Modler commented on MSHADE-311:
-
Same here. I'll try to come up with a PR.
> Bad exclusions in dependency-reduced-pom.xml
>
>
> Key: MSHADE-311
> URL: https://issues.apache.org/jira/browse/MSHADE-311
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: maven-shade-plugin 3.2.1
> Maven 3.6.0
> JDK 11
>Reporter: Dmitri Gabbasov
>Priority: Major
>
> Given the following dependency graph:
> {noformat}
> test:foo:jar:1.0.0-SNAPSHOT
> +- test:foz:jar:1.0.0-SNAPSHOT:compile
> \- test:bar:jar:1.0.0-SNAPSHOT:provided
>\- test:baz:jar:1.0.0-SNAPSHOT:provided
> {noformat}
> where {{baz}} is a _compile_ scope dependency of {{bar}} (and therefore a
> _provided_ scope dependency of {{foo}}). And given the following
> maven-shade-plugin configuration in {{foo}}:
> {noformat}
>
>
>
> test:foz
>
>
>
> {noformat}
> A weird {{dependency-reduced-pom.xml}} file is produced for {{foo}}, where
> the {{bar}} dependency declaration gets an exclusion for {{baz}}:
> {noformat}
>
>
> test
> bar
> 1.0.0-SNAPSHOT
> provided
>
>
> baz
> test
>
>
>
>
> {noformat}
> Such an exclusion is unexpected and seems wrong to me.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-311) Bad exclusions in dependency-reduced-pom.xml
[
https://issues.apache.org/jira/browse/MSHADE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007597#comment-17007597
]
Falko Modler commented on MSHADE-311:
-
I've just created [pull request
35|https://github.com/apache/maven-shade-plugin/pull/35].
> Bad exclusions in dependency-reduced-pom.xml
>
>
> Key: MSHADE-311
> URL: https://issues.apache.org/jira/browse/MSHADE-311
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1
> Environment: maven-shade-plugin 3.2.1
> Maven 3.6.0
> JDK 11
>Reporter: Dmitri Gabbasov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given the following dependency graph:
> {noformat}
> test:foo:jar:1.0.0-SNAPSHOT
> +- test:foz:jar:1.0.0-SNAPSHOT:compile
> \- test:bar:jar:1.0.0-SNAPSHOT:provided
>\- test:baz:jar:1.0.0-SNAPSHOT:provided
> {noformat}
> where {{baz}} is a _compile_ scope dependency of {{bar}} (and therefore a
> _provided_ scope dependency of {{foo}}). And given the following
> maven-shade-plugin configuration in {{foo}}:
> {noformat}
>
>
>
> test:foz
>
>
>
> {noformat}
> A weird {{dependency-reduced-pom.xml}} file is produced for {{foo}}, where
> the {{bar}} dependency declaration gets an exclusion for {{baz}}:
> {noformat}
>
>
> test
> bar
> 1.0.0-SNAPSHOT
> provided
>
>
> baz
> test
>
>
>
>
> {noformat}
> Such an exclusion is unexpected and seems wrong to me.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081328#comment-17081328
]
Falko Modler commented on MNG-6843:
---
I think I am also affected by this bug! Compilation fails spradically because
some RESTEasy packages cannot be found. Those packages come from a transitive
dependency of {{io.quarkus:quarkus-resteasy}}.
Btw: It _seems_ that in my case the problem can be worked around by defining
the respective dependencies _directly_ instead of relying on being pulled in
transitively.
I consider this a rather severe bug.
[~stepan.hrba...@gmail.com] have you ever managed to create a reproducer? I
cannot share my project either (closed source).
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar:/root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar:
> -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> After adding custom log messages I have found out that the root cause is that
> org.apache.maven.project.MavenProject.setArtifactFilter() is called with null
> artifactFilter parameter. The call ha
[jira] [Comment Edited] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081328#comment-17081328
]
Falko Modler edited comment on MNG-6843 at 4/11/20, 3:18 PM:
-
I think I am also affected by this bug! Compilation fails spradically because
some RESTEasy packages cannot be found. Those packages come from a transitive
dependency of {{io.quarkus:quarkus-resteasy}}.
When the bug strikes, I can see that another module is built concurrently which
does not have any RESTEasy dependencies.
Btw: It _seems_ that in my case the problem can be worked around by defining
the respective dependencies _directly_ instead of relying on being pulled in
transitively.
I consider this a rather severe bug.
[~stepan.hrba...@gmail.com] have you ever managed to create a reproducer? I
cannot share my project either (closed source).
was (Author: famod):
I think I am also affected by this bug! Compilation fails spradically because
some RESTEasy packages cannot be found. Those packages come from a transitive
dependency of {{io.quarkus:quarkus-resteasy}}.
Btw: It _seems_ that in my case the problem can be worked around by defining
the respective dependencies _directly_ instead of relying on being pulled in
transitively.
I consider this a rather severe bug.
[~stepan.hrba...@gmail.com] have you ever managed to create a reproducer? I
cannot share my project either (closed source).
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar:/root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar:/root/.m2/repository/org/slf4j/slf4j-api/1.7.26/sl
[jira] [Comment Edited] (MNG-6843) Parallel build fails due to missing JAR artifacts in compilePath
[
https://issues.apache.org/jira/browse/MNG-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081328#comment-17081328
]
Falko Modler edited comment on MNG-6843 at 4/11/20, 4:25 PM:
-
I think I am also affected by this bug! Compilation fails sporadically because
some RESTEasy packages cannot be found. Those packages come from a transitive
dependency of {{io.quarkus:quarkus-resteasy}}.
When the bug strikes, I can see that another module is built concurrently which
does not have any RESTEasy dependencies.
Btw: It _seems_ that in my case the problem can be worked around by defining
the respective dependencies _directly_ instead of relying on being pulled in
transitively.
I consider this a rather severe bug.
[~stepan.hrba...@gmail.com] have you ever managed to create a reproducer? I
cannot share my project either (closed source).
was (Author: famod):
I think I am also affected by this bug! Compilation fails spradically because
some RESTEasy packages cannot be found. Those packages come from a transitive
dependency of {{io.quarkus:quarkus-resteasy}}.
When the bug strikes, I can see that another module is built concurrently which
does not have any RESTEasy dependencies.
Btw: It _seems_ that in my case the problem can be worked around by defining
the respective dependencies _directly_ instead of relying on being pulled in
transitively.
I consider this a rather severe bug.
[~stepan.hrba...@gmail.com] have you ever managed to create a reproducer? I
cannot share my project either (closed source).
> Parallel build fails due to missing JAR artifacts in compilePath
>
>
> Key: MNG-6843
> URL: https://issues.apache.org/jira/browse/MNG-6843
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
> Environment: - Linux (tested Docker using maven:3-jdk-8 tag): happens
> most times.
> - Windows 10: happens sometimes.
>Reporter: Stepan Hrbacek
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Build of our multi module (57) Java maven project is failing phase when
> running it as parallel in 4 threads (mvn -T 4 clean install). The failure
> happens during compilation because packages/classes from compile dependencies
> cannot be found:
> {noformat}
> [main] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Compilation failure: Compilation
> failure:
> [main] [ERROR]
> /home/common/src/main/java/com/foo/ZonedDateTimeParser.java:[6,32] package
> org.apache.commons.lang3 does not exist{noformat}
> After enabling debug logging (with thread names) I have found out that a
> compile path of the failing module is empty (besides target/classes):
> When running in 4 threads (-T 4):
> {noformat}
> [BuilderThread 2] [DEBUG] (f) compilePath = [/home/common/target/classes]
> ...
> [BuilderThread 2] [DEBUG] Command line options:
> [BuilderThread 2] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes: -sourcepath
> /home/common/src/main/java:/home/common/target/generated-sources/annotations:
> -s /home/common/target/generated-sources/annotations -g -nowarn -target 1.8
> -source 1.8 -encoding UTF-8{noformat}
> When running in a single thread (-T 1):
> {noformat}
> [BuilderThread 0] [DEBUG] (f) compilePath = [/home/common/target/classes,
> /root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar,
>
> /root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar,
>
> /root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar,
>
> /root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar,
> /root/.m2/repository/org/jooq/jool-java-8/0.9.14/jool-java-8-0.9.14.jar,
> /root/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar,
> /root/.m2/repository/org/springframework/spring-beans/5.1.8.RELEASE/spring-beans-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-core/5.1.8.RELEASE/spring-core-5.1.8.RELEASE.jar,
>
> /root/.m2/repository/org/springframework/spring-context/5.1.8.RELEASE/spring-context-5.1.8.RELEASE.jar]
> ...
> [BuilderThread 0] [DEBUG] Command line options:
> [BuilderThread 0] [DEBUG] -d /home/common/target/classes -classpath
> /home/common/target/classes:/root/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar:/root/.m2/repository/commons-collections/commons-collections/3.2.2/commons-collections-3.2.2.jar:/root/.m2/repository/org/apache/commons/commons-collections4/4.3/commons-collections4-4.3.jar:/root/.m2/repository/org/apache/commons/commons-lang3/3.9/commons-lang3-3.9.jar
[jira] [Updated] (MGPG-79) plugin hangs on first run on Windows Git Bash with Kleopatra
[
https://issues.apache.org/jira/browse/MGPG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MGPG-79:
-
Attachment: gpg_jstack.log
> plugin hangs on first run on Windows Git Bash with Kleopatra
>
>
> Key: MGPG-79
> URL: https://issues.apache.org/jira/browse/MGPG-79
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0 (cancelled)
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.0.2
>
> Attachments: gpg_jstack.log, procexplr.PNG
>
>
> found during release 3.0.0 vote:
> [https://lists.apache.org/thread.html/r855a3f8d4b161da297191e5a7ce0e7e5be81895e60fe5b7be16cc604%40%3Cdev.maven.apache.org%3E]
> {quote}the plugin simply hangs and does not continue if I use 3.0.0 after
> starting Kleopatra (https://docs.kde.org/stable5/en/pim/kleopatra/).
> When I first use 1.6 of the plugin after starting Kleopatra, the
> password dialog pops up (as ususal), the files are signed *and after
> this I am able to use 3.0.0 just fine!*
> So with 3.0.0 the initial communication with the agent seems to be broken...
> $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\_dev\Maven\latest
> Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\latest
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> $ gpg --version
> gpg (GnuPG) 2.2.19-unknown
> libgcrypt 1.8.5
> Git Bash.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MGPG-79) plugin hangs on first run on Windows Git Bash with Kleopatra
[
https://issues.apache.org/jira/browse/MGPG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MGPG-79:
-
Attachment: procexplr.PNG
> plugin hangs on first run on Windows Git Bash with Kleopatra
>
>
> Key: MGPG-79
> URL: https://issues.apache.org/jira/browse/MGPG-79
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0 (cancelled)
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.0.2
>
> Attachments: gpg_jstack.log, procexplr.PNG
>
>
> found during release 3.0.0 vote:
> [https://lists.apache.org/thread.html/r855a3f8d4b161da297191e5a7ce0e7e5be81895e60fe5b7be16cc604%40%3Cdev.maven.apache.org%3E]
> {quote}the plugin simply hangs and does not continue if I use 3.0.0 after
> starting Kleopatra (https://docs.kde.org/stable5/en/pim/kleopatra/).
> When I first use 1.6 of the plugin after starting Kleopatra, the
> password dialog pops up (as ususal), the files are signed *and after
> this I am able to use 3.0.0 just fine!*
> So with 3.0.0 the initial communication with the agent seems to be broken...
> $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\_dev\Maven\latest
> Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\latest
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> $ gpg --version
> gpg (GnuPG) 2.2.19-unknown
> libgcrypt 1.8.5
> Git Bash.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MGPG-79) plugin hangs on first run on Windows Git Bash with Kleopatra
[
https://issues.apache.org/jira/browse/MGPG-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091877#comment-17091877
]
Falko Modler commented on MGPG-79:
--
[~tibordigana] I attached the output of {{jstack}}: [^gpg_jstack.log]
This is the process tree:
!procexplr.PNG!
The command line of the selected process is:
{noformat}
"C:\Program Files (x86)\GnuPG\bin\gpg.exe" --pinentry-mode loopback
--local-user A18E3376051AAC9D3E67822723BC64F27529BEB6 --armor --detach-sign
--output
C:\_dev\git\gitflow-incremental-builder\target\gitflow-incremental-builder-3.10.1-SNAPSHOT.jar.asc
C:\_dev\git\gitflow-incremental-builder\target\gitflow-incremental-builder-3.10.1-SNAPSHOT.jar
{noformat}
> plugin hangs on first run on Windows Git Bash with Kleopatra
>
>
> Key: MGPG-79
> URL: https://issues.apache.org/jira/browse/MGPG-79
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0 (cancelled)
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.0.2
>
> Attachments: gpg_jstack.log, procexplr.PNG
>
>
> found during release 3.0.0 vote:
> [https://lists.apache.org/thread.html/r855a3f8d4b161da297191e5a7ce0e7e5be81895e60fe5b7be16cc604%40%3Cdev.maven.apache.org%3E]
> {quote}the plugin simply hangs and does not continue if I use 3.0.0 after
> starting Kleopatra (https://docs.kde.org/stable5/en/pim/kleopatra/).
> When I first use 1.6 of the plugin after starting Kleopatra, the
> password dialog pops up (as ususal), the files are signed *and after
> this I am able to use 3.0.0 just fine!*
> So with 3.0.0 the initial communication with the agent seems to be broken...
> $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\_dev\Maven\latest
> Java version: 11.0.6, vendor: AdoptOpenJDK, runtime: C:\_dev\Java\latest
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> $ gpg --version
> gpg (GnuPG) 2.2.19-unknown
> libgcrypt 1.8.5
> Git Bash.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757724#comment-16757724
]
Falko Modler edited comment on MENFORCER-271 at 1/31/19 9:14 PM:
-
{quote}
Has there been any additional work or investigation regarding this issue?
{quote}
Not really. I just noticed that my example module is much faster with Maven
3.6.0 (~14s) that 3.3.9 (~20s), same Enforcer version (3.something).
That's better but still way too slow.
For now I ended up with a dedicated plugin execution just with
{{DependencyConvergence}} that can be skipped individually. Far from ideal and
certainly not a permanent solution but it eases the pain a bit...
{quote}
My team thinks it's an important issue, and may be able to contribute work
towards it.
{quote}
Any help is appreciated!
was (Author: famod):
{quote}
Has there been any additional work or investigation regarding this issue?
{quote}
Not really. I just noticed that my example module is much faster with Maven
3.6.0 (~14s) that 3.3.9 (~20s), same Enforcer version (3.something).
That's better but still way too slow.
For now I ended up with a dedicated plugin execution that can be skipped
individually. Far from ideal and certainly not a permanent solution but it
eases the pain a bit...
{quote}
My team thinks it's an important issue, and may be able to contribute work
towards it.
{quote}
Any help is appreciated!
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
>Priority: Major
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757724#comment-16757724
]
Falko Modler commented on MENFORCER-271:
{quote}
Has there been any additional work or investigation regarding this issue?
{quote}
Not really. I just noticed that my example module is much faster with Maven
3.6.0 (~14s) that 3.3.9 (~20s), same Enforcer version (3.something).
That's better but still way too slow.
For now I ended up with a dedicated plugin execution that can be skipped
individually. Far from ideal and certainly not a permanent solution but it
eases the pain a bit...
{quote}
My team thinks it's an important issue, and may be able to contribute work
towards it.
{quote}
Any help is appreciated!
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
>Priority: Major
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MENFORCER-271) Dependency convergence rule is very slow in larger projects
[
https://issues.apache.org/jira/browse/MENFORCER-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757724#comment-16757724
]
Falko Modler edited comment on MENFORCER-271 at 1/31/19 10:31 PM:
--
{quote}
Has there been any additional work or investigation regarding this issue?
{quote}
Not really. I just noticed that my example module is much faster with Maven
3.6.0 (~14s) than 3.3.9 (~20s), same Enforcer version (3.something).
That's better but still way too slow.
For now I ended up with a dedicated plugin execution just with
{{DependencyConvergence}} that can be skipped individually. Far from ideal and
certainly not a permanent solution but it eases the pain a bit...
{quote}
My team thinks it's an important issue, and may be able to contribute work
towards it.
{quote}
Any help is appreciated!
was (Author: famod):
{quote}
Has there been any additional work or investigation regarding this issue?
{quote}
Not really. I just noticed that my example module is much faster with Maven
3.6.0 (~14s) that 3.3.9 (~20s), same Enforcer version (3.something).
That's better but still way too slow.
For now I ended up with a dedicated plugin execution just with
{{DependencyConvergence}} that can be skipped individually. Far from ideal and
certainly not a permanent solution but it eases the pain a bit...
{quote}
My team thinks it's an important issue, and may be able to contribute work
towards it.
{quote}
Any help is appreciated!
> Dependency convergence rule is very slow in larger projects
> ---
>
> Key: MENFORCER-271
> URL: https://issues.apache.org/jira/browse/MENFORCER-271
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.4.1
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files\apache-maven-3.3.9
> Java version: 1.8.0_102, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.8.0_102\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Falko Modler
>Priority: Major
> Attachments: visualvm.PNG, visualvm_settings.PNG
>
>
> I noticed that DependencyConvergence can take up to 10 seconds or even more
> in modules with almost 300 direct and transitive dependencies (reported by
> {{dependency:tree}}).
> These modules are part of a JEE project based on JBoss EAP 6.4 which imports
> a couple of EAP BOMs. Unfortunately I am not allowed to share this project.
> I profiled the rule via VisualVM and these are the top 5 hotspots:
> !visualvm.PNG!
> The number of {{parseVersion}} calls seems excessive.
> See attached {{visualvm_settings.xml}} for reference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-584) excludePackageNames is not working as documented anymore
[
https://issues.apache.org/jira/browse/MJAVADOC-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825184#comment-16825184
]
Falko Modler commented on MJAVADOC-584:
---
Same here. With 2.10.4 the following is working just fine:
{code:xml}
foo.bar.internal
{code}
which excludes
{{foo.bar.internal.Foo.java}}
as well as
{{foo.bar.internal.baz.Foo.java}}
and
{{foo.bar.internal.baz.bing.Foo.java}}.
Now with 3.1.0 I have to configure:
{code:xml}
foo.bar.internal:
foo.bar.internal.*
{code}
Pretty annoying, given the 14 packages (= now 28 lines) that need to be
excluded in my current project.
> excludePackageNames is not working as documented anymore
>
>
> Key: MJAVADOC-584
> URL: https://issues.apache.org/jira/browse/MJAVADOC-584
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Mortagne
>Priority: Minor
>
> We have the following configuration at XWiki:
> https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-11.1/pom.xml#L1946.
> We don't want to produce javadoc for internal packages. This is very similar
> to the example given on
> https://maven.apache.org/plugins/maven-javadoc-plugin/examples/exclude-package-names.html.
> When I upgrade to 3.1.0 the exclude is not taken into account anymore (I get
> error related to classes located in internal packages). For example:
> {noformat}
> /home/hudsonagent/jenkins_root/workspace/XWiki_xwiki-commons_master/xwiki-commons-core/xwiki-commons-extension/xwiki-commons-extension-api/src/main/java/org/xwiki/extension/version/internal/DefaultVersionConstraint.java:49:
> error: reference not found
> * @see org.sonatype.aether.util.version.GenericVersionConstraint
> {noformat}
> I noticed MJAVADOC-548 but since the documentation did not changed I assumed
> my use case was still OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
Falko Modler created MJAVADOC-602:
-
Summary: "Aggregating Javadocs For Multi-Projects" code snippet is
garbled and tag example is missing
Key: MJAVADOC-602
URL: https://issues.apache.org/jira/browse/MJAVADOC-602
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Falko Modler
Attachments: javadoc-aggregation-doc-formatting.PNG
After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
aggregation setup to 3.1.0.
It seems [the respective
documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
was extended with the info of [this JIRA
comment|https://issues.apache.org/jira/browse/MJAVADOC-134?focusedCommentId=16724514&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16724514],
but something went wrong with the formatting:
TODO
The other issue is that this bit doesn't cover the {{}} tag approach so
I was fiddling around with this and ended up with:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
false
false
{code}
Notes: {{mvn -N ...}} does not work, but I don't want a separate aggregation
for each module. So I skip the plugin in general/for all modules by _not_
inheriting {{false}}.
This (or some better solution) should be added to the docs.
PS: A flag/property to just skip the individual aggregations per module would
be very much appreciated!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
[
https://issues.apache.org/jira/browse/MJAVADOC-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MJAVADOC-602:
--
Description:
After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
aggregation setup to 3.1.0.
It seems [the respective
documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
was extended with the info of [this JIRA
comment|https://issues.apache.org/jira/browse/MJAVADOC-134?focusedCommentId=16724514&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16724514],
but something went wrong with the formatting:
!javadoc-aggregation-doc-formatting.PNG!
The other issue is that this bit doesn't cover the {{}} tag approach so
I was fiddling around with this and ended up with:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
false
false
{code}
Notes: {{mvn -N ...}} does not work, but I don't want a separate aggregation
for each module. So I skip the plugin in general/for all modules by _not_
inheriting {{false}}.
This (or some better solution) should be added to the docs.
PS: A flag/property to just skip the individual aggregations per module would
be very much appreciated!
was:
After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
aggregation setup to 3.1.0.
It seems [the respective
documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
was extended with the info of [this JIRA
comment|https://issues.apache.org/jira/browse/MJAVADOC-134?focusedCommentId=16724514&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16724514],
but something went wrong with the formatting:
TODO
The other issue is that this bit doesn't cover the {{}} tag approach so
I was fiddling around with this and ended up with:
{code:xml}
org.apache.maven.plugins
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
false
false
{code}
Notes: {{mvn -N ...}} does not work, but I don't want a separate aggregation
for each module. So I skip the plugin in general/for all modules by _not_
inheriting {{false}}.
This (or some better solution) should be added to the docs.
PS: A flag/property to just skip the individual aggregations per module would
be very much appreciated!
> "Aggregating Javadocs For Multi-Projects" code snippet is garbled and
> tag example is missing
> -
>
> Key: MJAVADOC-602
> URL: https://issues.apache.org/jira/browse/MJAVADOC-602
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Falko Modler
>Priority: Major
> Attachments: javadoc-aggregation-doc-formatting.PNG
>
>
> After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
> aggregation setup to 3.1.0.
> It seems [the respective
> documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
> was extended with the info of [this JIRA
> comment|https://issues.apache.org/jira/browse/MJAVADOC-134?focusedCommentId=16724514&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16724514],
> but something went wrong with the formatting:
> !javadoc-aggregation-doc-formatting.PNG!
> The other issue is that this bit doesn't cover the {{}} tag approach
> so I was fiddling around with this and ended up with:
> {code:xml}
>
>
>
>
[jira] [Commented] (MJAVADOC-134) Support aggregated reports at each level in the multi-module hierarchy
[
https://issues.apache.org/jira/browse/MJAVADOC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827253#comment-16827253
]
Falko Modler commented on MJAVADOC-134:
---
For those looking for a solution to retain the original bahaviour when using
{{}} (instead of {{reporting}}): Have a look at MJAVADOC-602.
> Support aggregated reports at each level in the multi-module hierarchy
> --
>
> Key: MJAVADOC-134
> URL: https://issues.apache.org/jira/browse/MJAVADOC-134
> Project: Maven Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: skaze
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: MJAVADOC-134_multiaggregate.zip
>
>
> The current system makes the assumption that if one wants aggregated reports
> one does not want further javadoc reports (aggregated ones) down the
> hierarchy. We do require this functionality and in fact do the same for all
> our reports (PMD, Checkstyle, Clover, JXR, Surefire, etc):
> A->B->C->D1 (JAR)
> A->B->C->D2 (JAR)
> A->B->E(JAR)
> A->F (JAR)
> A - javadoc for D1,D2,E,F
> B - javadoc for D1,D2,E
> C - javadoc for D1,D2
> D1 - javadoc for D1
> D2 - javadoc for D2
> E - javadoc for E
> F - javadoc for F
> This way there is the required info at the appropriate level throughout the
> hierarchy. And nope we dont care about space or generation times:)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-134) Support aggregated reports at each level in the multi-module hierarchy
[
https://issues.apache.org/jira/browse/MJAVADOC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827253#comment-16827253
]
Falko Modler edited comment on MJAVADOC-134 at 4/26/19 7:49 PM:
For those looking for a solution to retain the original bahaviour when using
{{}} (instead of {{}}): Have a look at MJAVADOC-602.
was (Author: famod):
For those looking for a solution to retain the original bahaviour when using
{{}} (instead of {{reporting}}): Have a look at MJAVADOC-602.
> Support aggregated reports at each level in the multi-module hierarchy
> --
>
> Key: MJAVADOC-134
> URL: https://issues.apache.org/jira/browse/MJAVADOC-134
> Project: Maven Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: skaze
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: MJAVADOC-134_multiaggregate.zip
>
>
> The current system makes the assumption that if one wants aggregated reports
> one does not want further javadoc reports (aggregated ones) down the
> hierarchy. We do require this functionality and in fact do the same for all
> our reports (PMD, Checkstyle, Clover, JXR, Surefire, etc):
> A->B->C->D1 (JAR)
> A->B->C->D2 (JAR)
> A->B->E(JAR)
> A->F (JAR)
> A - javadoc for D1,D2,E,F
> B - javadoc for D1,D2,E
> C - javadoc for D1,D2
> D1 - javadoc for D1
> D2 - javadoc for D2
> E - javadoc for E
> F - javadoc for F
> This way there is the required info at the appropriate level throughout the
> hierarchy. And nope we dont care about space or generation times:)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6653) DefaultProjectBuildingRequest copy constructor does not copy RepositoryMerging
Falko Modler created MNG-6653:
-
Summary: DefaultProjectBuildingRequest copy constructor does not
copy RepositoryMerging
Key: MNG-6653
URL: https://issues.apache.org/jira/browse/MNG-6653
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.6.1
Reporter: Falko Modler
{code:java}
public DefaultProjectBuildingRequest( ProjectBuildingRequest request )
{
this();
setProcessPlugins( request.isProcessPlugins() );
setProfiles( request.getProfiles() );
setActiveProfileIds( request.getActiveProfileIds() );
setInactiveProfileIds( request.getInactiveProfileIds() );
setSystemProperties( request.getSystemProperties() );
setUserProperties( request.getUserProperties() );
setRemoteRepositories( request.getRemoteRepositories() );
setPluginArtifactRepositories( request.getPluginArtifactRepositories()
);
setRepositorySession( request.getRepositorySession() );
setLocalRepository( request.getLocalRepository() );
setBuildStartTime( request.getBuildStartTime() );
setProject( request.getProject() );
setResolveDependencies( request.isResolveDependencies() );
setValidationLevel( request.getValidationLevel() );
}
{code}
This is missing {{setRepositoryMerging( request.request.getRepositoryMerging()
);}}.
PS: {{resolveVersionRanges}} is also "missing" but this is already
deprecated/not used anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6653) DefaultProjectBuildingRequest copy constructor does not copy RepositoryMerging
[
https://issues.apache.org/jira/browse/MNG-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MNG-6653:
--
Priority: Minor (was: Major)
> DefaultProjectBuildingRequest copy constructor does not copy RepositoryMerging
> --
>
> Key: MNG-6653
> URL: https://issues.apache.org/jira/browse/MNG-6653
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.1
>Reporter: Falko Modler
>Priority: Minor
>
> {code:java}
> public DefaultProjectBuildingRequest( ProjectBuildingRequest request )
> {
> this();
> setProcessPlugins( request.isProcessPlugins() );
> setProfiles( request.getProfiles() );
> setActiveProfileIds( request.getActiveProfileIds() );
> setInactiveProfileIds( request.getInactiveProfileIds() );
> setSystemProperties( request.getSystemProperties() );
> setUserProperties( request.getUserProperties() );
> setRemoteRepositories( request.getRemoteRepositories() );
> setPluginArtifactRepositories(
> request.getPluginArtifactRepositories() );
> setRepositorySession( request.getRepositorySession() );
> setLocalRepository( request.getLocalRepository() );
> setBuildStartTime( request.getBuildStartTime() );
> setProject( request.getProject() );
> setResolveDependencies( request.isResolveDependencies() );
> setValidationLevel( request.getValidationLevel() );
> }
> {code}
> This is missing {{setRepositoryMerging(
> request.request.getRepositoryMerging() );}}.
> PS: {{resolveVersionRanges}} is also "missing" but this is already
> deprecated/not used anymore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-134) Support aggregated reports at each level in the multi-module hierarchy
[
https://issues.apache.org/jira/browse/MJAVADOC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827253#comment-16827253
]
Falko Modler edited comment on MJAVADOC-134 at 5/22/19 1:23 PM:
For those looking for a solution to retain the original behaviour when using
{{}} (instead of {{}}): Have a look at MJAVADOC-602.
was (Author: famod):
For those looking for a solution to retain the original bahaviour when using
{{}} (instead of {{}}): Have a look at MJAVADOC-602.
> Support aggregated reports at each level in the multi-module hierarchy
> --
>
> Key: MJAVADOC-134
> URL: https://issues.apache.org/jira/browse/MJAVADOC-134
> Project: Maven Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.2
>Reporter: skaze
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.1.0
>
> Attachments: MJAVADOC-134_multiaggregate.zip
>
>
> The current system makes the assumption that if one wants aggregated reports
> one does not want further javadoc reports (aggregated ones) down the
> hierarchy. We do require this functionality and in fact do the same for all
> our reports (PMD, Checkstyle, Clover, JXR, Surefire, etc):
> A->B->C->D1 (JAR)
> A->B->C->D2 (JAR)
> A->B->E(JAR)
> A->F (JAR)
> A - javadoc for D1,D2,E,F
> B - javadoc for D1,D2,E
> C - javadoc for D1,D2
> D1 - javadoc for D1
> D2 - javadoc for D2
> E - javadoc for E
> F - javadoc for F
> This way there is the required info at the appropriate level throughout the
> hierarchy. And nope we dont care about space or generation times:)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCHECKSTYLE-377) Violations or exception when using FQCNs in @throws after upgrade to 3.1.0
Falko Modler created MCHECKSTYLE-377:
Summary: Violations or exception when using FQCNs in @throws after
upgrade to 3.1.0
Key: MCHECKSTYLE-377
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-377
Project: Maven Checkstyle Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Environment: Apache Maven 3.6.1
(d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T21:00:29+02:00)
Java version: 1.8.0_202, vendor: Oracle Corporation
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
Reporter: Falko Modler
I started to see strange violations and even exceptions after upgrading
checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to
8.7, so the Checkstyle version itself did _not_ change in my setup.
The problem boils down to Checkstyle not being able anymore to load classes
that reside in dependencies (= not im the same project as the checked class)
when using fully qualified class names in {{@throws}} tags, e.g.:
{code:java}
/**
* Foo.
* @throws some.other.project.SomeException some exception.
*/
public void foo() throws SomeException {
// ...
}
{code}
Please note that the actual throws declaration does _not_ use the fully
qualified class name.
While this might be an inconsistent/non DRY approach, it is not forbidden by
JavaDoc or the compiler.
In one case (where the exception resides in an external dependency), this
resulted in a violation:
{noformat}
JavadocMethod: Expected @throws tag for 'SomeException'.
{noformat}
In another case (where the exception resides in the same module but implements
an interface that resides in another module of the project being built), this
resulted in an exception:
{noformat}
[...]
Caused by: java.lang.NoClassDefFoundError:
some/project/othermodule/SomeInterface
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
at
com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
at com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
at
com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
at com.puppycrawl.tools.checkstyle.Checker.processFile(Checker.java:319)
at
com.puppycrawl.tools.checkstyle.Checker.processFiles(Checker.java:289)
... 25 more
Caused by: java.lang.ClassNotFoundException:
com.t_systems_mms.ccs.common.base.service.exception.ExceptionAttributeInterface
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 54 more
{noformat}
I guess this is caused by MCHECKSTYLE-353 (which does
[jira] [Updated] (MCHECKSTYLE-377) Violations or exceptions when using FQCNs in @throws after upgrade to 3.1.0
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCHECKSTYLE-377:
-
Summary: Violations or exceptions when using FQCNs in @throws after upgrade
to 3.1.0 (was: Violations or exception when using FQCNs in @throws after
upgrade to 3.1.0)
> Violations or exceptions when using FQCNs in @throws after upgrade to 3.1.0
> ---
>
> Key: MCHECKSTYLE-377
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-377
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.6.1
> (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T21:00:29+02:00)
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Major
>
> I started to see strange violations and even exceptions after upgrading
> checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle
> to 8.7, so the Checkstyle version itself did _not_ change in my setup.
> The problem boils down to Checkstyle not being able anymore to load classes
> that reside in dependencies (= not im the same project as the checked class)
> when using fully qualified class names in {{@throws}} tags, e.g.:
> {code:java}
> /**
> * Foo.
> * @throws some.other.project.SomeException some exception.
> */
> public void foo() throws SomeException {
> // ...
> }
> {code}
> Please note that the actual throws declaration does _not_ use the fully
> qualified class name.
> While this might be an inconsistent/non DRY approach, it is not forbidden by
> JavaDoc or the compiler.
> In one case (where the exception resides in an external dependency), this
> resulted in a violation:
> {noformat}
> JavadocMethod: Expected @throws tag for 'SomeException'.
> {noformat}
> In another case (where the exception resides in the same module but
> implements an interface that resides in another module of the project being
> built), this resulted in an exception:
> {noformat}
> [...]
> Caused by: java.lang.NoClassDefFoundError:
> some/project/othermodule/SomeInterface
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
> at
> com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
> at
> com.puppycrawl.tools.checks
[jira] [Commented] (MCHECKSTYLE-353) Don't resolve any dependencies
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846609#comment-16846609 ] Falko Modler commented on MCHECKSTYLE-353: -- Note: I am almost sure this change is causing MCHECKSTYLE-377. > Don't resolve any dependencies > -- > > Key: MCHECKSTYLE-353 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-353 > Project: Maven Checkstyle Plugin > Issue Type: Improvement > Components: checkstyle:check >Affects Versions: 3.0.0 >Reporter: Zoran Regvart >Assignee: Enrico Olivelli >Priority: Major > Fix For: 3.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Not sure why resolving dependencies is needed for running Checkstyle, it does > slow down the build considerably. For Apache Camel this makes a ten fold > difference from ~20mins to ~2mins for running mvn checkstyle:check. > Seems this was introduced with MCHECKSTYLE-163 but subsequently integration > test was removed in MCHECKSTYLE-272. > I've created a GitHub pull request to address this: > https://github.com/apache/maven-checkstyle-plugin/pull/5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCHECKSTYLE-377) Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCHECKSTYLE-377:
-
Summary: Violations or exceptions when using "external" FQCNs in @throws
after upgrade to 3.1.0 (was: Violations or exceptions when using FQCNs in
@throws after upgrade to 3.1.0)
> Violations or exceptions when using "external" FQCNs in @throws after upgrade
> to 3.1.0
> --
>
> Key: MCHECKSTYLE-377
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-377
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
> Environment: Apache Maven 3.6.1
> (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T21:00:29+02:00)
> Java version: 1.8.0_202, vendor: Oracle Corporation
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Major
>
> I started to see strange violations and even exceptions after upgrading
> checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle
> to 8.7, so the Checkstyle version itself did _not_ change in my setup.
> The problem boils down to Checkstyle not being able anymore to load classes
> that reside in dependencies (= not im the same project as the checked class)
> when using fully qualified class names in {{@throws}} tags, e.g.:
> {code:java}
> /**
> * Foo.
> * @throws some.other.project.SomeException some exception.
> */
> public void foo() throws SomeException {
> // ...
> }
> {code}
> Please note that the actual throws declaration does _not_ use the fully
> qualified class name.
> While this might be an inconsistent/non DRY approach, it is not forbidden by
> JavaDoc or the compiler.
> In one case (where the exception resides in an external dependency), this
> resulted in a violation:
> {noformat}
> JavadocMethod: Expected @throws tag for 'SomeException'.
> {noformat}
> In another case (where the exception resides in the same module but
> implements an interface that resides in another module of the project being
> built), this resulted in an exception:
> {noformat}
> [...]
> Caused by: java.lang.NoClassDefFoundError:
> some/project/othermodule/SomeInterface
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
> at
> com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
> at
> com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
> at
> com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
>
[jira] [Updated] (MCHECKSTYLE-377) Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCHECKSTYLE-377:
-
Description:
I started to see strange violations and even exceptions after upgrading
checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to
8.7, so the Checkstyle version itself did _not_ change in my setup.
The problem boils down to Checkstyle not being able anymore to load classes
that reside in dependencies (= not im the same project as the checked class)
when using fully qualified class names in {{@throws}} tags, e.g.:
{code:java}
/**
* Foo.
* @throws some.other.project.SomeException some exception.
*/
public void foo() throws SomeException {
// ...
}
{code}
Please note that the actual throws declaration does _not_ use the fully
qualified class name.
While this might be an inconsistent/non DRY approach, it is not forbidden by
JavaDoc or the compiler.
In one case (where the exception resides in an external dependency), this
resulted in a violation:
{noformat}
JavadocMethod: Expected @throws tag for 'SomeException'.
{noformat}
In another case (where the exception resides in the same module but implements
an interface that resides in another module of the project being built), this
resulted in an exception:
{noformat}
[...]
Caused by: java.lang.NoClassDefFoundError:
some/project/othermodule/SomeInterface
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
at
com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
at com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
at
com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
at com.puppycrawl.tools.checkstyle.Checker.processFile(Checker.java:319)
at
com.puppycrawl.tools.checkstyle.Checker.processFiles(Checker.java:289)
... 25 more
Caused by: java.lang.ClassNotFoundException:
com.t_systems_mms.ccs.common.base.service.exception.ExceptionAttributeInterface
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 54 more
{noformat}
I guess this is caused by MCHECKSTYLE-353 (which does improve runtime a lot
when {{checkstyle:check}} is invoked explicitly).
*Workaround*: Don't use fully qualified exception class names in {{@throws}}.
PS: This might actually be a shortcomming in Checkstyle itself and it also
might affect more than just {{@throws}}.
was:
I started to see strange violations and even exceptions after upgrading
checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to
8.7, so the Checkstyle version itself did _not_ change
[jira] [Updated] (MCHECKSTYLE-377) Violations or exceptions when using "external" FQCNs in @throws after upgrade to 3.1.0
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated MCHECKSTYLE-377:
-
Description:
I started to see strange violations and even exceptions after upgrading
checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to
8.7, so the Checkstyle version itself did _not_ change in my setup.
The problem boils down to Checkstyle not being able anymore to load classes
that reside in dependencies (= not im the same project as the checked class)
when using fully qualified class names in {{@throws}} tags, e.g.:
{code:java}
/**
* Foo.
* @throws some.other.project.SomeException some exception.
*/
public void foo() throws SomeException {
// ...
}
{code}
Please note that the actual throws declaration does _not_ use the fully
qualified class name.
While this might be an inconsistent/non DRY approach, it is not forbidden by
JavaDoc or the compiler.
In one case (where the exception resides in an external dependency), this
resulted in a violation:
{noformat}
JavadocMethod: Expected @throws tag for 'SomeException'.
{noformat}
In another case (where the exception resides in the same module but implements
an interface that resides in another module of the project being built), this
resulted in an exception:
{noformat}
[...]
Caused by: java.lang.NoClassDefFoundError:
some/project/othermodule/SomeInterface
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.safeLoad(ClassResolver.java:216)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.ClassResolver.resolve(ClassResolver.java:95)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.resolveClass(AbstractTypeAwareCheck.java:241)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.tryLoadClass(AbstractTypeAwareCheck.java:258)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck$RegularClass.getClazz(AbstractTypeAwareCheck.java:467)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkThrowsTags(JavadocMethodCheck.java:909)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.checkComment(JavadocMethodCheck.java:503)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck.processAST(JavadocMethodCheck.java:357)
at
com.puppycrawl.tools.checkstyle.checks.javadoc.AbstractTypeAwareCheck.visitToken(AbstractTypeAwareCheck.java:157)
at
com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:423)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:579)
at com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:363)
at
com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:208)
at
com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:83)
at com.puppycrawl.tools.checkstyle.Checker.processFile(Checker.java:319)
at
com.puppycrawl.tools.checkstyle.Checker.processFiles(Checker.java:289)
... 25 more
Caused by: java.lang.ClassNotFoundException:
some.project.othermodule.SomeInterface
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 54 more
{noformat}
I guess this is caused by MCHECKSTYLE-353 (which does improve runtime a lot
when {{checkstyle:check}} is invoked explicitly).
*Workaround*: Don't use fully qualified exception class names in {{@throws}}.
PS: This might actually be a shortcomming in Checkstyle itself and it also
might affect more than just {{@throws}}.
was:
I started to see strange violations and even exceptions after upgrading
checkstyle-plugin from 3.0.0 and 3.1.0. Please note that I pinned Checkstyle to
8.7, so the Checkstyle version itself did _not_ change in my setup.
The problem boils down to C
[jira] [Comment Edited] (MNG-5897) Make extensions configurable in a more convenient way.
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182858#comment-17182858
]
Falko Modler edited comment on MNG-5897 at 8/23/20, 9:41 PM:
-
Better configuration support for extensions would be very much appreciated!
I am maintaining https://github.com/vackosar/gitflow-incremental-builder (GIB)
and I just recently added a "fake" plugin/mojo to expose the many properties
(and their descriptions) in an IDE and help-plugin friendly way.
This comes at the price of either maintaining the properties twice manually or
at the price of added complexity for generating the plugin parameters (see
[MojoParametersGeneratingByteBuddyPlugin|https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo/MojoParametersGeneratingByteBuddyPlugin.java]).
It would be really great if (with the proposed solution) extension parameters
and their descriptions would be picked up by IDEs and the help-plugin.
Another approach might be to enhance the plugin + extension hybrid setup (like
GIB is using) to have {{@Parameter}} (or something else) recognized on non-mojo
classes.
Btw: The downside of {{.mvn/extensions.xml}} is that you cannot use profiles
there and I am not sure whether tools like GitHub Dependabot will pick up such
extensions (defined outside of {{pom.xml}}).
was (Author: famod):
Better configuration support for extensions would be very much appreciated!
I am maintaining https://github.com/vackosar/gitflow-incremental-builder (GIB)
and I just recently added a "fake" plugin/mojo to expose the many properties
(and their descriptions) in an IDE and help-plugin friendly way.
This comes at the price of either maintaining the properties twice manually or
at the price of added complexity for generating the plugin parameters (see
[MojoParametersGeneratingByteBuddyPlugin|https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo/MojoParametersGeneratingByteBuddyPlugin.java]).
It would be really great if (with the proposed solution) extension parameters
and their descriptions would be picked up by IDEs and the help-plugin.
Another approach might be to enhance the plugin + extension hybrid setup (like
GIB is using) to have `@Parameter` (or something else) recognized on non-mojo
classes.
Btw: The downside of {{.mvn/extensions.xml}} is that you cannot use profiles
there and I am not sure whether tools like GitHub Dependabot will pick up such
extensions (defined outside of {{pom.xml}}).
> Make extensions configurable in a more convenient way.
> --
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5897) Make extensions configurable in a more convenient way.
[
https://issues.apache.org/jira/browse/MNG-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182858#comment-17182858
]
Falko Modler commented on MNG-5897:
---
Better configuration support for extensions would be very much appreciated!
I am maintaining https://github.com/vackosar/gitflow-incremental-builder (GIB)
and I just recently added a "fake" plugin/mojo to expose the many properties
(and their descriptions) in an IDE and help-plugin friendly way.
This comes at the price of either maintaining the properties twice manually or
at the price of added complexity for generating the plugin parameters (see
[MojoParametersGeneratingByteBuddyPlugin|https://github.com/vackosar/gitflow-incremental-builder/blob/master/src/main/java/com/vackosar/gitflowincrementalbuild/mojo/MojoParametersGeneratingByteBuddyPlugin.java]).
It would be really great if (with the proposed solution) extension parameters
and their descriptions would be picked up by IDEs and the help-plugin.
Another approach might be to enhance the plugin + extension hybrid setup (like
GIB is using) to have `@Parameter` (or something else) recognized on non-mojo
classes.
Btw: The downside of {{.mvn/extensions.xml}} is that you cannot use profiles
there and I am not sure whether tools like GitHub Dependabot will pick up such
extensions (defined outside of {{pom.xml}}).
> Make extensions configurable in a more convenient way.
> --
>
> Key: MNG-5897
> URL: https://issues.apache.org/jira/browse/MNG-5897
> Project: Maven
> Issue Type: New Feature
> Components: core
>Affects Versions: 3.3.3
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> Currently you can configure using an extensions via {{.mvn/extensions.xml}}
> to load it.
> But at the moment the only possibility to configure your extensions (or
> control behaviour) is via system properties like {{-Dwhatever=...}}.
> It would be convenient to make configuration possible in
> {{.mvn/extensions.xml}} like the plugin configuration are in pom file...
> {code:xml}
> http://maven.apache.org/EXTENSIONS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd";>
>
>
>
>
>
> ...
>
>
>
> {code}
> with some kind of replacements like in the pom.xml file (like
> {{$\{project.basedir}}} etc.) ?
> This could make the usage of extensions much more convenient...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build
[
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187254#comment-17187254
]
Falko Modler commented on MNG-6979:
---
I think there is a misunderstanding regarding the linked pull request.
The PR adds a workaround to a Maven extension
([gitflow-incremental-builder|https://github.com/vackosar/gitflow-incremental-builder])
that was running into this Maven core problem while [~gastaldi] was trying out
the extension in Quarkus.
So AFAICS there is no PR containing the core fix yet.
> MavenSession.getCurrentProject may return an incorrect project in a
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
>
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a
> project that depends on a module with the same parent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
