[GitHub] Tibor17 opened a new pull request #183: junit5

[GitBox]

Tibor17 opened a new pull request #183: junit5
URL: https://github.com/apache/maven-surefire/pull/183
 
 
   JUnit 5 Provider with tests


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] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing

[Thorsten Glaser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437765#comment-16437765
 ] 

Thorsten Glaser commented on MJAVADOC-523:
--

Actually, I have *two* cases in which this occurs; one is a JAR without Java™ 
code, the other even has…

{{    pom}}

…so I cannot even use the workaround to add one dummy class into it.

> Exclude non-Java JARs from Maven Javadoc plugin processing
> --
>
> Key: MJAVADOC-523
> URL: https://issues.apache.org/jira/browse/MJAVADOC-523
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 2.8
>Reporter: Thorsten Glaser
>Priority: Minor
>
> I have a multi-module project which builds a couple of JARs and then 
> distributed them into two WARs.
> However, one of the JARs does not contain any Java code at all, merely 
> (maven-filtered) resources. This leads to warnings during the build like 
> these:
> {{[…]
> [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc' 
> has not been previously called for the module: 
> 'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...
> [WARNING] Creating fake javadoc directory to prevent repeated invocations: 
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
> [ERROR] Error fetching link: 
> /var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
>  Ignored it.
> [INFO] 
> Loading source files for package de.tarent.foo.rest.transformation...
> […]}}
> I found how I can exclude javadoc stuff by package, but not by artifact.
> The plugin is currently included ONLY in the parent POM, like this:
> {{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
> While it _is_ run during “compilation” of the resources-only JAR, it 
> (obviously) produces no result, thus the warning (as it’s not excluded 
> either).
> How can I either make it produce something (i.e. the ability to create a 
> valid-looking yet contentless FOO-javadoc.jar that satisfies references by 
> reverse dependencies, in a JAR not containing any Java™ code) or, probably 
> preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc 
> on modules depending on it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MJAVADOC-523) Exclude non-Java JARs from Maven Javadoc plugin processing

[Thorsten Glaser (JIRA)]

Thorsten Glaser created MJAVADOC-523:


 Summary: Exclude non-Java JARs from Maven Javadoc plugin processing
 Key: MJAVADOC-523
 URL: https://issues.apache.org/jira/browse/MJAVADOC-523
 Project: Maven Javadoc Plugin
  Issue Type: Bug
  Components: javadoc
Affects Versions: 2.8
Reporter: Thorsten Glaser


I have a multi-module project which builds a couple of JARs and then 
distributed them into two WARs.

However, one of the JARs does not contain any Java code at all, merely 
(maven-filtered) resources. This leads to warnings during the build like these:
{{[…]
[INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @ foo-services ---
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.8:javadoc' has 
not been previously called for the module: 
'de.tarent.foo:foo-rsrcs:jar:1.3.900-SNAPSHOT'. Trying to invoke it...

[WARNING] Creating fake javadoc directory to prevent repeated invocations: 
/var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs
[ERROR] Error fetching link: 
/var/lib/jenkins/jobs/FooTool/workspace/foo-backend/foo-rsrcs/target/apidocs/package-list.
 Ignored it.

[INFO] 
Loading source files for package de.tarent.foo.rest.transformation...
[…]}}
I found how I can exclude javadoc stuff by package, but not by artifact.

The plugin is currently included ONLY in the parent POM, like this:
{{org.apache.maven.pluginsmaven-javadoc-plugin2.8attach-javadocsjar}}
While it _is_ run during “compilation” of the resources-only JAR, it 
(obviously) produces no result, thus the warning (as it’s not excluded either).

How can I either make it produce something (i.e. the ability to create a 
valid-looking yet contentless FOO-javadoc.jar that satisfies references by 
reverse dependencies, in a JAR not containing any Java™ code) or, probably 
preferably, exclude the {{foo-rsrcs}} module from being accessed by mjavadoc on 
modules depending on it?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437710#comment-16437710
 ] 

Hudson commented on MNG-6391:
-

Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #4

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/4/

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MEJB-121) Add documentation information for GitHub

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MEJB-121:


 Summary: Add documentation information for GitHub
 Key: MEJB-121
 URL: https://issues.apache.org/jira/browse/MEJB-121
 Project: Maven EJB Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.1
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.1






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MEJB-120) Upgrade mave-surefire/failsafe-plugin 2.21.0

