[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621181#comment-16621181 ] Sylwester Lachiewicz commented on MNG-6481: --- I have build that pass compile and tests for 7, 8 and 11 here: [https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/job/remove-commons-lang/] - we only need to remove commons-lang3 dependency or upgrade to an upper version with Java 11 support. > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.x-candidate > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9 and 10? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened SUREFIRE-1570:
--
Reopening. Using the same test with surefire does work as expected.
When running with {{-X}} you'll see that surefire does show the modulepath, but
failsafe is missing that part.
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module jdk.internal.opt
> module java.management.rmi
> module jdk.management.jfr
> module javafx.swing
> module jdk.editpad
> module jdk.crypto.ec
> module jdk.javaws
> module jdk.jstatd
> module jdk.management.agent
> module javafx.graphics
> module javafx.media
> module java.rmi
> module java.prefs
> module jdk.security.jgss
> module javafx.fxml
> module java.smartcardio
> module jdk.xml.dom
> module java.xml.crypto
> module jdk.jsobject
> module jdk.jdi
> module jdk.compiler
> module java.management
> module jdk.management.cmm
> module jdk.packager.services
> module jdk.jartool
> module jdk.scripting.nashorn
> module java.security.jgss
> module jdk.localedata
> module java.desktop
> module jdk.zipfs
> module jdk.jshell
> module oracle.desktop
> module jdk.internal.ed
> module java.security.sasl
> module jdk.jdwp.agent
>
[jira] [Comment Edited] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621031#comment-16621031
]
Pavel_K edited comment on SUREFIRE-1570 at 9/19/18 6:46 PM:
OK. Read JPMS specification. See also ServiceProvider javadoc
https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html . Read
tutorials in internet. Try them. See how they work.
We don't create META-INF/services we create only one file - module-info, which
contains all the information about service (provides with). JPMS manages
services itself. You are confused because for getting JPMS service is used old
ServiceProvider.
was (Author: pavel_k):
OK. Read JPMS specification. See also ServiceProvider javadoc
https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html . Read
tutorials in internet. Try them. See how they work.
This don't create META-INF/services we create only one file - module-info,
which contains all the information about service (provides with). JPMS manages
services itself. You are confused because for getting JPMS service is used old
ServiceProvider.
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module
[jira] [Commented] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621031#comment-16621031
]
Pavel_K commented on SUREFIRE-1570:
---
OK. Read JPMS specification. See also ServiceProvider javadoc
https://docs.oracle.com/javase/9/docs/api/java/util/ServiceLoader.html . Read
tutorials in internet. Try them. See how they work.
This don't create META-INF/services we create only one file - module-info,
which contains all the information about service (provides with). JPMS manages
services itself. You are confused because for getting JPMS service is used old
ServiceProvider.
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module jdk.internal.opt
> module java.management.rmi
> module jdk.management.jfr
> module javafx.swing
> module jdk.editpad
> module jdk.crypto.ec
> module jdk.javaws
> module jdk.jstatd
> module jdk.management.agent
> module javafx.graphics
> module javafx.media
> module java.rmi
> module java.prefs
> module jdk.security.jgss
> module javafx.fxml
> module java.smartcardio
> module jdk.xml.dom
> module java.xml.crypto
> module jdk.jsobject
> module jdk.jdi
> module jdk.compiler
> module java.management
> module jdk.management.cmm
>
[jira] [Commented] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621013#comment-16621013
]
Robert Scholte commented on SUREFIRE-1570:
--
bq. When we use JPMS we don't create services in META-INF folder
Who says you don't need to create this file? Show me a reliable source that
says so. It looks like you're mixing up the purpose of the module descriptor
and the need for these service loader files.
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module jdk.internal.opt
> module java.management.rmi
> module jdk.management.jfr
> module javafx.swing
> module jdk.editpad
> module jdk.crypto.ec
> module jdk.javaws
> module jdk.jstatd
> module jdk.management.agent
> module javafx.graphics
> module javafx.media
> module java.rmi
> module java.prefs
> module jdk.security.jgss
> module javafx.fxml
> module java.smartcardio
> module jdk.xml.dom
> module java.xml.crypto
> module jdk.jsobject
> module jdk.jdi
> module jdk.compiler
> module java.management
> module jdk.management.cmm
> module jdk.packager.services
> module jdk.jartool
> module jdk.scripting.nashorn
> module java.security.jgss
> module jdk.localedata
> module java.desktop
> module jdk.zipfs
[jira] [Commented] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620972#comment-16620972
]
Pavel_K commented on SUREFIRE-1570:
---
No. This is not right. The way you described is old way for creating services.
But I am speaking about JPMS! When we use JPMS we don't create services in
META-INF folder. Please, read comments to this questions - there is a lot of
explanation of this
https://stackoverflow.com/questions/52314884/how-to-test-jpms-service-with-failsafe-and-junit5-without-creating-additional-te
.
The problem here is that fail-safe doesn't put the testing module on module
path.
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module jdk.internal.opt
> module java.management.rmi
> module jdk.management.jfr
> module javafx.swing
> module jdk.editpad
> module jdk.crypto.ec
> module jdk.javaws
> module jdk.jstatd
> module jdk.management.agent
> module javafx.graphics
> module javafx.media
> module java.rmi
> module java.prefs
> module jdk.security.jgss
> module javafx.fxml
> module java.smartcardio
> module jdk.xml.dom
> module java.xml.crypto
> module jdk.jsobject
> module jdk.jdi
> module jdk.compiler
> module java.management
> module
[jira] [Closed] (SUREFIRE-1570) Maven-fail-safe doesn't put testing JPMS module on module path
[
https://issues.apache.org/jira/browse/SUREFIRE-1570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SUREFIRE-1570.
Resolution: Not A Problem
Assignee: Robert Scholte
You've forgot to add the following file:
{code:java|title=src/main/resources/META-INF/services/me.pavel.mavenproject20.Service}
me.pavel.mavenproject20.ServiceImpl
{code}
After that the test is green and build succeeds
> Maven-fail-safe doesn't put testing JPMS module on module path
> --
>
> Key: SUREFIRE-1570
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1570
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.22.0
>Reporter: Pavel_K
>Assignee: Robert Scholte
>Priority: Major
> Attachments: mavenproject20.zip
>
>
> I uploaded project - mavenproject20. Run `mvn verify`. You will see the
> following:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building mavenproject20 0.1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @
> mavenproject20 ---
> [WARNING]
>
> [WARNING] * Required filename-based automodules detected. Please don't
> publish this project to a public artifact repository! *
> [WARNING]
>
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 3 source files to
> /home/Jim/NetBeansProjects/mavenproject20/target/classes
> [WARNING]
> /home/Jim/NetBeansProjects/mavenproject20/src/main/java/module-info.java:[1,8]
> module name component Mavenproject20 should avoid terminal digits
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> mavenproject20 ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /home/Jim/NetBeansProjects/mavenproject20/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @
> mavenproject20 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> /home/Jim/NetBeansProjects/mavenproject20/target/test-classes
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ mavenproject20
> ---
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ mavenproject20 ---
> [INFO] Building jar:
> /home/Jim/NetBeansProjects/mavenproject20/target/mavenproject20-0.1.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (integration-tests)
> @ mavenproject20 ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running me.pavel.mavenproject20.ServiceIT
> JDKModulePath:null
> ModuleName:null
> module jdk.unsupported
> module jdk.sctp
> module java.naming
> module java.jnlp
> module jdk.httpserver
> module java.xml
> module javafx.controls
> module java.datatransfer
> module jdk.javadoc
> module jdk.jconsole
> module java.instrument
> module jdk.packager
> module jdk.deploy
> module jdk.jfr
> module jdk.management
> module jdk.charsets
> module oracle.net
> module jdk.jdeps
> module java.sql.rowset
> module jdk.net
> module jdk.accessibility
> module jdk.attach
> module jdk.internal.le
> module jdk.snmp
> module java.base
> module jdk.plugin
> module jdk.dynalink
> module jdk.naming.rmi
> module jdk.internal.opt
> module java.management.rmi
> module jdk.management.jfr
> module javafx.swing
> module jdk.editpad
> module jdk.crypto.ec
> module jdk.javaws
> module jdk.jstatd
> module jdk.management.agent
> module javafx.graphics
> module javafx.media
> module java.rmi
> module java.prefs
> module jdk.security.jgss
> module javafx.fxml
> module java.smartcardio
> module jdk.xml.dom
> module java.xml.crypto
> module jdk.jsobject
> module jdk.jdi
> module jdk.compiler
> module java.management
> module jdk.management.cmm
> module jdk.packager.services
> module jdk.jartool
> module jdk.scripting.nashorn
> module java.security.jgss
> module jdk.localedata
> module java.desktop
> module jdk.zipfs
> module jdk.jshell
> module
[jira] [Commented] (MSHADE-300) Allow retention of module-info class by property
[ https://issues.apache.org/jira/browse/MSHADE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620943#comment-16620943 ] Robert Scholte commented on MSHADE-300: --- I think this is an acceptable option. Probably should add a small integrationtest to confirm that the parameter is picked up correctly. > Allow retention of module-info class by property > > > Key: MSHADE-300 > URL: https://issues.apache.org/jira/browse/MSHADE-300 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Rafael Winterhalter >Priority: Major > Attachments: MSHADE300.patch > > > Currently, the shader removes any module-info.class file that is found during > the shading process. This makes perfect sense as the integrity of the > module-info class file breaks as a result of the relocation and any potential > renaming. > Many library vendors that use the shade plugin do so to import minor > dependencies into their namespace. In my case, I depend on ASM and use > another Maven plugin to generate a module-info.class file which does not > require ASM and would work correctly. Unfortunately, this working > module-info.class file is filtered out by the shade plugin. > To overcome this limitation, I suggest adding a 'retainModuleInfo' property > that allows for the retention of the module-info.class file that is extracted > from the main artifact. I understand that this might be an edge case but > given the module system only being partially adopted it would help some > low-level library vendors like myself a lot if this feature would be included > in the plugin. > I have attached a patch file that implements this feature and it only > requires minimal changes in the plugin. I have also validated that this > feature works for my project (Byte Buddy). > If you could merge and release this extension, I would hope to include module > descriptors in Byte Buddy in the upcoming Java 11-compatible release. Thanks > a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MCOMPILER-362) Change default source/target option to be a bit more modern
[ https://issues.apache.org/jira/browse/MCOMPILER-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCOMPILER-362. Resolution: Won't Fix Assignee: Robert Scholte I'm going to close this as won't fix for now. If you had a look at other issues related to the value of source/target you might have seen that with maven-compiler-plugin 3.8.0 the defaults have been changed to 1.6 due to MCOMPILER-335. In short: every project should specify a source+target and shouldn't rely on the plugin default, because it is not as constant as it should be. The value for source/target are the lowest supported by the latest Java version. This way everybody can create a "Hello World" application with the minimum pom file. So once Java 12 is released, we'll upgrade this value to 1.7 For all details, please read MCOMPILER-335 first. > Change default source/target option to be a bit more modern > --- > > Key: MCOMPILER-362 > URL: https://issues.apache.org/jira/browse/MCOMPILER-362 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: theminecoder >Assignee: Robert Scholte >Priority: Trivial > > With the impending release of Java 11, I think it's about time that we update > the source/target compiler options to something that isn't (at the time of > writing) 4 major versions behind. > With the amount of libraries that require at least Java 8 and Java 8 being > the current LTS version, I would like to propose that we change the default > to be at least a minimum of Java 8, with the option to change back to the > older compiler versions like how we have to switch to Java 8 currently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure
[
https://issues.apache.org/jira/browse/MJAVADOC-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620931#comment-16620931
]
Robert Scholte commented on MJAVADOC-538:
-
Interesting, based on
https://github.com/apache/maven-javadoc-plugin/blob/master/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1504
such lines should be ignored. Seems like there's a path that doesn't use this
StringStreamConsumer
> JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc
> warning, triggers failure
> -
>
> Key: MJAVADOC-538
> URL: https://issues.apache.org/jira/browse/MJAVADOC-538
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Maven 3.5.4
> Java 1.8.0_181
>Reporter: Yoann Rodière
>Priority: Major
>
> When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is
> defined, every JVM that starts will output a message to inform users of these
> options being picked up:
> {noformat}
> $ export JAVA_TOOL_OPTIONS=-Dfoo
> $ java -version
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
> Apparently this message cannot be suppressed, that's on purpose an won't
> change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
>
> Unfortunately, this message seems to be interpreted by the
> maven-javadoc-plugin as a warning:
> {noformat}
> [INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @
> hibernate-search-util-internal-common ---
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc'
> has not been previously called for the module:
> 'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
> Trying to invoke it...
> [WARN] Maven will be executed in interactive mode, but no input stream has
> been configured for this MavenInvoker instance.
> Picked up JAVA_TOOL_OPTIONS: -Dfoo
> [WARNING] Creating fake javadoc directory to prevent repeated invocations:
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
> [ERROR] Error fetching link:
> /home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
> Ignored it.
> [WARNING] Javadoc Warnings
> [WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
> {noformat}
> (see the last line, the message appears in the list of warnings)
> No big deal... until you enable the
> [failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
> option. Then the whole build will fail just because some JVM detected an
> environment variable...
> I couldn't find any workaround, except disabling the {{failOnWarnings}}
> options, but that's more a surrender than a workaround.
> Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not
> exactly an exotic use case, especially on Continuous Integration platforms.
> [Travis CI uses {{_JAVA_OPTIONS}}
> |https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added]
> to set JVM memory limits in its containerized environments, and [the Jenkins
> CI Pipeline Maven plugin uses
> {{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
> to pass options to Maven processes transparently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-278) Incremental build does not track inter-module dependencies.
[ https://issues.apache.org/jira/browse/MCOMPILER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620925#comment-16620925 ] Robert Scholte commented on MCOMPILER-278: -- So if I understand correctly this is about a dependency change, not a module change. The sampleProject is confusing, it should be 2 independent projects. I'm actually kind of surprised this wasn't implemented yet. I think this is something that should be solved in the [maven-shared-incremental|https://maven.apache.org/shared/maven-shared-incremental]. The date of the jars should be compared to some other date, I think using the date of the target-directory should work. Since [~olamy] wrote maven-shared-incremental: WDYT? Add this to the shared library? > Incremental build does not track inter-module dependencies. > --- > > Key: MCOMPILER-278 > URL: https://issues.apache.org/jira/browse/MCOMPILER-278 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Michael Zav'yalov >Priority: Major > Attachments: maven-compiler-checksum.patch, > maven-compiler-plugin-3.1.patch, sampleProject.zip > > > When useIncrementalCompilation=true the plugin actually assumes that this > incremental compilation is supported by compiler itself (I state it because > of all source files are always sent to compiler). > But plugin provides an additional optimization - it can detect that there are > no changes at all, so calling compiler can be skipped. It is especially > critical for javac that does not support incremental build since 1.3. > Unfortunately, plugin ignores claspath dependencies that are not directory, > i.e. - jars, so when dependent jar is modified (in incompatible way) - our > project is not re-compiled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MENFORCER-318) Upgrading maven-enforcer-plugin from 1.4 to 1.4.1 or higher breaks maven-assembly-plugin
Marcel Schutte created MENFORCER-318:
Summary: Upgrading maven-enforcer-plugin from 1.4 to 1.4.1 or
higher breaks maven-assembly-plugin
Key: MENFORCER-318
URL: https://issues.apache.org/jira/browse/MENFORCER-318
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Plugin
Affects Versions: 3.0.0-M2, 3.0.0-M1, 1.4.1
Environment: Maven 3.3.9
Reporter: Marcel Schutte
Attachments: extjars.xml, pom.xml
Upgrading maven-enforcer-plugin to a version above 1.4 causes
maven-assembly-plugin to generate the following error:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single (assemble) on
project extjars: Execution assemble of goal
org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single (assemble) on
project extjars: Execution assemble of goal
org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution assemble
of goal org.apache.maven.plugins:maven-assembly-plugin:3.1.0:single failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver$DefaultFileInfo.isFile(AssemblyProxyArchiver.java:1025)
at
org.apache.maven.plugins.assembly.filter.ComponentsXmlArchiverFileFilter.isSelected(ComponentsXmlArchiverFileFilter.java:179)
at
org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.acceptFile(AssemblyProxyArchiver.java:794)
at
org.apache.maven.plugins.assembly.archive.archiver.AssemblyProxyArchiver.addFile(AssemblyProxyArchiver.java:396)
at
org.apache.maven.plugins.assembly.archive.task.AddArtifactTask.asFile(AddArtifactTask.java:171)
at
org.apache.maven.plugins.assembly.archive.task.AddArtifactTask.execute(AddArtifactTask.java:132)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addNormalArtifact(AddDependencySetsTask.java:263)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:175)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:120)
at
org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:104)
at
org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
at
org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:478)
at
org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:61)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible
[GitHub] mkarg opened a new pull request #5: Parameter `fileMapper` for unpack path rewriting
mkarg opened a new pull request #5: Parameter `fileMapper` for unpack path rewriting URL: https://github.com/apache/maven-dependency-plugin/pull/5 The new parameter `fileMapper` (default: `null`) can be set to an implementation of the `org.codehaus.plexus.components.io.filemappers.FileMapper` interface to rewrite the target path of each unpacked file. This is useful in case prefixes of target files names within the target directory shall be added (using `PrefixFileMapper`), changed or omitted (using `RegExpFileMapper`). **This PR is dependent of [PR #100](https://github.com/codehaus-plexus/plexus-archiver/pull/100) of *Plexus Archiver*.** This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MJAVADOC-538) JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message detected as javadoc warning, triggers failure
Yoann Rodière created MJAVADOC-538:
--
Summary: JVM "JAVA_TOOL_OPTIONS" or "_JAVA_OPTIONS" message
detected as javadoc warning, triggers failure
Key: MJAVADOC-538
URL: https://issues.apache.org/jira/browse/MJAVADOC-538
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Environment: Maven 3.5.4
Java 1.8.0_181
Reporter: Yoann Rodière
When an environment variable {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is
defined, every JVM that starts will output a message to inform users of these
options being picked up:
{noformat}
$ export JAVA_TOOL_OPTIONS=-Dfoo
$ java -version
Picked up JAVA_TOOL_OPTIONS: -Dfoo
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode){noformat}
Apparently this message cannot be suppressed, that's on purpose an won't
change: [https://bugs.openjdk.java.net/browse/JDK-8039152]
Unfortunately, this message seems to be interpreted by the maven-javadoc-plugin
as a warning:
{noformat}
[INFO] --- maven-javadoc-plugin:3.0.1:javadoc-no-fork (generate-javadoc) @
hibernate-search-util-internal-common ---
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc'
has not been previously called for the module:
'org.hibernate.search:hibernate-search-util-internal-test:jar:6.0.0-SNAPSHOT'.
Trying to invoke it...
[WARN] Maven will be executed in interactive mode, but no input stream has been
configured for this MavenInvoker instance.
Picked up JAVA_TOOL_OPTIONS: -Dfoo
[WARNING] Creating fake javadoc directory to prevent repeated invocations:
/home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs
[ERROR] Error fetching link:
/home/yrodiere/workspaces/main/hibernate-search-parent/util/internal/test/target/site/apidocs/package-list.
Ignored it.
[WARNING] Javadoc Warnings
[WARNING] Picked up JAVA_TOOL_OPTIONS: -Dfoo
{noformat}
(see the last line, the message appears in the list of warnings)
No big deal... until you enable the
[failOnWarnings|https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-no-fork-mojo.html#failOnWarnings]
option. Then the whole build will fail just because some JVM detected an
environment variable...
I couldn't find any workaround, except disabling the {{failOnWarnings}}
options, but that's more a surrender than a workaround.
Note that the definition of {{_JAVA_OPTIONS}} or {{JAVA_TOOL_OPTIONS}} is not
exactly an exotic use case, especially on Continuous Integration platforms.
[Travis CI uses {{_JAVA_OPTIONS}}
|https://docs.travis-ci.com/user/build-environment-updates/2017-09-06/#added]
to set JVM memory limits in its containerized environments, and [the Jenkins CI
Pipeline Maven plugin uses
{{JAVA_TOOL_OPTIONS}}|https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-WhydoIseemessages%22[WARNING]PickedupJAVA_TOOL_OPTIONS...%22inthebuildlogs?]
to pass options to Maven processes transparently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] s50600822 closed pull request #180: better performant for some Collection operations
s50600822 closed pull request #180: better performant for some Collection
operations
URL: https://github.com/apache/maven/pull/180
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/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
b/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
index fb99593c90..9bcc384234 100644
--- a/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
+++ b/maven-compat/src/main/java/org/apache/maven/project/ModelUtils.java
@@ -313,12 +313,8 @@ private static void mergePluginExecutionDefinitions(
PluginExecution child, Plug
public static List mergeRepositoryLists( List
dominant, List recessive )
{
-List repositories = new ArrayList<>();
-for ( Repository repository : dominant )
-{
-repositories.add( repository );
-}
+List repositories = new ArrayList<>( dominant );
for ( Repository repository : recessive )
{
diff --git
a/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
b/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
index b6e3c0c96e..f980f5ab47 100644
---
a/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
+++
b/maven-compat/src/main/java/org/apache/maven/repository/metadata/DefaultClasspathTransformation.java
@@ -139,7 +139,7 @@ protected void visit( MetadataGraphVertex node ) // ,
String version, String art
if ( exits != null && exits.size() > 0 )
{
-MetadataGraphEdge[] sortedExits = exits.toArray( new
MetadataGraphEdge[exits.size()] );
+MetadataGraphEdge[] sortedExits = exits.toArray( new
MetadataGraphEdge[0] );
Arrays.sort( sortedExits
,
new Comparator()
diff --git
a/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
b/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
index 2b3108a47f..d1c69fd607 100644
---
a/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
+++
b/maven-core/src/main/java/org/apache/maven/project/ProjectModelResolver.java
@@ -19,14 +19,6 @@
* under the License.
*/
-import java.io.File;
-import java.util.ArrayList;
-import java.util.Collections;
-import java.util.HashSet;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Set;
-
import org.apache.maven.model.Dependency;
import org.apache.maven.model.Parent;
import org.apache.maven.model.Repository;
@@ -49,6 +41,14 @@
import org.eclipse.aether.resolution.VersionRangeResolutionException;
import org.eclipse.aether.resolution.VersionRangeResult;
+import java.io.File;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Set;
+
/**
* A model resolver to assist building of projects. This resolver gives
priority to those repositories that have been
* declared in the POM.
@@ -91,9 +91,7 @@ public ProjectModelResolver( RepositorySystemSession session,
RequestTrace trace
this.resolver = resolver;
this.remoteRepositoryManager = remoteRepositoryManager;
this.pomRepositories = new ArrayList<>();
-List externalRepositories = new ArrayList<>();
-externalRepositories.addAll( repositories );
-this.externalRepositories = Collections.unmodifiableList(
externalRepositories );
+this.externalRepositories = Collections.unmodifiableList( new
ArrayList<>( repositories ) );
this.repositories = new ArrayList<>();
this.repositories.addAll( externalRepositories );
this.repositoryMerging = repositoryMerging;
diff --git
a/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
b/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
index 40db38994d..1591573f62 100644
---
a/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
+++
b/maven-core/src/main/java/org/apache/maven/toolchain/DefaultToolchainManagerPrivate.java
@@ -69,7 +69,7 @@
}
}
-return toRet.toArray( new ToolchainPrivate[toRet.size()] );
+return toRet.toArray( new ToolchainPrivate[0] );
}
@Override
diff --git
a/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
b/maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/MojoExecutorStub.java
index a8572ffc9f..8a6580b699 100644
---
[jira] [Created] (MCOMPILER-362) Change default source/target option to be a bit more modern
theminecoder created MCOMPILER-362: -- Summary: Change default source/target option to be a bit more modern Key: MCOMPILER-362 URL: https://issues.apache.org/jira/browse/MCOMPILER-362 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: theminecoder With the impending release of Java 11, I think it's about time that we update the source/target compiler options to something that isn't (at the time of writing) 4 major versions behind. With the amount of libraries that require at least Java 8 and Java 8 being the current LTS version, I would like to propose that we change the default to be at least a minimum of Java 8, with the option to change back to the older compiler versions like how we have to switch to Java 8 currently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-278) Incremental build does not track inter-module dependencies.
[ https://issues.apache.org/jira/browse/MCOMPILER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620295#comment-16620295 ] Liwae Lamaa commented on MCOMPILER-278: --- Hi [~rfscholte], what do you think? > Incremental build does not track inter-module dependencies. > --- > > Key: MCOMPILER-278 > URL: https://issues.apache.org/jira/browse/MCOMPILER-278 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.1 >Reporter: Michael Zav'yalov >Priority: Major > Attachments: maven-compiler-checksum.patch, > maven-compiler-plugin-3.1.patch, sampleProject.zip > > > When useIncrementalCompilation=true the plugin actually assumes that this > incremental compilation is supported by compiler itself (I state it because > of all source files are always sent to compiler). > But plugin provides an additional optimization - it can detect that there are > no changes at all, so calling compiler can be skipped. It is especially > critical for javac that does not support incremental build since 1.3. > Unfortunately, plugin ignores claspath dependencies that are not directory, > i.e. - jars, so when dependent jar is modified (in incompatible way) - our > project is not re-compiled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHADE-300) Allow retention of module-info class by property
[ https://issues.apache.org/jira/browse/MSHADE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Winterhalter updated MSHADE-300: --- Attachment: MSHADE300.patch > Allow retention of module-info class by property > > > Key: MSHADE-300 > URL: https://issues.apache.org/jira/browse/MSHADE-300 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Rafael Winterhalter >Priority: Major > Attachments: MSHADE300.patch > > > Currently, the shader removes any module-info.class file that is found during > the shading process. This makes perfect sense as the integrity of the > module-info class file breaks as a result of the relocation and any potential > renaming. > Many library vendors that use the shade plugin do so to import minor > dependencies into their namespace. In my case, I depend on ASM and use > another Maven plugin to generate a module-info.class file which does not > require ASM and would work correctly. Unfortunately, this working > module-info.class file is filtered out by the shade plugin. > To overcome this limitation, I suggest adding a 'retainModuleInfo' property > that allows for the retention of the module-info.class file that is extracted > from the main artifact. I understand that this might be an edge case but > given the module system only being partially adopted it would help some > low-level library vendors like myself a lot if this feature would be included > in the plugin. > I have attached a patch file that implements this feature and it only > requires minimal changes in the plugin. I have also validated that this > feature works for my project (Byte Buddy). > If you could merge and release this extension, I would hope to include module > descriptors in Byte Buddy in the upcoming Java 11-compatible release. Thanks > a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSHADE-300) Allow retention of module-info class by property
Rafael Winterhalter created MSHADE-300: -- Summary: Allow retention of module-info class by property Key: MSHADE-300 URL: https://issues.apache.org/jira/browse/MSHADE-300 Project: Maven Shade Plugin Issue Type: New Feature Affects Versions: 3.2.0 Reporter: Rafael Winterhalter Currently, the shader removes any module-info.class file that is found during the shading process. This makes perfect sense as the integrity of the module-info class file breaks as a result of the relocation and any potential renaming. Many library vendors that use the shade plugin do so to import minor dependencies into their namespace. In my case, I depend on ASM and use another Maven plugin to generate a module-info.class file which does not require ASM and would work correctly. Unfortunately, this working module-info.class file is filtered out by the shade plugin. To overcome this limitation, I suggest adding a 'retainModuleInfo' property that allows for the retention of the module-info.class file that is extracted from the main artifact. I understand that this might be an edge case but given the module system only being partially adopted it would help some low-level library vendors like myself a lot if this feature would be included in the plugin. I have attached a patch file that implements this feature and it only requires minimal changes in the plugin. I have also validated that this feature works for my project (Byte Buddy). If you could merge and release this extension, I would hope to include module descriptors in Byte Buddy in the upcoming Java 11-compatible release. Thanks a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5870) Effective pom should not inherit SCM
[ https://issues.apache.org/jira/browse/MNG-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620147#comment-16620147 ] Hervé Boutemy commented on MNG-5870: like that, why not I'm convinced that we should not need such a difference between build and consumer pom if maven-scm urls for DVCS were powerful enough But at least for web view urls, having this separation between build and consumer makes sense, even if Jenkins experience for creating a web link to scm view is just a nightmare given the huge diversity of systems... we really need to work on this build vs consumer POM > Effective pom should not inherit SCM > > > Key: MNG-5870 > URL: https://issues.apache.org/jira/browse/MNG-5870 > Project: Maven > Issue Type: Improvement > Components: core, Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > > Up until Maven 3.3.7 if a pom didn't specify the scm section, it would be > inherited and extended with the artifactId *by default*. This mechanism could > work for a couple of SCMs like svn and cvs, but for most it doesn't. > This kind of scm specific logic of extending the connection or URL doesn't > belong in Maven core. > Instead we should say that scm marks this project as a valid release root. > The source repository page (mpir) should ask a specific Scm class for > handling connections and urls in case of modules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
