[jira] [Commented] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552179#comment-16552179
 ] 

Hudson commented on MRESOLVER-48:
-

Build succeeded in Jenkins: Maven TLP » maven-resolver » master #12

See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/12/

> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel

2018-07-22 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552177#comment-16552177
 ] 

ASF GitHub Bot commented on MRESOLVER-7:


michael-o commented on issue #10: [MRESOLVER-7] Download dependency POMs in 
parallel v2
URL: https://github.com/apache/maven-resolver/pull/10#issuecomment-406898751
 
 
   Can someone tell why the daemon threads along with the cached pool is 
necessary?


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


> Download dependency POMs in parallel
> 
>
> Key: MRESOLVER-7
> URL: https://issues.apache.org/jira/browse/MRESOLVER-7
> Project: Maven Resolver
>  Issue Type: Improvement
>Affects Versions: Aether 1.0.2
>Reporter: Harald Wellmann
>Assignee: Michael Osipov
>Priority: Major
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> h3. Background
> When building a project with dependencies not yet available in the local 
> repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the 
> dependency POMs _sequentially_ and then proceeds downloading the dependency 
> JARs with up to 5 threads _in parallel_.
> Due to this, when first building a project with a large number of 
> dependencies, downloading a large number of small POMs may take a lot longer 
> than downloading the much larger JARs, or even longer than building the 
> project itself, especially when a repository manager is used which increases 
> the download latency.
> h3. Enhancement
> Download POMs of (transitive) dependencies in parallel to significantly speed 
> up initial builds of large projects.



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


[GitHub] michael-o commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2

2018-07-22 Thread GitBox
michael-o commented on issue #10: [MRESOLVER-7] Download dependency POMs in 
parallel v2
URL: https://github.com/apache/maven-resolver/pull/10#issuecomment-406898751
 
 
   Can someone tell why the daemon threads along with the cached pool is 
necessary?


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] (MRESOLVER-47) Link to older Aether Wiki in Eclipse on front page

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552173#comment-16552173
 ] 

Hudson commented on MRESOLVER-47:
-

Build succeeded in Jenkins: Maven TLP » maven-resolver » master #11

See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/11/

> Link to older Aether Wiki in Eclipse on front page
> --
>
> Key: MRESOLVER-47
> URL: https://issues.apache.org/jira/browse/MRESOLVER-47
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Karl Heinz Marbaise
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>




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


[jira] [Commented] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552172#comment-16552172
 ] 

ASF GitHub Bot commented on MRESOLVER-48:
-