[Karl Heinz Marbaise (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MEJB-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl Heinz Marbaise closed MEJB-120.

Resolution: Done

Done in 
[6705eaf2a74b07720701aaa7c244d87cf9dc7d18|https://gitbox.apache.org/repos/asf?p=maven-ejb-plugin.git;a=commitdiff;h=6705eaf2a74b07720701aaa7c244d87cf9dc7d18]

> Upgrade mave-surefire/failsafe-plugin 2.21.0
> 
>
> Key: MEJB-120
> URL: https://issues.apache.org/jira/browse/MEJB-120
> Project: Maven EJB Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MEJB-120) Upgrade mave-surefire/failsafe-plugin 2.21.0

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MEJB-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437591#comment-16437591
 ] 

Hudson commented on MEJB-120:
-

Build succeeded in Jenkins: Maven TLP » maven-ejb-plugin » master #5

See https://builds.apache.org/job/maven-box/job/maven-ejb-plugin/job/master/5/

> Upgrade mave-surefire/failsafe-plugin 2.21.0
> 
>
> Key: MEJB-120
> URL: https://issues.apache.org/jira/browse/MEJB-120
> Project: Maven EJB Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6394) ${revision} and parent.releativePath

[Karl Heinz Marbaise (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437494#comment-16437494
 ] 

Karl Heinz Marbaise commented on MNG-6394:
--

Have you correctly configured flatten-maven-plugin in your pom's...as describe 
in the http://maven.apache.org/maven-ci-friendly.html documentation? 

> ${revision} and parent.releativePath
> 
>
> Key: MNG-6394
> URL: https://issues.apache.org/jira/browse/MNG-6394
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
>Reporter: Dorian Vallant
>Priority: Major
>
> If the CI friendly ${revision} property is used it seems maven does not 
> simple replace the property with the given value.
> Consider the following example:
> parent-project/
>      pom.xml
>  child-project/
>      pom.xml
> parent-project/pom.xml:
> ...
>     my.group
>     parentArtifact
>     ${revision}
>     pom
> ...
> child-project/pom.xml:
>   
> my.group
> parentArtifact
> ${revision}
> ../parent-project
>   
> If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
> child-project/pom.xml clean install' all works fine as long as the parent 
> project is present in the file system. But if you move the parent project to 
> another place, build & install it to your local repository and then try to 
> build the child project, maven tries to download the pom.xml of the parent 
> project but does not replace ${revision}. So maven complains about a missing 
> dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MASSEMBLY-883) Transitive dependencies with scope provided are included with jar-with-dependencies descriptor

[Francois Armand (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437486#comment-16437486
 ] 

Francois Armand commented on MASSEMBLY-883:
---

I added a minimal reproduction project here: 
https://github.com/fanf/test-maven-assembly/blob/master/readme.md

> Transitive dependencies with scope provided are included with 
> jar-with-dependencies descriptor
> --
>
> Key: MASSEMBLY-883
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-883
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: predefined descriptors
>Affects Versions: 3.1.0
>Reporter: Francois Armand
>Priority: Major
>
> In the following case as shown by {{mvn dependency:tree}}, with the 
> predifined descriptor {{jar-with-dependencies}}:
>  
> {{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile}}
> {{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile}}
> {{[INFO] | | - net.minidev:accessors-smart:jar:1.1:compile}}
> {{[INFO] | - org.slf4j:slf4j-api:jar:1.7.16:provided}}
>   
> {{json-path}}, {{json-smart}}, {{accessors-smart}} are included, as expected. 
> {{But slf4j-api}} is also included in the resulting jar.
> Other direct dependencies with scope `provided` are correctly excluded from 
> the final jar.
> If this is the intendented behavior, which is highly surprising, could you 
> document it in the corresponding descriptor documentation 
> ([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
>  Could you also explain what descriptor would allow to achieve the desired 
> behavior (or point to a resource explaining it, I wasn't able to find one).
> Thanks.
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPIR-366) Drop Maven 2 support

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437458#comment-16437458
 ] 

Hudson commented on MPIR-366:
-

Build failed in Jenkins: Maven TLP » maven-project-info-reports-plugin » 
MPIR-366 #18

See 
https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-366/18/

> Drop Maven 2 support
> 
>
> Key: MPIR-366
> URL: https://issues.apache.org/jira/browse/MPIR-366
> Project: Maven Project Info Reports Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPIR-366) Drop Maven 2 support

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437437#comment-16437437
 ] 

