[jira] [Commented] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758031#comment-16758031 ] Robert Scholte commented on MNG-6584: - See WAGON-541 > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Reporter: Lucas Ludueño >Priority: Blocker > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names
[
https://issues.apache.org/jira/browse/SUREFIRE-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757999#comment-16757999
]
Tibor Digana commented on SUREFIRE-1546:
[~dantran]
How you expect to use the string of display name?
In Report XML or file name of the report XML?
Currently it is like that but it should not be. The reports should be unique as
the Java test class names are.
We plan to print display name in {{std-out}} and {{std-err}}.
> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
> Fix For: 3.0.0-M4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the
> classname if any is defined. Seems last release doesn't support that feature
> of JUnit 5 making the console output and reports not the expected ones.
>
> Origin: https://github.com/junit-team/junit5/issues/990
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] Tibor17 commented on issue #217: Set properties readonly where it doesn't make sense to change values
Tibor17 commented on issue #217: Set properties readonly where it doesn't make sense to change values URL: https://github.com/apache/maven-surefire/pull/217#issuecomment-459614013 We can make readonly of Repository right now, but I would hold on with the rest because we have a chance to use Surefire `3.0.0-M4` in Maven `3.7.0` and there we must not break the backwards compatibility. Version `3.0.0-M5` makes sense for me. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] Tibor17 commented on issue #219: Add missing since tags to excludesFile and includesFile
Tibor17 commented on issue #219: Add missing since tags to excludesFile and includesFile URL: https://github.com/apache/maven-surefire/pull/219#issuecomment-459613246 @britter Pls rebase this PR. We can push it. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run
[ https://issues.apache.org/jira/browse/SUREFIRE-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757823#comment-16757823 ] Chris Graham commented on SUREFIRE-1623: In addition, I am unable to build surefire on XP (32) either - it hangs at the WMIC calls. What exactly was the driver for the change to using WMIC in the first place? > TempWmicBatchFile.bat is left in project dirs after surefire tests are run > -- > > Key: SUREFIRE-1623 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1623 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Chris Graham >Priority: Blocker > > WINDOWS ONLY: > When the WMIC command it run to obtain the process start time, the current > implementation leaves behind a batch file, TempWmicBatchFile.bat, which is > zero bytes long. > This file needs to be removed post execution. > Leaving it behind will interfere with the release plugin as a scm status call > will fail with files needing to be added. Simply ignoring the file is a very > sloppy approach. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] famod commented on issue #43: [MENFORCER-314] - Warn if EnforcerRuleException has no message
famod commented on issue #43: [MENFORCER-314] - Warn if EnforcerRuleException has no message URL: https://github.com/apache/maven-enforcer/pull/43#issuecomment-459552062 @eolivelli I had a quick look at the existing integration tests and I have to say that I have **no** clue how to test this very specific (and rare) case with capabilities of maven-invoker-plugin. I mean, I would need to provoke a NPE or similar in a existing rule. How would one do that? Extending `TestEnforceMojo` seems more doable, IMHO. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies
eolivelli commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-459542448 @zregvart thank you ! Now we are sure that we are not breaking those implementations. @rmannibucau do you have time to take a look again? Thank you in advance This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (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=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] [Updated] (SUREFIRE-1632) ClassNotFoundException, multi-module Maven project, forkCount > 1
[
https://issues.apache.org/jira/browse/SUREFIRE-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kaib updated SUREFIRE-1632:
---
Description:
Base configuration:
* Windows 10
* Maven 3.6.0
* Mixed Java 8 and Scala 2.11.8
* JMockit
I'm trying update my SureFire configuration in a multi-module project from:
* SureFire 2.20
* JUnit 5.01
to:
* SureFire 2.22.1
* JUnit 5 1.3.2
This is the SureFire configuration I've come up with:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.22.1
2
2
true
-XX:-TieredCompilation -Xint
-javaagent:${org.jmockit:jmockit:jar} @{surefireArgLine} -server
**/*Suite.class
**/*Test.class
**/*Tests.class
**/*Spec.class
**/*Specs.class
**/*ITest.class
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=dynamic
listener
org.evosuite.runtime.InitializingListener
{code}
When I run the multi-module build (mvn test), the second module fails with the
error:
{noformat}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 05:52 min
[INFO] Finished at: 2019-01-30T13:09:43-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on
project guardians: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test failed: A required
class was missing while executing
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test:
org/apache/maven/surefire/report/ConsoleOutputReceiver
[ERROR] -
[ERROR] realm = plugin>org.apache.maven.plugins:maven-surefire-plugin:2.22.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.22.1/maven-surefire-plugin-2.22.1.jar
[ERROR] urls[1] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/maven-surefire-common/2.22.1/maven-surefire-common-2.22.1.jar
[ERROR] urls[2] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.5.2/maven-plugin-annotations-3.5.2.jar
[ERROR] urls[3] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-api/2.22.1/surefire-api-2.22.1.jar
[ERROR] urls[4] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-logger-api/2.22.1/surefire-logger-api-2.22.1.jar
[ERROR] urls[5] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-booter/2.22.1/surefire-booter-2.22.1.jar
[ERROR] urls[6] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
[ERROR] urls[7] =
file:/C:/Users/starlord/.m2/repository/junit/junit/4.12/junit-4.12.jar
[ERROR] urls[8] =
file:/C:/Users/starlord/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] urls[9] =
file:/C:/Users/starlord/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[10] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[11] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[12] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[13] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.0/maven-reporting-api-3.0.jar
[ERROR] urls[14] =
file:/C:/Users/starlord/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[15] =
file:/C:/Users/starlord/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[16] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-java/0.9.10/plexus-java-0.9.10.jar
[ERROR] urls[17] =
file:/C:/Users/starlord/.m2/repository/org/ow2/asm/asm/6.2/asm-6.2.jar
[ERROR] urls[18] =
[jira] [Commented] (MSHARED-798) Add defaultEntries option
[
https://issues.apache.org/jira/browse/MSHARED-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757762#comment-16757762
]
Hervé Boutemy commented on MSHARED-798:
---
ok, logged the dependency on MSHARED-799
> Add defaultEntries option
> -
>
> Key: MSHARED-798
> URL: https://issues.apache.org/jira/browse/MSHARED-798
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> Based on MSHARED-362 one should have the option to disable default
> (reproducible) manifest entries explicitly: {{Created-By}},
> {{Build-Jdk-Spec}} with the option {{addDefaultEntries: true}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-787) Add optional buildEnvironment information to the manifest
[
https://issues.apache.org/jira/browse/MSHARED-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757760#comment-16757760
]
Hervé Boutemy commented on MSHARED-787:
---
MSHARED-799 issue created for the {{Created-By}} entry value change
> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> People are demanding to have more control about the build information
> (MSHARED-362). We should add the following to control this:
> {{ which is by default disabled. It will
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Build-Tool: ${maven.build.version:-Apache Maven}
> Build-Jdk: ${java.version} (${java.vendor})
> Build-Os: ${os.name} (${os.version}; (${os.arch})
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-799) change "Created-By" manifest entry value to reproducible one
Hervé Boutemy created MSHARED-799:
-
Summary: change "Created-By" manifest entry value to reproducible
one
Key: MSHARED-799
URL: https://issues.apache.org/jira/browse/MSHARED-799
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-archiver
Affects Versions: maven-archiver-3.3.0
Reporter: Hervé Boutemy
Fix For: maven-archiver-3.4.0
as seen during work on MSHARED-787, the current value for {{Created-By}} entry
is {{Maven $\{maven.version}}} which is not reproducible
it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
and an easy to use API for plugins that use the component to override the value
with a more precise value like {{Maven XXX Plugin $\{version\}}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
[
https://issues.apache.org/jira/browse/MJAVADOC-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-574.
---
Resolution: Not A Bug
Assignee: Robert Scholte
> Unable to inherit Javadoc comments for overriden JDK methods
>
>
> Key: MJAVADOC-574
> URL: https://issues.apache.org/jira/browse/MJAVADOC-574
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: JDK 11.0.2
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testcase.zip
>
>
> If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
> any overriden methods end up with empty Javadoc (aside from a small
> "Overrides" section. According to
> [https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
> the inherited method must be on the {{-sourcepath}} but I'm not sure whether
> that's even possible for core JDK classes. I mean, am I supposed to download
> the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1632) ClassNotFoundException, multi-module Maven project, forkCount > 1
[
https://issues.apache.org/jira/browse/SUREFIRE-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kaib updated SUREFIRE-1632:
---
Description:
Base configuration:
* Windows 10
* Maven 3.6.0
* Mixed Java 8 and Scala 2.11.8
* JMockit
I'm trying update my SureFire configuration in a multi-module project from:
* SureFire 2.20
* JUnit 5.01
to:
* SureFire 2.22.1
* JUnit 5 v1.3.2
This is the SureFire configuration I've come up with:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.22.1
2
2
true
-XX:-TieredCompilation -Xint
-javaagent:${org.jmockit:jmockit:jar} @{surefireArgLine} -server
**/*Suite.class
**/*Test.class
**/*Tests.class
**/*Spec.class
**/*Specs.class
**/*ITest.class
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=dynamic
listener
org.evosuite.runtime.InitializingListener
{code}
When I run the multi-module build (mvn test), the second module fails with the
error:
{noformat}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 05:52 min
[INFO] Finished at: 2019-01-30T13:09:43-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on
project guardians: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test failed: A required
class was missing while executing
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test:
org/apache/maven/surefire/report/ConsoleOutputReceiver
[ERROR] -
[ERROR] realm = plugin>org.apache.maven.plugins:maven-surefire-plugin:2.22.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.22.1/maven-surefire-plugin-2.22.1.jar
[ERROR] urls[1] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/maven-surefire-common/2.22.1/maven-surefire-common-2.22.1.jar
[ERROR] urls[2] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.5.2/maven-plugin-annotations-3.5.2.jar
[ERROR] urls[3] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-api/2.22.1/surefire-api-2.22.1.jar
[ERROR] urls[4] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-logger-api/2.22.1/surefire-logger-api-2.22.1.jar
[ERROR] urls[5] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-booter/2.22.1/surefire-booter-2.22.1.jar
[ERROR] urls[6] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
[ERROR] urls[7] =
file:/C:/Users/starlord/.m2/repository/junit/junit/4.12/junit-4.12.jar
[ERROR] urls[8] =
file:/C:/Users/starlord/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] urls[9] =
file:/C:/Users/starlord/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[10] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[11] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[12] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[13] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.0/maven-reporting-api-3.0.jar
[ERROR] urls[14] =
file:/C:/Users/starlord/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[15] =
file:/C:/Users/starlord/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[16] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-java/0.9.10/plexus-java-0.9.10.jar
[ERROR] urls[17] =
file:/C:/Users/starlord/.m2/repository/org/ow2/asm/asm/6.2/asm-6.2.jar
[ERROR] urls[18] =
[jira] [Created] (SUREFIRE-1632) ClassNotFoundException, multi-module Maven project, forkCount > 1
Jim Kaib created SUREFIRE-1632:
--
Summary: ClassNotFoundException, multi-module Maven project,
forkCount > 1
Key: SUREFIRE-1632
URL: https://issues.apache.org/jira/browse/SUREFIRE-1632
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin, process forking
Affects Versions: 2.22.1
Reporter: Jim Kaib
Base configuration:
* Windows 10
* Maven 3.6.0
* Mixed Java 8 and Scala 2.11.8
* JMockit
I'm trying update my SureFire configuration in a multi-module project from:
* SureFire 2.20
* JUnit 5.01
to:
* SureFire 2.22.1
* JUnit 5 v1.3.2
This is the SureFire configuration I've come up with:
{code:xml}
org.apache.maven.plugins
maven-surefire-plugin
2.22.1
2
2
true
-XX:-TieredCompilation -Xint
-javaagent:${org.jmockit:jmockit:jar} @{surefireArgLine} -server
**/*Suite.class
**/*Test.class
**/*Tests.class
**/*Spec.class
**/*Specs.class
**/*ITest.class
junit.jupiter.execution.parallel.enabled=true
junit.jupiter.execution.parallel.config.strategy=dynamic
listener
org.evosuite.runtime.InitializingListener
{code}
When I run the multi-module build (mvn test), the second module fails with the
error:
{noformat}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 05:52 min
[INFO] Finished at: 2019-01-30T13:09:43-05:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on
project guardians: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test failed: A required
class was missing while executing
org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test:
org/apache/maven/surefire/report/ConsoleOutputReceiver
[ERROR] -
[ERROR] realm = plugin>org.apache.maven.plugins:maven-surefire-plugin:2.22.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugins/maven-surefire-plugin/2.22.1/maven-surefire-plugin-2.22.1.jar
[ERROR] urls[1] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/maven-surefire-common/2.22.1/maven-surefire-common-2.22.1.jar
[ERROR] urls[2] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.5.2/maven-plugin-annotations-3.5.2.jar
[ERROR] urls[3] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-api/2.22.1/surefire-api-2.22.1.jar
[ERROR] urls[4] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-logger-api/2.22.1/surefire-logger-api-2.22.1.jar
[ERROR] urls[5] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/surefire/surefire-booter/2.22.1/surefire-booter-2.22.1.jar
[ERROR] urls[6] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
[ERROR] urls[7] =
file:/C:/Users/starlord/.m2/repository/junit/junit/4.12/junit-4.12.jar
[ERROR] urls[8] =
file:/C:/Users/starlord/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
[ERROR] urls[9] =
file:/C:/Users/starlord/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[10] =
file:/C:/Users/starlord/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[11] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
[ERROR] urls[12] =
file:/C:/Users/starlord/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
[ERROR] urls[13] =
file:/C:/Users/starlord/.m2/repository/org/apache/maven/reporting/maven-reporting-api/3.0/maven-reporting-api-3.0.jar
[ERROR] urls[14] =
file:/C:/Users/starlord/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[15] =
[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=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] [Updated] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
[
https://issues.apache.org/jira/browse/MDEP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Solecki updated MDEP-639:
--
Description:
When you run:
{code:sh}
$ mvn dependency:tree -Dverbose
{code}
it does not show omitted dependencies.
It happens for version 3+.
When I change to 2.10 it is working flawlessly
Environment details:
{code:sh}
$ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: /home/grzsol1/dev/tls/mvn/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
/home/grzsol1/dev/jdk/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
{code}
was:
When you run:
{code:sh}
mvn dependency:tree -Dverbose
{code}
it does not show omitted dependencies.
It happens for version 3+.
When I change to 2.10 it is working flawlessly
Environment details:
maven-dependency-plugin
{code:sh}
$ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: /home/grzsol1/dev/tls/mvn/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
/home/grzsol1/dev/jdk/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
{code}
> Not showing omitted dependencies when running dependency:tree verbose
> -
>
> Key: MDEP-639
> URL: https://issues.apache.org/jira/browse/MDEP-639
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.1.1
> Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
> 4.15.0-44-generic x86_64
>Reporter: Grzegorz Solecki
>Priority: Major
>
> When you run:
> {code:sh}
> $ mvn dependency:tree -Dverbose
> {code}
> it does not show omitted dependencies.
> It happens for version 3+.
> When I change to 2.10 it is working flawlessly
> Environment details:
> {code:sh}
> $ mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: /home/grzsol1/dev/tls/mvn/current
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /home/grzsol1/dev/jdk/jdk1.8.0_191/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
> Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
[
https://issues.apache.org/jira/browse/MDEP-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Solecki updated MDEP-639:
--
Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
4.15.0-44-generic x86_64 (was: $ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: /home/grzsol1/dev/tls/mvn/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
/home/grzsol1/dev/jdk/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
)
Description:
When you run:
{code:sh}
mvn dependency:tree -Dverbose
{code}
it does not show omitted dependencies.
It happens for version 3+.
When I change to 2.10 it is working flawlessly
Environment details:
maven-dependency-plugin
{code:sh}
$ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: /home/grzsol1/dev/tls/mvn/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
/home/grzsol1/dev/jdk/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
{code}
was:
When you run:
{code:sh}
mvn dependency:tree -Dverbose
{code}
it does not show omitted dependencies.
It happens for version 3+.
When I change to 2.10 it is working flawlessly.
> Not showing omitted dependencies when running dependency:tree verbose
> -
>
> Key: MDEP-639
> URL: https://issues.apache.org/jira/browse/MDEP-639
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.1.1
> Environment: Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux
> 4.15.0-44-generic x86_64
>Reporter: Grzegorz Solecki
>Priority: Major
>
> When you run:
> {code:sh}
> mvn dependency:tree -Dverbose
> {code}
> it does not show omitted dependencies.
> It happens for version 3+.
> When I change to 2.10 it is working flawlessly
> Environment details:
> maven-dependency-plugin
> {code:sh}
> $ mvn -version
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T14:41:47-04:00)
> Maven home: /home/grzsol1/dev/tls/mvn/current
> Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
> /home/grzsol1/dev/jdk/jdk1.8.0_191/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
> Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
Lucas Ludueño created MNG-6584: -- Summary: Maven version 3.6.0 does not show ReasonPhrase anymore Key: MNG-6584 URL: https://issues.apache.org/jira/browse/MNG-6584 Project: Maven Issue Type: Bug Reporter: Lucas Ludueño Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for example when you run mvn deploy to a custom Maven service). With version 3.5.0 the ReasonPhrase is shown in a message like: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project mule-module-tooling-service: Failed to deploy artifacts: Could not transfer artifact 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 from/to exchange-repository (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to transfer file: http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] I am not completely sure if the ReasonPhrase has been removed intentionally. If the answer is no, can you fix it? If the answer is yes, how can I simulate the behavior to indicate to someone what was happening? Thanks!! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEP-639) Not showing omitted dependencies when running dependency:tree verbose
Grzegorz Solecki created MDEP-639:
-
Summary: Not showing omitted dependencies when running
dependency:tree verbose
Key: MDEP-639
URL: https://issues.apache.org/jira/browse/MDEP-639
Project: Maven Dependency Plugin
Issue Type: Bug
Components: tree
Affects Versions: 3.1.1
Environment: $ mvn -version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T14:41:47-04:00)
Maven home: /home/grzsol1/dev/tls/mvn/current
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime:
/home/grzsol1/dev/jdk/jdk1.8.0_191/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-44-generic", arch: "amd64", family: "unix"
Ubuntu 18.04.1 LTS (64-bit) Bionic Beaver Linux 4.15.0-44-generic x86_64
Reporter: Grzegorz Solecki
When you run:
{code:sh}
mvn dependency:tree -Dverbose
{code}
it does not show omitted dependencies.
It happens for version 3+.
When I change to 2.10 it is working flawlessly.
--
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=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] [Reopened] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
[ https://issues.apache.org/jira/browse/MSHARED-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reopened MSHARED-339: > DependencyGraphBuilder does not provide verbose tree > > > Key: MSHARED-339 > URL: https://issues.apache.org/jira/browse/MSHARED-339 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.1 >Reporter: Paul Gier >Priority: Major > > The dependency graph builder provides a dependency tree which has already > filtered out duplicate dependencies. In some cases such as testing > dependency convergence or viewing the verbose dependency tree, it's useful to > get information about the full tree including duplicates. > The dependency graph builder should provide an option for including the > unfiltered dependency tree. -- 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=16757678#comment-16757678
]
Christian Cygnus commented on MENFORCER-271:
Has there been any additional work or investigation regarding this issue? My
team thinks it's an important issue, and may be able to contribute work towards
it.
> 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] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
[ https://issues.apache.org/jira/browse/MSHARED-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757675#comment-16757675 ] Christian Cygnus commented on MSHARED-339: -- It appears this issue has been auto-closed, but it's still a big issue that I think should be addressed. MDEP-374 is closed, but as Herve Boutemy said in the comment chain, he would still be open to a Maven3 solution. I have some CS students that may wish to contribute towards this. Could we open this issue back up? > DependencyGraphBuilder does not provide verbose tree > > > Key: MSHARED-339 > URL: https://issues.apache.org/jira/browse/MSHARED-339 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.1 >Reporter: Paul Gier >Priority: Major > > The dependency graph builder provides a dependency tree which has already > filtered out duplicate dependencies. In some cases such as testing > dependency convergence or viewing the verbose dependency tree, it's useful to > get information about the full tree including duplicates. > The dependency graph builder should provide an option for including the > unfiltered dependency tree. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
[
https://issues.apache.org/jira/browse/MJAVADOC-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757652#comment-16757652
]
Gili edited comment on MJAVADOC-574 at 1/31/19 7:44 PM:
Related links:
[https://stackoverflow.com/a/38708383/14731|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
Conclusion: it looks like this expected (albeit sub-optimal) behavior.
The good news is that as of JDK 10 users can pass
{{--overridden-methods=summary}} to the Javadoc tool and such methods will get
pushed down below, to a "Methods declared in class X" section. Clicking on
method names will take the user to the Javadoc definition in the base class.
I think we can close this issue, unless you want to do the whole
JDK-on-the-sourcepath thing on behalf of users.
was (Author: cowwoc):
Related links:
[https://stackoverflow.com/a/38708383/14731|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
Conclusion: it looks like this expected (albeit sub-optimal) behavior.
The good news is that as of JDK 10 users can pass
{{--overridden-methods=summary}} to the Javadoc tool and such methods will get
moved down to the "Methods inherited from X" section where a Javadoc body is
not needed (method names link to the Javadoc comments in the base class).
I think we can close this issue, unless you want to do the whole
JDK-on-the-sourcepath thing on behalf of users.
> Unable to inherit Javadoc comments for overriden JDK methods
>
>
> Key: MJAVADOC-574
> URL: https://issues.apache.org/jira/browse/MJAVADOC-574
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: JDK 11.0.2
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
> any overriden methods end up with empty Javadoc (aside from a small
> "Overrides" section. According to
> [https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
> the inherited method must be on the {{-sourcepath}} but I'm not sure whether
> that's even possible for core JDK classes. I mean, am I supposed to download
> the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
[
https://issues.apache.org/jira/browse/MJAVADOC-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757652#comment-16757652
]
Gili edited comment on MJAVADOC-574 at 1/31/19 7:26 PM:
Related links:
[https://stackoverflow.com/a/38708383/14731|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
Conclusion: it looks like this expected (albeit sub-optimal) behavior.
The good news is that as of JDK 10 users can pass
{{--overridden-methods=summary}} to the Javadoc tool and such methods will get
moved down to the "Methods inherited from X" section where a Javadoc body is
not needed (method names link to the Javadoc comments in the base class).
I think we can close this issue, unless you want to do the whole
JDK-on-the-sourcepath thing on behalf of users.
was (Author: cowwoc):
Related links:
[https://stackoverflow.com/a/38708383/14731|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
Conclusion: it looks like this expected (albeit sub-optimal) behavior.
The good news is that as of JDK 10 users can pass
{{--overridden-methods=summary}} to the Javadoc tool and such methods will get
moved down to the "Methods inherited from X" section where a Javadoc body is
not needed (method names link to the Javadoc comments in the base class).
> Unable to inherit Javadoc comments for overriden JDK methods
>
>
> Key: MJAVADOC-574
> URL: https://issues.apache.org/jira/browse/MJAVADOC-574
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: JDK 11.0.2
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
> any overriden methods end up with empty Javadoc (aside from a small
> "Overrides" section. According to
> [https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
> the inherited method must be on the {{-sourcepath}} but I'm not sure whether
> that's even possible for core JDK classes. I mean, am I supposed to download
> the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
[
https://issues.apache.org/jira/browse/MJAVADOC-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757652#comment-16757652
]
Gili commented on MJAVADOC-574:
---
Related links:
[https://stackoverflow.com/a/38708383/14731|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8187386]
Conclusion: it looks like this expected (albeit sub-optimal) behavior.
The good news is that as of JDK 10 users can pass
{{--overridden-methods=summary}} to the Javadoc tool and such methods will get
moved down to the "Methods inherited from X" section where a Javadoc body is
not needed (method names link to the Javadoc comments in the base class).
> Unable to inherit Javadoc comments for overriden JDK methods
>
>
> Key: MJAVADOC-574
> URL: https://issues.apache.org/jira/browse/MJAVADOC-574
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: JDK 11.0.2
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
> any overriden methods end up with empty Javadoc (aside from a small
> "Overrides" section. According to
> [https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
> the inherited method must be on the {{-sourcepath}} but I'm not sure whether
> that's even possible for core JDK classes. I mean, am I supposed to download
> the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-568) javadoc:jar fails when project has Automatic-Module-Name and (implicit) uses offlinelinks with element-list
[
https://issues.apache.org/jira/browse/MJAVADOC-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757625#comment-16757625
]
Gili commented on MJAVADOC-568:
---
See
https://issues.apache.org/jira/browse/MJAVADOC-569?focusedCommentId=16757347=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16757347
for a discussion of what is missing from the implementation.
> javadoc:jar fails when project has Automatic-Module-Name and (implicit) uses
> offlinelinks with element-list
> ---
>
> Key: MJAVADOC-568
> URL: https://issues.apache.org/jira/browse/MJAVADOC-568
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> JDK 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # module2 will fail to build with: "javadoc: error - The code being
> documented uses packages in the unnamed module, but the packages defined in
> http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs/
> are in named modules."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (MJAVADOC-568) javadoc:jar fails when project has Automatic-Module-Name and (implicit) uses offlinelinks with element-list
[
https://issues.apache.org/jira/browse/MJAVADOC-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MJAVADOC-568:
-
Implementation is incomplete, so reopening
> javadoc:jar fails when project has Automatic-Module-Name and (implicit) uses
> offlinelinks with element-list
> ---
>
> Key: MJAVADOC-568
> URL: https://issues.apache.org/jira/browse/MJAVADOC-568
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> JDK 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Attachments: testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # module2 will fail to build with: "javadoc: error - The code being
> documented uses packages in the unnamed module, but the packages defined in
> http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs/
> are in named modules."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757619#comment-16757619
]
Robert Scholte commented on MJAVADOC-569:
-
It is unrelated to the description of this issue (javadoc:aggregate fails with
'error: package org.w3c.dom is not visible' when mixing Java modules and
non-modules). Reopening MJAVADOC-568 makes more sense.
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCHECKSTYLE-367) Regexp module fails when "id" property without a "." is provided
Robert Bain created MCHECKSTYLE-367:
---
Summary: Regexp module fails when "id" property without a "." is
provided
Key: MCHECKSTYLE-367
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-367
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Affects Versions: 3.0.0
Reporter: Robert Bain
Using an "id" property without a "." as follows, the following stack trace is
produced:
{code:java}
{code}
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 6
at java.lang.String.checkBoundsBeginEnd (String.java:3116)
at java.lang.String.substring (String.java:1885)
at org.apache.maven.plugins.checkstyle.RuleUtil.getCategory (RuleUtil.java:95)
It's pretty clear from [the
code|https://github.com/apache/maven-plugins/blob/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugins/checkstyle/RuleUtil.java#L95]
what's causing the issue.
Adding a "." to the "id" property resolves things, as follows:
{code:java}
{code}
We now get the message [WARNING] Example.java:[12] (extension) foo: Line
matches the illegal pattern 'Use NuDateService'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757610#comment-16757610
]
Gili commented on MJAVADOC-569:
---
Do you plan to reopen this issue or should I file a new bug report with the
aforementioned testcase (for adding a patch-mechanism for this case)?
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757593#comment-16757593
]
Robert Scholte commented on MJAVADOC-569:
-
Having a closer look at it, I think you are right: we probably need the
patch-mechanism here as well.
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-229) release:rollback is missing remove tag implementation
[ https://issues.apache.org/jira/browse/MRELEASE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757578#comment-16757578 ] Clemens Quoß commented on MRELEASE-229: --- Regarding svn: from what I have seen so far, maven scm remove only works locally, correct? So what you would have to do is checkout a clean copy into the working dir and then remove, right? We actually need this kind of functionality at our company, so yes, I could give it a try. But I don't know how to create a PR properly. Any help there would be appreciated. > release:rollback is missing remove tag implementation > - > > Key: MRELEASE-229 > URL: https://issues.apache.org/jira/browse/MRELEASE-229 > Project: Maven Release Plugin > Issue Type: Bug > Components: rollback >Affects Versions: 2.0-beta-5 >Reporter: Mark Hobson >Priority: Major > > The remove-scm-tag phase of release:rollback is currently unimplemented - see > the TODO in RemoveScmTagPhase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757577#comment-16757577
]
Robert Scholte commented on MJAVADOC-569:
-
I missed those questions, but here are my thoughts:
- I don't understand why the export to the unnamed module is required. If both
module1 and module2 are available on the modulepath I would expect them to see
each other. So we need to finetune that.
- The plugin has the info to calculate if the {{export to}} is relevant. But if
module2 has a dependency on module1, then it makes sense to add it to the
modulepath, otherwise (if it had a module descriptor) it wouldn;t even compile.
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6583.
---
Resolution: Duplicate
Assignee: Robert Scholte
> Relative path for parent pom on Windows fails depending on case of drive
> letter
> ---
>
> Key: MNG-6583
> URL: https://issues.apache.org/jira/browse/MNG-6583
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> Environment: Windows 7 Enterprise
>Reporter: J.Cranendonk
>Assignee: Robert Scholte
>Priority: Major
> Attachments: RelativelyInsane.7z
>
>
> Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
> 3.6.0)
> This issue does not appear in Maven 3.3.9 or older.
> Works: 3.3.3, 3.3.9
> Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> It seems to be related to whether the cmd current path either starts with a
> upper case (works) or lower case (doesn't work) driver letter.
> With an upper case drive letter, relative paths to the parent pom resolve
> correctly.
> With a lower case driver letter, relative paths to the parent pom do not
> resolve correctly.
> For example, this cmd works:
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+C+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> And this cmd fails, the only difference is the drive letter in the second
> 'cd'.
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+c+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> I have attached a full minimal example in [^RelativelyInsane.7z]
> Extract it to C:\Temp, change the paths to your maven install, and run the
> cmd's
>
> Log of failed run:
> {{[INFO] Scanning for projects...}}
> {{[ERROR] [ERROR] Some problems were encountered while processing the POMs:}}
> {{[FATAL] Non-resolvable parent POM for reltest.mine:ArtiA:[unknown-version]:
> Could not find artifact reltest.mine:parenty:pom:0.0.1-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 4, column 13 @}}
> {{[ERROR] The build could not read 1 project -> [Help 1]}}
> {{[ERROR]}}
> {{[ERROR] The project reltest.mine:ArtiA:[unknown-version]
> (C:\Temp\RelativelyInsane\ArtiA\pom.xml) has 1 error}}
> {{[ERROR] Non-resolvable parent POM for
> reltest.mine:ArtiA:[unknown-version]: Could not find artifact
> reltest.mine:parenty:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
> wrong local POM @ line 4, column 13 -> [Help 2]}}
> {{[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/ProjectBuildingException}}
> {{[ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException}}
> {{Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
> 2018-10-24T20:41:47+02:00)}}
> {{Maven home: C:\Portable\Tools\apache-maven-3.6.0\bin\..}}
> {{Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: C:\Program
> Files (x86)\Java\jdk1.8.0_192\jre}}
> {{Default locale: en_US, platform encoding: Cp1252}}
> {{OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"}}
> {{Press any key to continue . . .}}
>
> Log of succesfull run:
> {{[INFO] Scanning for projects...}}
> {{[INFO]
> }}
> {{[INFO] Reactor Build Order:}}
> {{[INFO]}}
> {{[INFO] parenty
> [pom]}}
> {{[INFO] ArtiA
> [pom]}}
> {{[INFO] rooty
> [pom]}}
> {{[INFO]}}
> {{[INFO] < reltest.mine:parenty
> >}}
> {{[INFO] Building parenty 0.0.1-SNAPSHOT
> [1/3]}}
> {{[INFO] [ pom
> ]-}}
> {{[INFO]}}
> {{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ parenty ---}}
> {{[INFO]}}
> {{[INFO] -< reltest.mine:ArtiA
> >-}}
> {{[INFO] Building ArtiA 0.0.1-SNAPSHOT
> [2/3]}}
> {{[INFO] [ pom
> ]-}}
> {{[INFO]}}
>
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks deploys when alt*DeploymentRepository properties are used
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757500#comment-16757500 ] Nick Cross commented on MDEPLOY-244: [~khmarbaise] With this issue (and potentially MDEPLOY-246 , MDEPLOY-247 which might be related ) will the final release of the maven-deploy-plugin for 3.0.0 include backwards compatibility ? When might the final release happen ? > maven deploy plugin 3.0.0-M1 breaks deploys when alt*DeploymentRepository > properties are used > - > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Assignee: Karl Heinz Marbaise >Priority: Critical > Attachments: project-pom.xml, root-pom.xml, test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757468#comment-16757468 ] Aaron Digulla commented on SUREFIRE-1631: - *sigh* This is really driving me insane. Now, I can't repeat it myself... it failed only once (see stack trace above). So my current statistics with the attached test case: 1 failure in 21 builds... > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
Gili created MJAVADOC-574:
-
Summary: Unable to inherit Javadoc comments for overriden JDK
methods
Key: MJAVADOC-574
URL: https://issues.apache.org/jira/browse/MJAVADOC-574
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.1.0
Reporter: Gili
Attachments: testcase.zip
If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
any overriden methods end up with empty Javadoc (aside from a small "Overrides"
section. According to
[https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
the inherited method must be on the {{-sourcepath}} but I'm not sure whether
that's even possible for core JDK classes. I mean, am I supposed to download
the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-574) Unable to inherit Javadoc comments for overriden JDK methods
[
https://issues.apache.org/jira/browse/MJAVADOC-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-574:
--
Environment: JDK 11.0.2
> Unable to inherit Javadoc comments for overriden JDK methods
>
>
> Key: MJAVADOC-574
> URL: https://issues.apache.org/jira/browse/MJAVADOC-574
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
> Environment: JDK 11.0.2
>Reporter: Gili
>Priority: Major
> Attachments: testcase.zip
>
>
> If you run {{mvn javadoc:jar}} on the attached testcase you will notice that
> any overriden methods end up with empty Javadoc (aside from a small
> "Overrides" section. According to
> [https://manpages.debian.org/testing/openjdk-11-jdk-headless/javadoc.1.en.html#METHOD%C2%A0COMMENT%C2%A0INHERITANCE]
> the inherited method must be on the {{-sourcepath}} but I'm not sure whether
> that's even possible for core JDK classes. I mean, am I supposed to download
> the JDK source-code and link to it somehow?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757347#comment-16757347
]
Gili edited comment on MJAVADOC-569 at 1/31/19 3:18 PM:
Wow. That is not intuitive but makes a lot of sense. Thank you for pointing
this out! :)
There are still 2 outstanding questions in this comment which you haven't
answered:
https://issues.apache.org/jira/browse/MJAVADOC-569?focusedCommentId=16753250=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16753250
Any ideas?
Once that's done I will consider this issue closed. Thanks.
was (Author: cowwoc):
Wow. That is not intuitive but makes a lot of sense. Thank you for pointing
this out! :)
There are still 2 outstanding questions in this comment you haven't answered:
https://issues.apache.org/jira/browse/MJAVADOC-569?focusedCommentId=16753250=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16753250
Any ideas?
Once that's done I will consider this issue closed. Thanks.
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757347#comment-16757347
]
Gili commented on MJAVADOC-569:
---
Wow. That is not intuitive but makes a lot of sense. Thank you for pointing
this out! :)
There are still 2 outstanding questions in this comment you haven't answered:
https://issues.apache.org/jira/browse/MJAVADOC-569?focusedCommentId=16753250=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16753250
Any ideas?
Once that's done I will consider this issue closed. Thanks.
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MJAVADOC-569) javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when mixing Java modules and non-modules
[
https://issues.apache.org/jira/browse/MJAVADOC-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753250#comment-16753250
]
Gili edited comment on MJAVADOC-569 at 1/31/19 3:16 PM:
I got it working (export-to-testcase.zip) but I think it's worth having a
follow-up discussion about how (and why) this works:
* If the root project inherits from org.sonatype.oss:oss-parent:9 then the
plugin logs this extra step "[DEBUG] Added Javadoc offline link:
[http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs]
for the module: testcase:module1:jar:1.0-SNAPSHOT"
* This causes the plugin to add "--add-modules module1" to the "options" file.
* This leads to us getting a new error message: "package module1 is declared
in module module1, which does not export it to the unnamed module".
* To fix this, I had to add:
{code:java}
--add-exports
module1/module1=ALL-UNNAMED
{code}
to module2's plugin configuration.
I want to update the FAQ with more examples so I need your help in understand
what is going on. Open questions:
* Why aren't we always adding "--add-modules module1"? I think we should
respect "export...to" in the presence of at least one module, even if no
offline links are present. Is this a bug?
* Are the above options the correct way to solve this problem? Meaning, are we
forced to export the package into the unnamed module space? Couldn't we use
"--patch-module" to convert module2 into a named module and in so doing (1)
avoid having the user needing to declare (2) avoid
exposing a package to modules that should not see it?
was (Author: cowwoc):
I got it working (export-to-testcase.zip) but I think it's worth having a
follow-up discussion about how (and why) this works:
* If the root project inherits from org.sonatype.oss:oss-parent:9 then the
plugin logs this extra step "[DEBUG] Added Javadoc offline link:
http://nexus.sonatype.org/oss-repository-hosting.html/root/module1/apidocs for
the module: testcase:module1:jar:1.0-SNAPSHOT"
* This causes the plugin to add "--add-modules module1" to the "options" file.
* This leads to us getting a new error message: "package module1 is declared
in module module1, which does not export it to the unnamed module".
* To fix this, I had to add:
{code:java}
--add-exports
module1/module1=ALL-UNNAMED
{code}
to module2's plugin configuration.
I want to update the FAQ with more examples so I need your help in understand
what is going on. Open questions:
* Why aren't we always adding "--add-modules module1"? I think we should
respect "export...to" in the presence of at least one module, even if no
offline links are present. Is this a bug?
* Are the above options the correct way to solve this problem? Meaning, are we
forced to export the package into the unnamed module space? Couldn't we use
"--patch-module" to convert module2 into a named module and in so doing (1)
avoid having the user needing to declare (2) avoid
exposing a package to modules that should not see it?
> javadoc:aggregate fails with 'error: package org.w3c.dom is not visible' when
> mixing Java modules and non-modules
> -
>
> Key: MJAVADOC-569
> URL: https://issues.apache.org/jira/browse/MJAVADOC-569
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Environment: maven-javadoc-plugin 3.1.0-SNAPSHOT
> Java 12-ea+28
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: export-to-testcase.zip, testcase.zip
>
>
> # Unpack testcase
> # Run {{mvn clean package javadoc:aggregate -e}}
> # {{javadoc:aggregate}} will fail with various errors like "(package
> org.w3c.dom is declared in module java.xml, but module module2 does not read
> it)"
> Note that module 2 isn't really a Java Module but we are treating it as such
> for the purposes of aggregating Javadoc across modularized and
> non-modularized code. Module 2 has no way of declaring its intention of
> reading the aforementioned package because it does not have a
> {{module-info.java}} file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] zregvart commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies
zregvart commented on issue #5: [MCHECKSTYLE-353] - Don't resolve any dependencies URL: https://github.com/apache/maven-checkstyle-plugin/pull/5#issuecomment-459336435 @eolivelli I added two commits to this PR with integration tests for [MCHECKSTYLE-163](https://issues.apache.org/jira/browse/MCHECKSTYLE-163) and [MCHECKSTYLE-54](https://issues.apache.org/jira/browse/MCHECKSTYLE-54). For MCHECKSTYLE-163 I used `IllegalThrows` as `RedundantThrows` was removed from checkstyle. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
J.Cranendonk created MNG-6583: - Summary: Relative path for parent pom on Windows fails depending on case of drive letter Key: MNG-6583 URL: https://issues.apache.org/jira/browse/MNG-6583 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.6.0, 3.5.4, 3.5.3, 3.5.2, 3.5.0 Environment: Windows 7 Enterprise Reporter: J.Cranendonk Hi! I've found an odd issue with Maven 3.5.0 and higher (including current: 3.6.0) This issue does not appear in Maven 3.3.9 or older. Works: 3.3.3, 3.3.9 Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 It seems to be related to whether the cmd current path either starts with a upper case (works) or lower case (doesn't work) driver letter. With an upper case drive letter, relative paths to the parent pom resolve correctly. With a lower case driver letter, relative paths to the parent pom do not resolve correctly. (I will add a sample after creating the issue) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757106#comment-16757106
]
Aaron Digulla commented on SUREFIRE-1631:
-
Updates. I've made some changes to the logger configuration (I'm using slf4j
with logback) and then built the system 10 times.
The first change was adding color to the log by changing the pattern
{code}
{code}
to
{code}
{code}
Now the build fails 10 out of 11 times (the first build succeeded ...).
Then, I've disabled AMQ logging. This avoids log output in a shutdown hook.
{code}
{code}
Now 6 out of 10 builds fail.
If I also disable {{org.springframework.core.env}} (which creates a few 80KB
lines of log), then only 2 out of 20 builds fail.
Weird fact: The first two of 20 builds failed. It's as if the problem "heals"
itself.
It seems the amount of logging has an effect on the bug but I can't see why. In
the code of Surefire, you're using {{readLine()}} in
{{org.apache.maven.shared.utils.cli.StreamPumper.run()}} to read the test
output which has no length limitation. Non-printables are escaped in
{{ForkingRunListener.writeTestOutput()}}. It seems that the length of the line
shouldn't have an effect but it does.
So I wrote a small test project which just writes a 100K log and ... it crashes
for me with:
{code}
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96420
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96421
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96422
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 04:23 min
[INFO] Finished at: 2019-01-31T11:02:22+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M2:test (default-test) on
project surefire-shutdownhook-bug: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\dev\workspace\surefire-shutdownhook-bug\target\surefire-reports for the
individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was cmd.exe /X /C "C:\tools\java\jdk1.8.0_191\jre\bin\java -jar
C:\tools\cygwin\tmp\surefire2097056449345541265\surefirebooter7815058800200549210.jar
C:\tools\cygwin\tmp\surefire2097056449345541265
2019-01-31T10-58-05_362-jvmRun1 surefire7801676233715227954tmp
surefire_06053953062955035510tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR]
org.apache.maven.surefire.bugs.shutdownhook.SomethingWhichInstallShutdownHookTest
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
forked VM terminated without properly saying goodbye. VM crash or System.exit
called?
[ERROR] Command was cmd.exe /X /C "C:\tools\java\jdk1.8.0_191\jre\bin\java -jar
C:\tools\cygwin\tmp\surefire2097056449345541265\surefirebooter7815058800200549210.jar
C:\tools\cygwin\tmp\surefire2097056449345541265
2019-01-31T10-58-05_362-jvmRun1 surefire7801676233715227954tmp
surefire_06053953062955035510tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR]
org.apache.maven.surefire.bugs.shutdownhook.SomethingWhichInstallShutdownHookTest
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:670)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
I have attached a full minimal example in [^RelativelyInsane.7z]
Extract it to C:\Temp, change the paths to your maven install, and run the cmd's
Log of failed run:
{{[INFO] Scanning for projects...}}
{{[ERROR] [ERROR] Some problems were encountered while processing the POMs:}}
{{[FATAL] Non-resolvable parent POM for reltest.mine:ArtiA:[unknown-version]:
Could not find artifact reltest.mine:parenty:pom:0.0.1-SNAPSHOT and
'parent.relativePath' points at wrong local POM @ line 4, column 13 @}}
{{[ERROR] The build could not read 1 project -> [Help 1]}}
{{[ERROR]}}
{{[ERROR] The project reltest.mine:ArtiA:[unknown-version]
(C:\Temp\RelativelyInsane\ArtiA\pom.xml) has 1 error}}
{{[ERROR] Non-resolvable parent POM for
reltest.mine:ArtiA:[unknown-version]: Could not find artifact
reltest.mine:parenty:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
wrong local POM @ line 4, column 13 -> [Help 2]}}
{{[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/ProjectBuildingException}}
{{[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException}}
{{Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T20:41:47+02:00)}}
{{Maven home: C:\Portable\Tools\apache-maven-3.6.0\bin\..}}
{{Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: C:\Program
Files (x86)\Java\jdk1.8.0_192\jre}}
{{Default locale: en_US, platform encoding: Cp1252}}
{{OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"}}
{{Press any key to continue . . .}}
Log of succesfull run:
{{[INFO] Scanning for projects...}}
{{[INFO]
}}
{{[INFO] Reactor Build Order:}}
{{[INFO]}}
{{[INFO] parenty
[pom]}}
{{[INFO] ArtiA
[pom]}}
{{[INFO] rooty
[pom]}}
{{[INFO]}}
{{[INFO] < reltest.mine:parenty
>}}
{{[INFO] Building parenty 0.0.1-SNAPSHOT
[1/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ parenty ---}}
{{[INFO]}}
{{[INFO] -< reltest.mine:ArtiA
>-}}
{{[INFO] Building ArtiA 0.0.1-SNAPSHOT
[2/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ArtiA ---}}
{{[INFO]}}
{{[INFO] -< reltest.mine:rooty
>-}}
{{[INFO] Building rooty 0.0.1-SNAPSHOT
[3/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ rooty ---}}
{{[INFO]
}}
{{[INFO] Reactor Summary for rooty 0.0.1-SNAPSHOT:}}
{{[INFO]}}
{{[INFO] parenty SUCCESS [ 0.141
s]}}
{{[INFO] ArtiA .. SUCCESS [ 0.011
s]}}
{{[INFO] rooty .. SUCCESS [ 0.009
[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757109#comment-16757109
]
Aaron Digulla edited comment on SUREFIRE-1631 at 1/31/19 10:29 AM:
---
I've attached a project which demonstrates the bug. Just compile it with
{code}mvn clean install{code}
Can someone please confirm this bug?
was (Author: digulla):
I've attached the test case. Can someone please confirm this bug?
> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2
>Reporter: Aaron Digulla
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?" messages when running unit tests in
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
> * Reboot / Cold boot (happens first thing on Monday morning when I come into
> the office and turn on my PC).
> * More free memory (happens when I only have a single window open). I have
> 16GB of RAM.
> * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
> * Different versions of the Surefire plugin or Maven
> * Different JDK 8 builds
> Things that affect the bug:
> * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
> * Redirecting all log output to a file using logback-test.xml
> * Running Surefire with forkCount=0
> * Running a subset of the tests (-Dtest=...)
> * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker
> and uses a shutdown hook to stop it. So I created a small test project which
> demonstrates that Surefire will sometimes cut off stdout. I think that
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between
> the surefire child VM and main Maven process. ActiveMQ might be worse since
> it stops threads and execution pools (so the output comes slowly with a
> couple of exceptions sprinkled in when one component loses connection because
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies)
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster
> than printing on a terminal. The strange part is that the log file is about
> the same size but 30% of the tests haven't run. Most tests log a lot, do I
> would expect to see a difference of at least a few MB. The Maven part (which
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the
> communication between parent and child would help. Also the parent should
> terminate the child and then read stdout until EOF to we can see anything
> that happens afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
I have attached a full minimal example in [^RelativelyInsane.7z]
Extract it to C:\Temp, change the paths to your maven install, and run the cmd's
was:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
> Relative path for parent pom on Windows fails depending on case of drive
> letter
> ---
>
> Key: MNG-6583
> URL: https://issues.apache.org/jira/browse/MNG-6583
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> Environment: Windows 7 Enterprise
>Reporter: J.Cranendonk
>Priority: Major
> Attachments: RelativelyInsane.7z
>
>
> Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
> 3.6.0)
> This issue does not appear in Maven 3.3.9 or older.
> Works: 3.3.3, 3.3.9
> Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> It seems to be related to whether the cmd current path either starts with a
> upper case (works) or lower case (doesn't work) driver letter.
> With an upper case drive letter, relative paths to the parent pom resolve
> correctly.
> With a lower case driver letter, relative paths to the parent pom do not
> resolve correctly.
> For example, this cmd works:
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+C+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> And this cmd fails, the only difference is the drive letter in the second
> 'cd'.
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+c+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> I have attached a full minimal example in [^RelativelyInsane.7z]
> Extract it to C:\Temp, change the paths to your maven install, and run the
> cmd's
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[ https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.Cranendonk updated MNG-6583: -- Attachment: RelativelyInsane.7z > Relative path for parent pom on Windows fails depending on case of drive > letter > --- > > Key: MNG-6583 > URL: https://issues.apache.org/jira/browse/MNG-6583 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 > Environment: Windows 7 Enterprise >Reporter: J.Cranendonk >Priority: Major > Attachments: RelativelyInsane.7z > > > Hi! I've found an odd issue with Maven 3.5.0 and higher (including current: > 3.6.0) > This issue does not appear in Maven 3.3.9 or older. > Works: 3.3.3, 3.3.9 > Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 > It seems to be related to whether the cmd current path either starts with a > upper case (works) or lower case (doesn't work) driver letter. > With an upper case drive letter, relative paths to the parent pom resolve > correctly. > With a lower case driver letter, relative paths to the parent pom do not > resolve correctly. > (I will add a sample after creating the issue) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
was:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
(I will add a sample after creating the issue)
> Relative path for parent pom on Windows fails depending on case of drive
> letter
> ---
>
> Key: MNG-6583
> URL: https://issues.apache.org/jira/browse/MNG-6583
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> Environment: Windows 7 Enterprise
>Reporter: J.Cranendonk
>Priority: Major
> Attachments: RelativelyInsane.7z
>
>
> Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
> 3.6.0)
> This issue does not appear in Maven 3.3.9 or older.
> Works: 3.3.3, 3.3.9
> Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> It seems to be related to whether the cmd current path either starts with a
> upper case (works) or lower case (doesn't work) driver letter.
> With an upper case drive letter, relative paths to the parent pom resolve
> correctly.
> With a lower case driver letter, relative paths to the parent pom do not
> resolve correctly.
> For example, this cmd works:
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+C+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> And this cmd fails, the only difference is the drive letter in the second
> 'cd'.
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+c+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757109#comment-16757109 ] Aaron Digulla commented on SUREFIRE-1631: - I've attached the test case. Can someone please confirm this bug? > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated SUREFIRE-1631: Attachment: shurefire-shutdownhook-bug-0.0.1.zip > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