slachiewicz closed pull request #19: [MRESOLVER-48] Add Travis CI default 
configuration for Java 7, 8, 10
URL: https://github.com/apache/maven-resolver/pull/19
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index ..0a58cab8
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,29 @@
+language: java
+
+sudo: false
+dist: trusty
+
+matrix:
+  include:
+- os: linux
+  jdk: openjdk7
+- os: linux
+  jdk: openjdk8
+- os: linux
+  jdk: openjdk10
+
+before_install:
+# https://github.com/travis-ci/travis-ci/issues/8408
+  - unset _JAVA_OPTIONS
+
+install: mvn clean dependency:go-offline -V
+
+before_script: true
+
+script:
+  - mvn verify
+
+cache:
+  directories:
+  - "$HOME/.cache"
+  - "$HOME/.m2"
diff --git a/pom.xml b/pom.xml
index edaad986..7b8d6428 100644
--- a/pom.xml
+++ b/pom.xml
@@ -351,6 +351,7 @@
   src/test/resources/**/*.ini
   src/test/resources/**/*.txt
   src/test/resources/ssl/*-store
+  .travis.yml
 
   
 


 


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


> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[GitHub] slachiewicz closed pull request #19: [MRESOLVER-48] Add Travis CI default configuration for Java 7, 8, 10

2018-07-22 Thread GitBox
slachiewicz closed pull request #19: [MRESOLVER-48] Add Travis CI default 
configuration for Java 7, 8, 10
URL: https://github.com/apache/maven-resolver/pull/19
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index ..0a58cab8
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,29 @@
+language: java
+
+sudo: false
+dist: trusty
+
+matrix:
+  include:
+- os: linux
+  jdk: openjdk7
+- os: linux
+  jdk: openjdk8
+- os: linux
+  jdk: openjdk10
+
+before_install:
+# https://github.com/travis-ci/travis-ci/issues/8408
+  - unset _JAVA_OPTIONS
+
+install: mvn clean dependency:go-offline -V
+
+before_script: true
+
+script:
+  - mvn verify
+
+cache:
+  directories:
+  - "$HOME/.cache"
+  - "$HOME/.m2"
diff --git a/pom.xml b/pom.xml
index edaad986..7b8d6428 100644
--- a/pom.xml
+++ b/pom.xml
@@ -351,6 +351,7 @@
   src/test/resources/**/*.ini
   src/test/resources/**/*.txt
   src/test/resources/ssl/*-store
+  .travis.yml
 
   
 


 


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] [Closed] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MRESOLVER-48.
---
Resolution: Fixed

Fixed with 
[681754d83a7f77941390e5440ecbc4cb6d811968|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=681754d83a7f77941390e5440ecbc4cb6d811968].

> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[jira] [Commented] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552170#comment-16552170
 ] 

ASF GitHub Bot commented on MRESOLVER-48:
-

michael-o commented on issue #19: [MRESOLVER-48] Add Travis CI default 
configuration for Java 7, 8, 10
URL: https://github.com/apache/maven-resolver/pull/19#issuecomment-406898486
 
 
   Merged, please close.


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


> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[GitHub] michael-o commented on issue #19: [MRESOLVER-48] Add Travis CI default configuration for Java 7, 8, 10

2018-07-22 Thread GitBox
michael-o commented on issue #19: [MRESOLVER-48] Add Travis CI default 
configuration for Java 7, 8, 10
URL: https://github.com/apache/maven-resolver/pull/19#issuecomment-406898486
 
 
   Merged, please close.


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] [Assigned] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov reassigned MRESOLVER-48:
---

Assignee: Michael Osipov

> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[jira] [Updated] (MRESOLVER-48) Add default Travis CI configuration for Java 7, 8, 10

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov updated MRESOLVER-48:

Fix Version/s: Maven Artifact Resolver 1.1.2

> Add default Travis CI configuration for Java 7, 8, 10
> -
>
> Key: MRESOLVER-48
> URL: https://issues.apache.org/jira/browse/MRESOLVER-48
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Add default .travis.yml file for easier testing with Travis CI in forked 
> repositories
> Currently Jenkins infra is available only to ASF members. 



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


[jira] [Closed] (MRESOLVER-47) Link to older Aether Wiki in Eclipse on front page

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MRESOLVER-47.
---
Resolution: Fixed

Fixed with 
[d97e45726eb182c23137d5f9bad77f046386285d|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=d97e45726eb182c23137d5f9bad77f046386285d].

> Link to older Aether Wiki in Eclipse on front page
> --
>
> Key: MRESOLVER-47
> URL: https://issues.apache.org/jira/browse/MRESOLVER-47
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Karl Heinz Marbaise
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>




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


[jira] [Assigned] (MRESOLVER-47) Link to older Aether Wiki in Eclipse on front page

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov reassigned MRESOLVER-47:
---

Assignee: Michael Osipov

> Link to older Aether Wiki in Eclipse on front page
> --
>
> Key: MRESOLVER-47
> URL: https://issues.apache.org/jira/browse/MRESOLVER-47
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Karl Heinz Marbaise
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>




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


[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}

Looks like --add-opens is no longer added? Or is it just appended to the 
command line, not added to the tmp java @arg file?
Or is it that with forkCount=0 the test is ran on the classpath and with 
forkCount=1 the test is ran on the modulepath?

 

If i set it to 2, I get instead:
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 Which is even more mysterious.

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get instead:
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 

[jira] [Closed] (MRESOLVER-20) Create re-packaged uber JAR with basic dependencies to perform resolution against Maven central

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MRESOLVER-20.
---
Resolution: Incomplete

No reaction for a year.

> Create re-packaged uber JAR with basic dependencies to perform resolution 
> against Maven central
> ---
>
> Key: MRESOLVER-20
> URL: https://issues.apache.org/jira/browse/MRESOLVER-20
> Project: Maven Resolver
>  Issue Type: Wish
>Reporter: Graeme Rocher
>Priority: Major
>
> Apache Groovy's @Grab annotation currently uses Ivy for resolution. It would 
> be preferable if Ivy was removed and replaced by Apache Maven Resolver, 
> however one challenge to that is Ivy is a single JAR whilst Apache Maven 
> Resolver has a whole graph of dependencies requiring additional dependency 
> management.
> See http://docs.groovy-lang.org/latest/html/documentation/grape.html
> Would it be a possible to release as part of the release process a single JAR 
> designed to be embedded into systems like @Grab?
> We could also use this same JAR in the Grails project which has a CLI that 
> uses Aether to resolve dependencies from central and a configured list HTTPS 
> repositories.



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


[jira] [Closed] (MRESOLVER-36) SLFJ - remove LoggerFactory from dependency injection

2018-07-22 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MRESOLVER-36.
---
Resolution: Fixed

Postfixed.

> SLFJ - remove LoggerFactory from dependency injection
> -
>
> Key: MRESOLVER-36
> URL: https://issues.apache.org/jira/browse/MRESOLVER-36
> Project: Maven Resolver
>  Issue Type: Improvement
>  Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
>Reporter: Sylwester Lachiewicz
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: Maven Artifact Resolver 1.1.2
>
>
> Because Maven moved to SL4J as the primary login structure we can remove 
> {{NullLoggerFactory}} class and replace {{loggerFactory}} variables with 
> {{LoggerFactory.getLogger}}
> To maintain compatibility constructors will be Deprecated



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


[jira] [Commented] (MRESOLVER-40) Migrate examples to use java annotations

2018-07-22 Thread Michael Osipov (JIRA)


[ 
https://issues.apache.org/jira/browse/MRESOLVER-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552160#comment-16552160
 ] 

Michael Osipov commented on MRESOLVER-40:
-

Is there a PR for that?

> Migrate examples to use java annotations
> 
>
> Key: MRESOLVER-40
> URL: https://issues.apache.org/jira/browse/MRESOLVER-40
> Project: Maven Resolver
>  Issue Type: Improvement
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>
> Migrate examples from javadoc to java 5 annotations in 
> _maven-resolver-demo-maven-plugin_



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


[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 9:19 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following to work with Java 10:
{code:java}

org.apache.maven.plugins
maven-compiler-plugin
[...]
   

org.ow2.asm
asm
6.2 



{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
_This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE._

Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package you're going to get that message.
  

__But__ writing this, I realize looking at the output of \{{mvn -X clean 
install }}again, that in my working configuration Surefire is using the 
classpath and not the module-path??
{code:java}
[DEBUG] test(compact) classpath:  test-classes  classes  
wires-support-1.0-SNAPSHOT.jar  wires-support-1.0-SNAPSHOT-tests.jar  
junit-4.12.jar  hamcrest-core-1.3.jar  assertj-core-3.8.0.jar  
mockito-core-2.8.47.jar  byte-buddy-1.6.14.jar  byte-buddy-agent-1.6.14.jar  
objenesis-2.5.jar  junit-quickcheck-core-0.7.jar  javaruntype-1.2.jar  
antlr-runtime-3.1.2.jar  ognl-3.1.2.jar  javassist-3.11.0.GA.jar  
generics-resolver-2.0.1.jar  junit-quickcheck-generators-0.7.jar
[DEBUG] provider(compact) classpath:  surefire-junit4-2.22.0.jar  
surefire-api-2.22.0.jar  surefire-logger-api-2.22.0.jar{code}
and no mention of the module-path..

*So is {{forkCount}} changing the way classpath/module-path is used by 
Surefire??*

 

NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following to work with Java 10:
{code:java}

org.apache.maven.plugins
maven-compiler-plugin
[...]
   

org.ow2.asm
asm
6.2 



{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed 

[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 9:16 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following to work with Java 10:
{code:java}

org.apache.maven.plugins
maven-compiler-plugin
[...]
   

org.ow2.asm
asm
6.2 



{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package you're going to get that message.
  

__But__ writing this, I realize looking at the output of \{{mvn -X clean 
install }}again, that in my working configuration Surefire is using the 
classpath and not the module-path??
{code:java}
[DEBUG] test(compact) classpath:  test-classes  classes  
wires-support-1.0-SNAPSHOT.jar  wires-support-1.0-SNAPSHOT-tests.jar  
junit-4.12.jar  hamcrest-core-1.3.jar  assertj-core-3.8.0.jar  
mockito-core-2.8.47.jar  byte-buddy-1.6.14.jar  byte-buddy-agent-1.6.14.jar  
objenesis-2.5.jar  junit-quickcheck-core-0.7.jar  javaruntype-1.2.jar  
antlr-runtime-3.1.2.jar  ognl-3.1.2.jar  javassist-3.11.0.GA.jar  
generics-resolver-2.0.1.jar  junit-quickcheck-generators-0.7.jar
[DEBUG] provider(compact) classpath:  surefire-junit4-2.22.0.jar  
surefire-api-2.22.0.jar  surefire-logger-api-2.22.0.jar{code}
and no mention of the module-path..

*So is {{forkCount}} changing the way classpath/module-path is used by 
Surefire??*

 

NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed 

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get instead:
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get instead (!):
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get instead (!):
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get:
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: 

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} or set it to 1 in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

If i set it to 2, I get:
{code:java}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
project wires-support: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test failed: 
java.lang.ClassNotFoundException: 
org.apache.maven.plugin.surefire.StartupReportConfiguration -> [Help 1]{code}
 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt, 
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire 

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

Environment:
{code:java}
$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-17T20:33:14+02:00)
Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program 
Files\Java\jdk-10.0.2
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"{code}

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt, 
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> 

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Attachment: mvn-X-clean-install--noforkCount0-KO.txt

> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt, 
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException: 
> java.lang.IllegalAccessException: class 
> com.pholser.junit.quickcheck.internal.Reflection cannot access class 
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
> fr.cla.wires.core) because module fr.cla.wires.core does not export 
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-exports is no longer passed or something?
>  



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


[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Attachment: mvn-X-clean-install--forkCount0-OK.txt

> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt, 
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException: 
> java.lang.IllegalAccessException: class 
> com.pholser.junit.quickcheck.internal.Reflection cannot access class 
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
> fr.cla.wires.core) because module fr.cla.wires.core does not export 
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-exports is no longer passed or something?
>  



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


[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Attachment: (was: mvn-X-clean-install--forkCount0.txt)

> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0-OK.txt, 
> mvn-X-clean-install--noforkCount0-KO.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException: 
> java.lang.IllegalAccessException: class 
> com.pholser.junit.quickcheck.internal.Reflection cannot access class 
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
> fr.cla.wires.core) because module fr.cla.wires.core does not export 
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-exports is no longer passed or something?
>  



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


[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Attachment: mvn-X-clean-install--forkCount0.txt

> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException: 
> java.lang.IllegalAccessException: class 
> com.pholser.junit.quickcheck.internal.Reflection cannot access class 
> fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
> fr.cla.wires.core) because module fr.cla.wires.core does not export 
> fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
> {code}
> Looks like --add-exports is no longer passed or something?
>  



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


[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}
Looks like --add-exports is no longer passed or something?

 

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}

-->It looks like {{argLine}} options are appended incorrectly to the final 
command line when {{forkCount > 0}} ?

>From what I saw, Surefire calls Java with an {{@argFile}} argument pointing to 
>a tmp file with all the arguments (here 
>{{@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952}}),
> so the {{--add-opens}} should go into that.

But it seems it only does when {{forkCount ==0}} ??


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
> Attachments: mvn-X-clean-install--forkCount0.txt
>
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  <<< ERROR!
> com.pholser.junit.quickcheck.internal.ReflectionException: 
> 

[jira] [Updated] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)


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

foo bar updated SUREFIRE-1539:
--
Description: 
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
[ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 s 
<<< FAILURE! - in 
fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
[ERROR] 
should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
  Time elapsed: 0.219 s  <<< ERROR!
com.pholser.junit.quickcheck.internal.ReflectionException: 
java.lang.IllegalAccessException: class 
com.pholser.junit.quickcheck.internal.Reflection cannot access class 
fr.cla.wires.core.support.tests.pbt.BooleansGenerator (in module 
fr.cla.wires.core) because module fr.cla.wires.core does not export 
fr.cla.wires.core.support.tests.pbt to unnamed module @4b5a5ed1
{code}

-->It looks like {{argLine}} options are appended incorrectly to the final 
command line when {{forkCount > 0}} ?

>From what I saw, Surefire calls Java with an {{@argFile}} argument pointing to 
>a tmp file with all the arguments (here 
>{{@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952}}),
> so the {{--add-opens}} should go into that.

But it seems it only does when {{forkCount ==0}} ??

  was:
h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
    Command was cmd.exe /X /C ""C:\Program Files\Java\jdk-10.0.2\bin\java" 
--add-opens fr.cla.wires.core.support.tests.pbt=ALL-UNNAMED 
@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952
 C:\Users\User\AppData\Local\Temp\surefire17232382819109770877 
2018-07-22T17-31-27_183-jvmRun1 surefire6300613916016740531tmp 
surefire_0406188086577321752tmp"
{code}
-->It looks like {{argLine}} options are appended incorrectly to the final 
command line when {{forkCount > 0}} ?

>From what I saw, Surefire calls Java with an {{@argFile}} argument pointing to 
>a tmp file with all the arguments (here 
>{{@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952}}),
> so the {{--add-opens}} should go into that.

But it seems it only does when {{forkCount ==0}} ??


> Surefire causes Jigwaw runtime errors when forkCount > 0
> 
>
> Key: SUREFIRE-1539
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: foo bar
>Priority: Major
>
> h1. The problem
> I'm migrating my toy project to Jigsaw modules. 
>  Now I managed to make it work ({{maven clean install}} OK), but I had to 
> pass an additional flag to Surefire ({{forkCount=0}}) that I think I 
> shouldn't have to and feels very "magical" (in a bad way).
> To reproduce:
>      1. {{git clone [https://github.com/vandekeiser/wires.git]}}
>      2. {{git checkout REPORT_SUREFIRE}}
>      3.1 {{mvn clean install}}
>      -->passes
>      3.2 remove {{0}} in {{/pom.xml}}
>      -->fails
> h1. Analysis
> If I remove {{0}} in {{/pom.xml}} I get:
> {code:java}
> [ERROR] Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 5.678 
> s <<< FAILURE! - in 
> fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest
> [ERROR] 
> should_sometimes_give_false(fr.cla.wires.core.boxes.exampleusage.propertybasedtesting.MultipleAnd_ReduceAndCollectShouldBeEquivalent_PbtTest)
>   Time elapsed: 0.219 s  

[GitHub] cardil commented on issue #112: Adding support for externally passed random seed and printing used seed on console

2018-07-22 Thread GitBox
cardil commented on issue #112: Adding support for externally passed random 
seed and printing used seed on console
URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-406889805
 
 
   Ok. I've manage to fix this bug. Tests are now passing on Linux and Windows 
on multiple JDK: Azul, Oracle and OpenJDK.
   
   The error was that test randomization was done on list of loaded classes, 
but class loading doesn't provide a contract on order of loading. So, input 
list was platform dependent. I've added pre step of sorting input class list. 
In that way randomization with seed is predictable, every time on every 
platform.
   
   
https://github.com/apache/maven-surefire/pull/112/files#diff-5bf860cde9189b3ffb9b3e0295282663R42
   
   @Tibor17 please review again


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] (MDOAP-58) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MDOAP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552128#comment-16552128
 ] 

Hudson commented on MDOAP-58:
-

Build succeeded in Jenkins: Maven TLP » maven-doap-plugin » master #22

See https://builds.apache.org/job/maven-box/job/maven-doap-plugin/job/master/22/

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDOAP-58
> URL: https://issues.apache.org/jira/browse/MDOAP-58
> Project: Maven DOAP Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Closed] (MDOAP-58) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise closed MDOAP-58.

Resolution: Done

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDOAP-58
> URL: https://issues.apache.org/jira/browse/MDOAP-58
> Project: Maven DOAP Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Commented] (MDOAP-58) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MDOAP-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552127#comment-16552127
 ] 

Karl Heinz Marbaise commented on MDOAP-58:
--

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

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDOAP-58
> URL: https://issues.apache.org/jira/browse/MDOAP-58
> Project: Maven DOAP Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Assigned] (MDOAP-58) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise reassigned MDOAP-58:


Assignee: Karl Heinz Marbaise

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDOAP-58
> URL: https://issues.apache.org/jira/browse/MDOAP-58
> Project: Maven DOAP Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Created] (MDOAP-58) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MDOAP-58:


 Summary: Upgrade maven-plugins parent to version 32
 Key: MDOAP-58
 URL: https://issues.apache.org/jira/browse/MDOAP-58
 Project: Maven DOAP Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
 Fix For: 3.0.0






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


[jira] [Commented] (MDEPLOY-238) Upgrade JUnit 4.11 to 4.12

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552119#comment-16552119
 ] 

Hudson commented on MDEPLOY-238:


Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » master #17

See 
https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/17/

> Upgrade JUnit 4.11 to 4.12
> --
>
> Key: MDEPLOY-238
> URL: https://issues.apache.org/jira/browse/MDEPLOY-238
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Closed] (MDEPLOY-238) Upgrade JUnit 4.11 to 4.12

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise closed MDEPLOY-238.
---
Resolution: Done

> Upgrade JUnit 4.11 to 4.12
> --
>
> Key: MDEPLOY-238
> URL: https://issues.apache.org/jira/browse/MDEPLOY-238
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Commented] (MDEPLOY-238) Upgrade JUnit 4.11 to 4.12

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552116#comment-16552116
 ] 

Karl Heinz Marbaise commented on MDEPLOY-238:
-

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

> Upgrade JUnit 4.11 to 4.12
> --
>
> Key: MDEPLOY-238
> URL: https://issues.apache.org/jira/browse/MDEPLOY-238
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Assigned] (MDEPLOY-238) Upgrade JUnit 4.11 to 4.12

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise reassigned MDEPLOY-238:
---

Assignee: Karl Heinz Marbaise

> Upgrade JUnit 4.11 to 4.12
> --
>
> Key: MDEPLOY-238
> URL: https://issues.apache.org/jira/browse/MDEPLOY-238
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Created] (MDEPLOY-238) Upgrade JUnit 4.11 to 4.12

2018-07-22 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MDEPLOY-238:
---

 Summary: Upgrade JUnit 4.11 to 4.12
 Key: MDEPLOY-238
 URL: https://issues.apache.org/jira/browse/MDEPLOY-238
 Project: Maven Deploy Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
 Fix For: 3.0.0






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


[jira] [Commented] (MDEPLOY-237) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552108#comment-16552108
 ] 

Hudson commented on MDEPLOY-237:


Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » master #16

See 
https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/16/

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEPLOY-237
> URL: https://issues.apache.org/jira/browse/MDEPLOY-237
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 5:56 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package you're going to get that message.
  

__But__ writing this, I realize looking at the output of {{mvn -X clean install 
}}again, that in my working configuration Surefire is using the classpath and 
not the module-path??
{code:java}
[DEBUG] test(compact) classpath:  test-classes  classes  
wires-support-1.0-SNAPSHOT.jar  wires-support-1.0-SNAPSHOT-tests.jar  
junit-4.12.jar  hamcrest-core-1.3.jar  assertj-core-3.8.0.jar  
mockito-core-2.8.47.jar  byte-buddy-1.6.14.jar  byte-buddy-agent-1.6.14.jar  
objenesis-2.5.jar  junit-quickcheck-core-0.7.jar  javaruntype-1.2.jar  
antlr-runtime-3.1.2.jar  ognl-3.1.2.jar  javassist-3.11.0.GA.jar  
generics-resolver-2.0.1.jar  junit-quickcheck-generators-0.7.jar
[DEBUG] provider(compact) classpath:  surefire-junit4-2.22.0.jar  
surefire-api-2.22.0.jar  surefire-logger-api-2.22.0.jar{code}
and no mention of the module-path..

*So is {{forkCount}} changing the way classpath/module-path is used by 
Surefire??*

 

NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 

[jira] [Commented] (MDEPLOY-237) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16552104#comment-16552104
 ] 

Karl Heinz Marbaise commented on MDEPLOY-237:
-

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

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEPLOY-237
> URL: https://issues.apache.org/jira/browse/MDEPLOY-237
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Closed] (MDEPLOY-237) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise closed MDEPLOY-237.
---
Resolution: Done

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEPLOY-237
> URL: https://issues.apache.org/jira/browse/MDEPLOY-237
> Project: Maven Deploy Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>
> 



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


[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 5:19 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package you're going to get that message.
  

__But__ writing this, I realize looking at the output of {{mvn -X clean install 
}}again, that in my working configuration Surefire is using the classpath and 
not the module-path??
{code:java}
[DEBUG] test(compact) classpath:  test-classes  classes  
wires-support-1.0-SNAPSHOT.jar  wires-support-1.0-SNAPSHOT-tests.jar  
junit-4.12.jar  hamcrest-core-1.3.jar  assertj-core-3.8.0.jar  
mockito-core-2.8.47.jar  byte-buddy-1.6.14.jar  byte-buddy-agent-1.6.14.jar  
objenesis-2.5.jar  junit-quickcheck-core-0.7.jar  javaruntype-1.2.jar  
antlr-runtime-3.1.2.jar  ognl-3.1.2.jar  javassist-3.11.0.GA.jar  
generics-resolver-2.0.1.jar  junit-quickcheck-generators-0.7.jar
[DEBUG] provider(compact) classpath:  surefire-junit4-2.22.0.jar  
surefire-api-2.22.0.jar  surefire-logger-api-2.22.0.jar{code}
and no mention of the module-path..

*So is {{forkCount}} changing the way classpath/module-path is used??*

 

NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or 

[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 5:18 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package you're going to get that message.
  

__But__ writing this, I realize looking at the output of {{mvn -X clean install 
}}again, that in my working configuration Surefire is using the classpath and 
not the module-path??
{code:java}
[DEBUG] test(compact) classpath:  test-classes  classes  
wires-support-1.0-SNAPSHOT.jar  wires-support-1.0-SNAPSHOT-tests.jar  
junit-4.12.jar  hamcrest-core-1.3.jar  assertj-core-3.8.0.jar  
mockito-core-2.8.47.jar  byte-buddy-1.6.14.jar  byte-buddy-agent-1.6.14.jar  
objenesis-2.5.jar  junit-quickcheck-core-0.7.jar  javaruntype-1.2.jar  
antlr-runtime-3.1.2.jar  ognl-3.1.2.jar  javassist-3.11.0.GA.jar  
generics-resolver-2.0.1.jar  junit-quickcheck-generators-0.7.jar
[DEBUG] provider(compact) classpath:  surefire-junit4-2.22.0.jar  
surefire-api-2.22.0.jar  surefire-logger-api-2.22.0.jar{code}
and no mention of the module-path..

So is {{forkCount}} changing the way classpath/module-path is used??

 

NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or 

[jira] [Comment Edited] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar edited comment on MCOMPILER-348 at 7/22/18 5:08 PM:


As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

Also thinking about your latest answer, I don't agree with your description. I 
say why after the big - separator at the end.

 

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
  

I also had to add the following:
{code:java}


org.ow2.asm
asm
6.2 


{code}
 
 And it was important that:
{code:java}
2.22.0
{code}
(doesn't work with any older version)

 

--
 I don't agree with you description when you say:
{noformat}
This looks like a bug in the Java Compiler. I don't see a reason why 
--add-exports should be added, since all classes of the unnamed module should 
be able to see each other. Also, as you mentioned, the empty modulename is 
weird. It should at least have said UNNAMED_MODULE.
{noformat}
Surefire runs tests using the module-path (unlike IJ) so the application test 
class ends up on the module path. Therefore it is not in the classpath, and 
thus not in the unnamed module. 
 On the other hand, the test framework (here junit quick check) is in the 
unnamed module because it's on the classpath.
 Yes the unnamed module requires all modules, but if the test class isn't in an 
exported or opened package.
  
 NB: I also wonder if I didn't see that surefire was putting test-classes both 
in the classpath and on the module-path, which feels wrong. Reminder to myself 
to check.


was (Author: vandekeizer):
As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
 

I also had to add the following:

{code:java}


org.ow2.asm
asm
6.2 


{code}

 
And it was important that:

{code:java}
2.22.0
{code}

(doesn't work with any older version) 

> Can't make test-scoped dependencies work with Java 9 modules
> 
>
> Key: MCOMPILER-348
> URL: https://issues.apache.org/jira/browse/MCOMPILER-348
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 9.0.4, vendor: Oracle Corporation, runtime: C:\Program 
> Files\Java\jdk-9.0.4
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: foo bar
>Priority: Major
>  Labels: Java9, jigsaw, scope, test
> Attachments: MCOMPILER-348-reproduce.7z, 
> mvn-X-clean-install-output.txt
>
>
> h1. In short
> With Java 9 if I declare both the test-scoped dependency and the Java 9 
> modules the test doesn't compile anymore (mvn clean install output):
> {code:java}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project clientmod: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /G:/projets/wires/wires/wires/clientmod/src/test/java/qux/DerivedTest.java:[3,11]
>  package api does not exist
> [ERROR] 
> /G:/projets/wires/wires/wires/clientmod/src/test/java/qux/DerivedTest.java:[11,13]
>  cannot find symbol
> [ERROR]   symbol:   class Base
> [ERROR]   location: class qux.DerivedTest
> [ERROR] -> [Help 1]
> {code}
> *That same test {{DerivedTest}} compiles and runs just fine in IntelliJ!* So 
> it's probably worth it to look at the different flags that Maven passes to 
> javac and java compared to IJ? 
> h1. 

[jira] [Commented] (MNG-6449) Upgrade parent to 32

2018-07-22 Thread Hudson (JIRA)


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

Hudson commented on MNG-6449:
-

Build failed in Jenkins: Maven TLP » maven » MNG-6449 #2

See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6449/2/

> Upgrade parent to 32
> 
>
> Key: MNG-6449
> URL: https://issues.apache.org/jira/browse/MNG-6449
> Project: Maven
>  Issue Type: Dependency upgrade
>Affects Versions: 3.6.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.0
>
>




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


[jira] [Commented] (MCOMPILER-348) Can't make test-scoped dependencies work with Java 9 modules

2018-07-22 Thread foo bar (JIRA)


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

foo bar commented on MCOMPILER-348:
---

As promised I did some digging. Turns out the problem is in Surefire, I created 
an issue:

_Surefire causes Jigwaw runtime errors when forkCount > 0_

https://issues.apache.org/jira/browse/SUREFIRE-1539

 

But apart from having to specify: {{0}} for Surefire, I 
now have a functionning Jigsaw config, including test-scoped dependencies and 
whitebox testing ({{src/test}} can test package-private from {{src/main}}).

 

You can check it out with:

    1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3. {{mvn clean install}}
     -->passes (with JDK 10.0.2)
 

I also had to add the following:

{code:java}


org.ow2.asm
asm
6.2 


{code}

 
And it was important that:

{code:java}
2.22.0
{code}

(doesn't work with any older version) 

> Can't make test-scoped dependencies work with Java 9 modules
> 
>
> Key: MCOMPILER-348
> URL: https://issues.apache.org/jira/browse/MCOMPILER-348
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 9.0.4, vendor: Oracle Corporation, runtime: C:\Program 
> Files\Java\jdk-9.0.4
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: foo bar
>Priority: Major
>  Labels: Java9, jigsaw, scope, test
> Attachments: MCOMPILER-348-reproduce.7z, 
> mvn-X-clean-install-output.txt
>
>
> h1. In short
> With Java 9 if I declare both the test-scoped dependency and the Java 9 
> modules the test doesn't compile anymore (mvn clean install output):
> {code:java}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project clientmod: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /G:/projets/wires/wires/wires/clientmod/src/test/java/qux/DerivedTest.java:[3,11]
>  package api does not exist
> [ERROR] 
> /G:/projets/wires/wires/wires/clientmod/src/test/java/qux/DerivedTest.java:[11,13]
>  cannot find symbol
> [ERROR]   symbol:   class Base
> [ERROR]   location: class qux.DerivedTest
> [ERROR] -> [Help 1]
> {code}
> *That same test {{DerivedTest}} compiles and runs just fine in IntelliJ!* So 
> it's probably worth it to look at the different flags that Maven passes to 
> javac and java compared to IJ? 
> h1. Explanation of the 2 modules, and what fails
> I have a java 9 maven project with 2 modules: {{apimod}} and {{clientmod}}. 
> Module {{clientmod}} depends on module {{apimod}} (those modules are both 
> Maven modules and Java 9 modules).
> Also, i want module {{clientmod}} to be able to reuse not only production 
> code from {{apimod}}, *but also test code*. This is a common pattern, that I 
> used many times with Java 8. With Java 9 (it's the same with Java 10) it also 
> works fine, as long as i don't declare module-info.java (that is, as long as 
> I don't run with the module system).
> But as soon as I do, enabling the test dependency seems to disable the 
> production dependency: {{api.Base}} (an {{src/main}} class of module 
> {{apimod}}) is no longer visible from {{qux.DerivedTest}} (an {{src/test}} 
> class of module {{clientmod}}). The test doesn't compile anymore. (_Note that 
> every class is in a different package to eliminate split packages as a cause 
> of the problem_)
> This is with: Java 9.0.4 (it's the same with Java 10), Maven 3.5.3, 
> maven-compiler-plugin 3.7.0
>  
> h1. A project to reproduce the issue
> h2. The code
> I "dichotomized" the issue with a failing test in a branch:
> {code:java}
> git clone https://github.com/vandekeiser/wires.git
> git checkout MCOMPILER_ISSUE2
> mvn clean install{code}
> -> BUILD FAIL (compilation error in the test of {{clientmod}})
> h2. The Maven test-scoped dependency
> I want module {{clientmod}} to be able to reuse not only production code from 
> {{apimod}} but also test code. With Maven you do it like that 
> ({{clientmod/pom.xml}}):
> {code:java}
> 
>     fr.cla
>     apimod
>     ${project.version}
>     tests
>     test
> 
> {code}
> h2. The Java 9 modules
> {code:java}
> module apimod {
>     exports api;
> }
> module clientmod {
>     requires apimod;
> }
> {code}
> h2. The failure when trying to enable both module systems
> With Java 9 if I declare both the test-scoped dependency and the Java 9 
> modules the test doesn't compile anymore ({{mvn clean 

[jira] [Created] (SUREFIRE-1539) Surefire causes Jigwaw runtime errors when forkCount > 0

2018-07-22 Thread foo bar (JIRA)
foo bar created SUREFIRE-1539:
-

 Summary: Surefire causes Jigwaw runtime errors when forkCount > 0
 Key: SUREFIRE-1539
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1539
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Plugin
Affects Versions: 2.22.0
Reporter: foo bar


h1. The problem

I'm migrating my toy project to Jigsaw modules. 
 Now I managed to make it work ({{maven clean install}} OK), but I had to pass 
an additional flag to Surefire ({{forkCount=0}}) that I think I shouldn't have 
to and feels very "magical" (in a bad way).

To reproduce:
     1. {{git clone [https://github.com/vandekeiser/wires.git]}}
     2. {{git checkout REPORT_SUREFIRE}}
     3.1 {{mvn clean install}}
     -->passes
     3.2 remove {{0}} in {{/pom.xml}}
     -->fails
h1. Analysis

If I remove {{0}} in {{/pom.xml}} I get:
{code:java}
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
    Command was cmd.exe /X /C ""C:\Program Files\Java\jdk-10.0.2\bin\java" 
--add-opens fr.cla.wires.core.support.tests.pbt=ALL-UNNAMED 
@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952
 C:\Users\User\AppData\Local\Temp\surefire17232382819109770877 
2018-07-22T17-31-27_183-jvmRun1 surefire6300613916016740531tmp 
surefire_0406188086577321752tmp"
{code}
-->It looks like {{argLine}} options are appended incorrectly to the final 
command line when {{forkCount > 0}} ?

>From what I saw, Surefire calls Java with an {{@argFile}} argument pointing to 
>a tmp file with all the arguments (here 
>{{@C:\Users\User\AppData\Local\Temp\surefire17232382819109770877\surefireargs1242676904531575952}}),
> so the {{--add-opens}} should go into that.

But it seems it only does when {{forkCount ==0}} ??



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


[GitHub] cardil edited a comment on issue #112: Adding support for externally passed random seed and printing used seed on console

2018-07-22 Thread GitBox
cardil edited a comment on issue #112: Adding support for externally passed 
random seed and printing used seed on console
URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-406868127
 
 
   Yup. It's the right branch. Those tests are ones that I added. They test if 
running with given seed will produce repeatable build. Ideally it should 
produce the same outcome on every machine thus those tests I've added. I will 
dig in to this to determine a fault.
   
   I've manage to reproduce those errors on different machine, with Windows 10. 
Running it from IT test fails with errors you just posted. Maybe forked 
launcher somehow involves?!
   
   I will dig into more and keep you posted.


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] cardil edited a comment on issue #112: Adding support for externally passed random seed and printing used seed on console

2018-07-22 Thread GitBox
cardil edited a comment on issue #112: Adding support for externally passed 
random seed and printing used seed on console
URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-406868127
 
 
   Yup. It's the right branch. Those tests are ones that I added. They test if 
running with given seed will produce repeatable build. Ideally it should 
produce the same outcome on every machine thus those tests I've added. I will 
dig in to this to determine a fault.
   
   I've manage to reproduce those errors on different machine, with Windows 10. 
It's very strange, because when I run it directly, everything works properly. 
This is good news as library works well, only tests are faulty:
   
   ```bash
   cd surefire-its/target/RunOrderIT_testRandomWithSeed123456
   mvn test -Dsurefire.version=3.0.0-SNAPSHOT
   ```
   
   Running it from IT test fails with errors you just posted. Maybe forked 
launcher somehow involves?!
   
   I will dig into more and keep you posted.


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] cardil commented on issue #112: Adding support for externally passed random seed and printing used seed on console

2018-07-22 Thread GitBox
cardil commented on issue #112: Adding support for externally passed random 
seed and printing used seed on console
URL: https://github.com/apache/maven-surefire/pull/112#issuecomment-406868127
 
 
   Yup. It's the right branch. Those tests are one that I added. They test if 
running with given seed will produce repeatable build. Ideally it should 
produce the same outcome on every machine thus those tests I've added. I will 
dig in to this to determine a fault.
   
   I've manage to reproduce those errors on different machine, with Windows 10. 
It's very strange, because when I run it directly, everything works properly. 
This is good news as library works well, only tests are faulty:
   
   ```bash
   cd surefire-its/target/RunOrderIT_testRandomWithSeed123456
   mvn test -Dsurefire.version=3.0.0-SNAPSHOT
   ```
   
   Running it from IT test fails with errors you just posted. Maybe forked 
launcher somehow involves?!
   
   I will dig into more and keep you posted.


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] (MPOM-198) Updated plexus-container-default to 1.7.1 and plexus-utils to 3.1.0 for Doxia Tools

2018-07-22 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MPOM-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551985#comment-16551985
 ] 

Hervé Boutemy commented on MPOM-198:


thinking about it, what could be useful would be to migrate everything to sisu 
instead of plexis-container-default: this change would be useful

>  Updated plexus-container-default to 1.7.1 and plexus-utils to 3.1.0 for 
> Doxia Tools
> 
>
> Key: MPOM-198
> URL: https://issues.apache.org/jira/browse/MPOM-198
> Project: Maven POMs
>  Issue Type: Dependency upgrade
>  Components: doxia-tools
>Reporter: Sylwester Lachiewicz
>Priority: Trivial
>




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


[jira] [Commented] (SCM-791) maven-scm-provider-gitexe - Lastest version (1.9.2) doesn't work properly in Cygwin

2018-07-22 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/SCM-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551978#comment-16551978
 ] 

ASF GitHub Bot commented on SCM-791:


basinilya opened a new pull request #77: SCM-791,SCM-815: fixes for Windows 
paths in git command line
URL: https://github.com/apache/maven-scm/pull/77
 
 
   Cygwin: use relative path for checkout directory
   Cygwin: force forward slashes in commands
   Git for Windows: fix file://\\unc\path does not appear to be a git repository


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


> maven-scm-provider-gitexe - Lastest version (1.9.2) doesn't work properly in 
> Cygwin
> ---
>
> Key: SCM-791
> URL: https://issues.apache.org/jira/browse/SCM-791
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.2
> Environment: Cygwin under Windows 8
>Reporter: Irineu Ruiz
>Priority: Critical
> Attachments: test_1.9.2_Cygwin.log, test_1.9.2_prompt.log, 
> test_HEAD_Cygwin.log, test_HEAD_prompt.log
>
>
> The tests of the maven-scm project fails in CygWin and passed in command 
> prompt, as you can see in the attachment.
> Also, using Cygwin under Windows 8, we can't execute a mvn release:prepare 
> properly, because pom.xml is not correct commited in tag and HEAD of 
> repository.
> The maven gives a false positive of Build Sucess, but the tag is incorret, 
> with the SNAPSHOT termination in version.



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


[GitHub] basinilya opened a new pull request #77: SCM-791, SCM-815: fixes for Windows paths in git command line

2018-07-22 Thread GitBox
basinilya opened a new pull request #77: SCM-791,SCM-815: fixes for Windows 
paths in git command line
URL: https://github.com/apache/maven-scm/pull/77
 
 
   Cygwin: use relative path for checkout directory
   Cygwin: force forward slashes in commands
   Git for Windows: fix file://\\unc\path does not appear to be a git repository


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] (MDEP-624) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551957#comment-16551957
 ] 

Hudson commented on MDEP-624:
-

Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #27

See 
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/27/

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEP-624
> URL: https://issues.apache.org/jira/browse/MDEP-624
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.1.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.2
>
>
> 



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


[jira] [Created] (MDEPLOY-237) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MDEPLOY-237:
---

 Summary: Upgrade maven-plugins parent to version 32
 Key: MDEPLOY-237
 URL: https://issues.apache.org/jira/browse/MDEPLOY-237
 Project: Maven Deploy Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
 Fix For: 3.0.0






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


[jira] [Closed] (MDEP-624) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise closed MDEP-624.

Resolution: Done

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEP-624
> URL: https://issues.apache.org/jira/browse/MDEP-624
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.1.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.2
>
>
> 



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


[jira] [Commented] (MDEP-624) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


[ 
https://issues.apache.org/jira/browse/MDEP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551950#comment-16551950
 ] 

Karl Heinz Marbaise commented on MDEP-624:
--

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

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEP-624
> URL: https://issues.apache.org/jira/browse/MDEP-624
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.1.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.2
>
>
> 



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


[jira] [Assigned] (MDEP-624) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)


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

Karl Heinz Marbaise reassigned MDEP-624:


Assignee: Karl Heinz Marbaise

> Upgrade maven-plugins parent to version 32
> --
>
> Key: MDEP-624
> URL: https://issues.apache.org/jira/browse/MDEP-624
> Project: Maven Dependency Plugin
>  Issue Type: Dependency upgrade
>Affects Versions: 3.1.2
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.1.2
>
>
> 



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


[jira] [Created] (MDEP-624) Upgrade maven-plugins parent to version 32

2018-07-22 Thread Karl Heinz Marbaise (JIRA)
Karl Heinz Marbaise created MDEP-624:


 Summary: Upgrade maven-plugins parent to version 32
 Key: MDEP-624
 URL: https://issues.apache.org/jira/browse/MDEP-624
 Project: Maven Dependency Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.1.2
Reporter: Karl Heinz Marbaise
 Fix For: 3.1.2






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