Hudson commented on MPIR-366:
-

Build failed in Jenkins: Maven TLP » maven-project-info-reports-plugin » 
MPIR-366 #17

See 
https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-366/17/

> Drop Maven 2 support
> 
>
> Key: MPIR-366
> URL: https://issues.apache.org/jira/browse/MPIR-366
> Project: Maven Project Info Reports Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1502) Forking fails on OS/X

[Paul Hammant (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437375#comment-16437375
 ] 

Paul Hammant commented on SUREFIRE-1502:


Can we disambiguate what "OS/X 10" is please.

These are the correct verion names/numbers for macOS (as it is known as today):

 
|[OS X 10.8|https://simple.wikipedia.org/wiki/OS_X_Mountain_Lion]|Mountain 
Lion|February 16, 
2012^[[17]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-16-02-17]^|July 
25, 
2012^[[18]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-25-07-18]^|10.8.5
 (12F45) (October 3, 2013)|
|[OS X 10.9|https://simple.wikipedia.org/wiki/OS_X_Mavericks]|Mavericks|June 
10, 
2013^[[19]|https://simple.wikipedia.org/wiki/MacOS#cite_note-PR-10-06-19]^|October
 22, 2013|10.9.5 (13F1112) (September 18, 2014)|
|[OS X 10.10|https://simple.wikipedia.org/wiki/OS_X_Yosemite]|Yosemite|June 2, 
2014|October 16, 2014|10.10.5 (14F27) (August 13, 2015)|
|[OS X 10.11|https://simple.wikipedia.org/wiki/OS_X_El_Capitan]|El Capitan|June 
8, 2015|September 30, 2015|10.11.6 (15G1510) (May 15, 2017)|
|[macOS 
10.12|https://simple.wikipedia.org/w/index.php?title=MacOS_10.12=edit=1]|Sierra|June
 13, 2016|September 20, 2016|10.12.6 (16G1212) (Jul 19, 2017)|
|macOS 10.13|High Sierra|June 5, 2017|September 25, 2017|10.13.4 (17E150g) 
(March 29, 2018)|

> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp, 
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_ 
> on version 2.21.0 as well as 2.20.1.  It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon 
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
>  ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider 
> (AbstractSurefireMojo.java:1148)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
>  (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute 
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> 

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437278#comment-16437278
 ] 

Robert Scholte commented on MCOMPILER-337:
--

Yes, both classpath and modulepath are use, but none of the jars are on both!
{noformat}
[DEBUG] Classpath:
[DEBUG]  E:\java-workspace\sandbox\quebec.lachine\target\classes
[DEBUG]  
d:\maven_repo\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
[DEBUG]  
d:\maven_repo\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
[DEBUG] Modulepath:
[DEBUG]  
d:\maven_repo\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
[DEBUG]  
d:\maven_repo\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
[DEBUG]  
d:\maven_repo\.m2\repository\org\apache\commons\commons-lang3\3.7\commons-lang3-3.7.jar
{noformat}

bq. the Java documentation says that the jar dependencies should be in the 
module-path ONLY, not both

Show me, you must have interpreted it incorrectly.

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Assignee: Robert Scholte
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS 

[jira] [Closed] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MCOMPILER-337.

Resolution: Not A Problem
  Assignee: Robert Scholte

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Assignee: Robert Scholte
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> {noformat}
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
>  [DEBUG] Modulepath: <- All jar file dependencies should be under this 
> ModulePath list ***
>  [DEBUG] 

[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437227#comment-16437227
 ] 

Tibor Digana commented on SUREFIRE-1383:


I will have a look in the weekend. Now I can't, I am in the office.

On Fri, Apr 13, 2018 at 1:37 PM, ASF GitHub Bot (JIRA) 



> dependenciesToScan Does Not Leverage Classpath Elements 
> 
>
> Key: SUREFIRE-1383
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1383
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Owen Farrell
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.1
>
> Attachments: scanned-dependencies-sample.zip
>
>  Time Spent: 48h
>  Remaining Estimate: 24h
>
> The  configuration attribute relies solely on installed 
> artifacts. This is an issue when the targeted dependencies were built as part 
> of the current session. The net result is that stale artifacts are used (i.e. 
> if the dependency has changed since it was last installed) or the tests are 
> not executed at all (if the dependency has not been previously installed.
> Attached is a sample project that illustrates this issue:
> Given I have a multi-module project
>And the first module built includes test classes as part of the project 
> artifact
>And subsequent modules scan the first for unit tests to execute
> When I execute the _*test*_ goal (prior to any install)
> Then the build should succeed
>And tests should be executed with each module



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437212#comment-16437212
 ] 

ASF GitHub Bot commented on SUREFIRE-1383:
--

paulduffin commented on issue #157: SUREFIRE-1383 dependenciesToScan Does Not 
Leverage Classpath Elements
URL: https://github.com/apache/maven-surefire/pull/157#issuecomment-381108795
 
 
   Any progress on this?


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


> dependenciesToScan Does Not Leverage Classpath Elements 
> 
>
> Key: SUREFIRE-1383
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1383
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Owen Farrell
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.1
>
> Attachments: scanned-dependencies-sample.zip
>
>  Time Spent: 48h
>  Remaining Estimate: 24h
>
> The  configuration attribute relies solely on installed 
> artifacts. This is an issue when the targeted dependencies were built as part 
> of the current session. The net result is that stale artifacts are used (i.e. 
> if the dependency has changed since it was last installed) or the tests are 
> not executed at all (if the dependency has not been previously installed.
> Attached is a sample project that illustrates this issue:
> Given I have a multi-module project
>And the first module built includes test classes as part of the project 
> artifact
>And subsequent modules scan the first for unit tests to execute
> When I execute the _*test*_ goal (prior to any install)
> Then the build should succeed
>And tests should be executed with each module



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] paulduffin commented on issue #157: SUREFIRE-1383 dependenciesToScan Does Not Leverage Classpath Elements

[GitBox]

paulduffin commented on issue #157: SUREFIRE-1383 dependenciesToScan Does Not 
Leverage Classpath Elements
URL: https://github.com/apache/maven-surefire/pull/157#issuecomment-381108795
 
 
   Any progress on this?


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] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Colbert Philippe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437203#comment-16437203
 ] 

Colbert Philippe commented on MCOMPILER-337:


Robert, did you notice that using your maven-compiler-plugin declaration, the 
compiler puts the list of jar dependencies in BOTH the classpath and the 
module-path?    You can view this in the detailed compiler logs.

I just want to say that the Java documentation says that the jar dependencies 
should be in the module-path ONLY, not both.   It still works but this is 
something to look into.

Colbert

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> {noformat}
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
>  [DEBUG] 

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Colbert Philippe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437202#comment-16437202
 ] 

Colbert Philippe commented on MCOMPILER-337:


Robert, it finally works!    The reason my build was failing is because I was 
using the maven java compiler declaration from this page

[https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html]

By replacing it with your simplified declaration, it works!   I am very  
pleased because my company project can move forward.

Thank-You!

Colbert

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> {noformat}
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
>  [DEBUG] C:\Users\Colbert 
> 

[jira] [Commented] (MPIR-366) Drop Maven 2 support

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437200#comment-16437200
 ] 

Hudson commented on MPIR-366:
-

Build failed in Jenkins: Maven TLP » maven-project-info-reports-plugin » 
MPIR-366 #16

See 
https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-366/16/

> Drop Maven 2 support
> 
>
> Key: MPIR-366
> URL: https://issues.apache.org/jira/browse/MPIR-366
> Project: Maven Project Info Reports Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MPIR-366) Drop Maven 2 support

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPIR-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16437195#comment-16437195
 ] 

Hudson commented on MPIR-366:
-

Build failed in Jenkins: Maven TLP » maven-project-info-reports-plugin » 
MPIR-366 #15

See 
https://builds.apache.org/job/maven-box/job/maven-project-info-reports-plugin/job/MPIR-366/15/

> Drop Maven 2 support
> 
>
> Key: MPIR-366
> URL: https://issues.apache.org/jira/browse/MPIR-366
> Project: Maven Project Info Reports Plugin
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6394) ${revision} and parent.releativePath

[Dorian Vallant (JIRA)]

Dorian Vallant created MNG-6394:
---

 Summary: ${revision} and parent.releativePath
 Key: MNG-6394
 URL: https://issues.apache.org/jira/browse/MNG-6394
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.5.3
 Environment: Ubuntu 17.10; Maven 3.5.3; Java 1.8.0_161
Reporter: Dorian Vallant


If the CI friendly ${revision} property is used it seems maven does not simple 
replace the property with the given value.

Consider the following example:

parent-project/
     pom.xml
 child-project/
     pom.xml

parent-project/pom.xml:
...
    my.group
    parentArtifact
    ${revision}
    pom
...

child-project/pom.xml:
  
my.group
parentArtifact
${revision}
../parent-project
  

If you build the child-project with 'mvn -Drevision=1.0.0-SNAPSHOT -f 
child-project/pom.xml clean install' all works fine as long as the parent 
project is present in the file system. But if you move the parent project to 
another place, build & install it to your local repository and then try to 
build the child project, maven tries to download the pom.xml of the parent 
project but does not replace ${revision}. So maven complains about a missing 
dependency.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436982#comment-16436982
 ] 

Robert Scholte commented on MCOMPILER-337:
--

Have a look at my zip, it works as expected.

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> {noformat}
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
>  [DEBUG] Modulepath: <- All jar file dependencies should be under this 
> ModulePath list ***
>  [DEBUG] C:\Users\Colbert 
> 

[jira] [Updated] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Robert Scholte (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MCOMPILER-337:
-
Attachment: quebec.lachine.zip

> Using old-style Jar files with Java9 Module project, Classpath and 
> Module-path are mixed up!
> 
>
> Key: MCOMPILER-337
> URL: https://issues.apache.org/jira/browse/MCOMPILER-337
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Colbert Philippe
>Priority: Major
> Attachments: quebec.lachine.zip
>
>
> I'm trying to use Eclipse (4.8M4) with Maven to practice Java9 module.
> I already contacted Maven to ask what version of Maven to use with Java 9 
> module feature. They recommended the latest version: Maven 3.5.0 (latest) 
> with the Maven plug-in: maven-compiler-plugin 3.7.0, which is what I'm using. 
> I'm also using Java JDK 9.
> I want to report a problem with Maven when working with Java 9 module 
> feature. It's not a big problem but it's big enough to prevent the use of 
> Maven with Java 9 modules. The problem is with Maven, when used under 
> Eclipse.   I create Maven projects under Eclipse for speed.
> I created two identical projects with Java 9 module. The two projects make 
> use of a few old-style Jar files by importing them as default module (as 
> prescribed by the makers of Java 9). The jar files are: ant.jar, 
> commons-beanutils-1.9.3.jar, commons-collections4-4.1.jar, 
> commons-lang3-3.7.jar.
>  * The first project is a small project built from the command-line with a 
> text-editor. It's a Java 9 module project (has a module-info.java) and makes 
> use of these 4 libray jar files in the manner prescribed by the Java 9 
> documentation. This project compiles and works. All Jar files are put the the 
> module-path of the project and their respective 'requires' statement is in 
> the module-info.java file. (see below)
>  
> {code:java}
> module canada.ontario {
>   exports canada.ontario;
>   requires org.apache.commons.lang3;
>   requires commons.collections4;
>   requires commons.beanutils;
> }
> {code}
>  * 
>  ** The second project is identical to the first one but is built using Maven 
> (versions specified above) created under Eclipse. The project as created as 
> intended based on Maven guidelines. First a parent project was created with 
> packaging set with pom. The a child-project was created for the module.
> After the child-project was created, in the child-project POM file, I entered 
> the full plug-in entries to use the new 'maven-compiler-plugin' version 
> 3.7.0. This works because we can see its use on the compiling log display 
> messages.
> On Eclipse Workspace view, I selected the parent project root (previously 
> created), right clicking on the parent project, then selecting 'Maven', then 
> selecting 'New Maven Module Project'. This creates a Maven child project for 
> the new module.
>  - I created a 'module-info.java' with the name of the module 
> (canada.ontario) in the src directory.
>  - I also created a package with the same name as the module (canada.ontario).
>  - I entered the same 'exports' and 'requires' statements as displayed above.
>  - I also entered all the Maven dependencies to each of the four (4) 
> libraries stated above. I got these dependencies from the Maven repository.
>  - I also enabled full compile-time log-message diplay, in order to get 
> maximum information.
> HERE IS THE PROBLEM WHEN COMPILING THIS SECOND MAVEN CHILD-PROJECT! 
> When compiling the second child-project for the module, there is an error. I 
> have narrowed down the reason for the error.
> For some unknown reason, the Maven compiler plug-in DOES NOT put all the jar 
> dependencies under the module-path. It splits the list of dependencies 
> between the classpath and the module-path, WHICH IS WRONG! (see below)
> {noformat}
> [INFO] Changes detected - recompiling the module!
>  [DEBUG] Classpath: <- There should be no jar under this Classpath list 
> ***
>  [DEBUG] C:\Users\Colbert 
> Philippe\workspace\montreal\quebec.lachine\target\classes
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\org\apache\commons\commons-collections4\4.1\commons-collections4-4.1.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-beanutils\commons-beanutils\1.9.3\commons-beanutils-1.9.3.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar
>  [DEBUG] C:\Users\Colbert 
> Philippe\.m2\repository\commons-collections\commons-collections\3.2.2\commons-collections-3.2.2.jar
>  [DEBUG] Modulepath: <- All jar file dependencies should be under this 
> ModulePath list ***
>  [DEBUG] C:\Users\Colbert 
> 

[jira] [Comment Edited] (MCOMPILER-337) Using old-style Jar files with Java9 Module project, Classpath and Module-path are mixed up!

[Robert Scholte (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436100#comment-16436100
 ] 

Robert Scholte edited comment on MCOMPILER-337 at 4/13/18 7:40 AM:
---

 {noformat}
Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 
2018-02-24T14:49:05-05:00)
 Maven home: C:\Users\Colbert 
Philippe\workspace\montreal\quebec.lachine\EMBEDDED
 Java version: 9, vendor: Oracle Corporation
 Java home: C:\Program Files\Java\jdk-9
 Default locale: en_US, platform encoding: Cp1252
 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
 [DEBUG] Created new class realm maven.api
 [DEBUG] Importing foreign packages into class realm maven.api
 [DEBUG] Imported: javax.annotation.* < plexus.core
 [DEBUG] Imported: javax.annotation.security.* < plexus.core
 [DEBUG] Imported: javax.enterprise.inject.* < plexus.core
 [DEBUG] Imported: javax.enterprise.util.* < plexus.core
 [DEBUG] Imported: javax.inject.* < plexus.core
 [DEBUG] Imported: org.apache.maven.* < plexus.core
 [DEBUG] Imported: org.apache.maven.artifact < plexus.core
 [DEBUG] Imported: org.apache.maven.classrealm < plexus.core
 [DEBUG] Imported: org.apache.maven.cli < plexus.core
 [DEBUG] Imported: org.apache.maven.configuration < plexus.core
 [DEBUG] Imported: org.apache.maven.exception < plexus.core
 [DEBUG] Imported: org.apache.maven.execution < plexus.core
 [DEBUG] Imported: org.apache.maven.execution.scope < plexus.core
 [DEBUG] Imported: org.apache.maven.lifecycle < plexus.core
 [DEBUG] Imported: org.apache.maven.model < plexus.core
 [DEBUG] Imported: org.apache.maven.monitor < plexus.core
 [DEBUG] Imported: org.apache.maven.plugin < plexus.core
 [DEBUG] Imported: org.apache.maven.profiles < plexus.core
 [DEBUG] Imported: org.apache.maven.project < plexus.core
 [DEBUG] Imported: org.apache.maven.reporting < plexus.core
 [DEBUG] Imported: org.apache.maven.repository < plexus.core
 [DEBUG] Imported: org.apache.maven.rtinfo < plexus.core
 [DEBUG] Imported: org.apache.maven.settings < plexus.core
 [DEBUG] Imported: org.apache.maven.toolchain < plexus.core
 [DEBUG] Imported: org.apache.maven.usability < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.* < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.authentication < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.authorization < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.events < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.observers < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.proxy < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.repository < plexus.core
 [DEBUG] Imported: org.apache.maven.wagon.resource < plexus.core
 [DEBUG] Imported: org.codehaus.classworlds < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.* < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.classworlds < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.component < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.configuration < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.container < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.context < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.lifecycle < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.logging < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.personality < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.util.xml.Xpp3Dom < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.util.xml.pull.XmlPullParser < plexus.core
 [DEBUG] Imported: org.codehaus.plexus.util.xml.pull.XmlPullParserException < 
plexus.core
 [DEBUG] Imported: org.codehaus.plexus.util.xml.pull.XmlSerializer < plexus.core
 [DEBUG] Imported: org.eclipse.aether.* < plexus.core
 [DEBUG] Imported: org.eclipse.aether.artifact < plexus.core
 [DEBUG] Imported: org.eclipse.aether.collection < plexus.core
 [DEBUG] Imported: org.eclipse.aether.deployment < plexus.core
 [DEBUG] Imported: org.eclipse.aether.graph < plexus.core
 [DEBUG] Imported: org.eclipse.aether.impl < plexus.core
 [DEBUG] Imported: org.eclipse.aether.installation < plexus.core
 [DEBUG] Imported: org.eclipse.aether.internal.impl < plexus.core
 [DEBUG] Imported: org.eclipse.aether.metadata < plexus.core
 [DEBUG] Imported: org.eclipse.aether.repository < plexus.core
 [DEBUG] Imported: org.eclipse.aether.resolution < plexus.core
 [DEBUG] Imported: org.eclipse.aether.spi < plexus.core
 [DEBUG] Imported: org.eclipse.aether.transfer < plexus.core
 [DEBUG] Imported: org.eclipse.aether.version < plexus.core
 [DEBUG] Imported: org.fusesource.jansi.* < plexus.core
 [DEBUG] Imported: org.slf4j.* < plexus.core
 [DEBUG] Imported: org.slf4j.helpers.* < plexus.core
 [DEBUG] Imported: org.slf4j.spi.* < plexus.core
 [DEBUG] Populating class realm maven.api
 [INFO] Error stacktraces are turned on.
 [DEBUG] Message scheme: plain
 [DEBUG] Reading global settings from settings.xml
 [DEBUG] Reading user settings from C:\Users\Colbert 

[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436963#comment-16436963
 ] 

Tibor Digana commented on SUREFIRE-1480:


How your tests look like? You use ErrorCollector from JUnit?
It would be fantastic to make a simple prototype which can reproduce this
issue.

On Fri, Apr 13, 2018 at 9:38 AM, Tibor Digana (JIRA) 



> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin, 
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
>  * Jenkins 2.108
>  * Maven 3.??
>  * JUnit 4.12
>  * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple 
> JUnit methods), which are all run in parallel. Some of the tests may be 
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an 
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
> 
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being 
> flagged as failed, and Jenkins simply has the message: 
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct 
> filename!).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report

[Tibor Digana (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436959#comment-16436959
 ] 

Tibor Digana commented on SUREFIRE-1480:


Ok, so this needs to be investigated. Select only those tests and run them
and then the class StatelessXmlReporter should be debugged. See the lines I
pointed out in some previous comments.
We need to see the plugin configuration of the project where these classes
reside.

On Fri, Apr 13, 2018 at 8:13 AM, Heiko Wentzke (JIRA) 



> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin, 
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
>  * Jenkins 2.108
>  * Maven 3.??
>  * JUnit 4.12
>  * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple 
> JUnit methods), which are all run in parallel. Some of the tests may be 
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an 
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
> 
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being 
> flagged as failed, and Jenkins simply has the message: 
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct 
> filename!).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report

[Heiko Wentzke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436898#comment-16436898
 ] 

Heiko Wentzke commented on SUREFIRE-1480:
-

For me, nothing has changed, I still have the same issues randomly happening to 
some test classes

> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin, 
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
>  * Jenkins 2.108
>  * Maven 3.??
>  * JUnit 4.12
>  * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple 
> JUnit methods), which are all run in parallel. Some of the tests may be 
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an 
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
> 
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being 
> flagged as failed, and Jenkins simply has the message: 
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct 
> filename!).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)