[jira] [Commented] (MPLUGIN-312) maven-plugin-tools-annotations visitors fail scanning java8 annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439728#comment-15439728
]
Hudson commented on MPLUGIN-312:
SUCCESS: Integrated in Jenkins build maven-plugin-tools #267 (See
[https://builds.apache.org/job/maven-plugin-tools/267/])
[MPLUGIN-312] maven-plugin-tools-annotations visitors fail scanning java8
annotations (rfscholte: [http://svn.apache.org/viewvc/?view=rev=1757909])
* (edit) maven-plugin-tools-annotations/pom.xml
* (edit)
maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/visitors/MojoAnnotationVisitor.java
* (edit)
maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/visitors/MojoClassVisitor.java
* (edit)
maven-plugin-tools-annotations/src/main/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/visitors/MojoFieldVisitor.java
* (edit)
maven-plugin-tools-annotations/src/test/java/org/apache/maven/tools/plugin/extractor/annotations/scanner/DefaultMojoAnnotationsScannerTest.java
* (add) maven-plugin-tools-annotations/src/test/resources/java8-annotations.jar
> maven-plugin-tools-annotations visitors fail scanning java8 annotations
> ---
>
> Key: MPLUGIN-312
> URL: https://issues.apache.org/jira/browse/MPLUGIN-312
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Affects Versions: 3.4
>Reporter: Yegor Borovikov
>Assignee: Robert Scholte
> Fix For: 3.5
>
> Attachments: MPLUGIN-312-maven-plugin-tools-annotations.patch,
> java6-plugin.zip
>
>
> Custom (Java 6) Maven plugin (relying on Java 5 annotations to generate the
> plugin descriptor file) with dependencies that have Java 8 classes (not
> necessarily referenced by plugin code - just present in the jars) which use
> Java 8 type-use or type-parameter annotations fails on `generate:descriptor`
> goal:
> {noformat}
> $ mvn plugin:descriptor -e
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building java6-plugin 0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-plugin-plugin:3.4:descriptor (default-cli) @ java6-plugin ---
> [INFO] Using 'UTF-8' encoding to read mojo metadata.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.022 s
> [INFO] Finished at: 2016-08-25T17:14:54-07:00
> [INFO] Final Memory: 10M/245M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor (default-cli) on
> project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> RuntimeException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor
> (default-cli) on project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (MPLUGIN-312) maven-plugin-tools-annotations visitors fail scanning java8 annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439708#comment-15439708
]
Yegor Borovikov commented on MPLUGIN-312:
-
[~rfscholte], thank you for quick resolution!
> maven-plugin-tools-annotations visitors fail scanning java8 annotations
> ---
>
> Key: MPLUGIN-312
> URL: https://issues.apache.org/jira/browse/MPLUGIN-312
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Affects Versions: 3.4
>Reporter: Yegor Borovikov
>Assignee: Robert Scholte
> Fix For: 3.5
>
> Attachments: MPLUGIN-312-maven-plugin-tools-annotations.patch,
> java6-plugin.zip
>
>
> Custom (Java 6) Maven plugin (relying on Java 5 annotations to generate the
> plugin descriptor file) with dependencies that have Java 8 classes (not
> necessarily referenced by plugin code - just present in the jars) which use
> Java 8 type-use or type-parameter annotations fails on `generate:descriptor`
> goal:
> {noformat}
> $ mvn plugin:descriptor -e
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building java6-plugin 0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-plugin-plugin:3.4:descriptor (default-cli) @ java6-plugin ---
> [INFO] Using 'UTF-8' encoding to read mojo metadata.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.022 s
> [INFO] Finished at: 2016-08-25T17:14:54-07:00
> [INFO] Final Memory: 10M/245M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor (default-cli) on
> project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> RuntimeException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor
> (default-cli) on project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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
> default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
>
[jira] [Commented] (MPLUGIN-290) Version 3.4 fails to parse enums with Regex patterns
[
https://issues.apache.org/jira/browse/MPLUGIN-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439659#comment-15439659
]
Robert Scholte commented on MPLUGIN-290:
NEeds to be fixed at [QDox|https://github.com/paul-hammant/qdox]
> Version 3.4 fails to parse enums with Regex patterns
>
>
> Key: MPLUGIN-290
> URL: https://issues.apache.org/jira/browse/MPLUGIN-290
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.4
> Environment: Windows
>Reporter: Richard Birenheide
> Attachments: Test.java
>
>
> When having the file attached as Java source file, maven-plugin-plugin fails
> with the following error messages below.
> Version 3.4 fails to parse the file, version 3.3 works fine.
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor
> (default-descriptor) on proje
> ct extensionPointDocu-maven-plugin: Execution default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.
> 4:descriptor failed: syntax error @[7,22] in
> file:/D:/D035816/repos/git-repos/fiori_extension_point_documenter/extension
> PointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plu
> gin:3.4:descriptor (default-descriptor) on project
> extensionPointDocu-maven-plugin: Execution default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed: syntax
> error @[7,22] in file:/D:/D035816/repos/git-
> repos/fiori_extension_point_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-descriptor of goal org.apache.maven.plugi
> ns:maven-plugin-plugin:3.4:descriptor failed: syntax error @[7,22] in
> file:/D:/D035816/repos/git-repos/fiori_extension_p
> oint_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: com.thoughtworks.qdox.parser.ParseException: syntax error @[7,22]
> in file:/D:/D035816/repos/git-repos/fiori_e
> xtension_point_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
> at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1683)
> at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1805)
> at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:1664)
> at
> com.thoughtworks.qdox.library.SourceLibrary.parse(SourceLibrary.java:210)
> at
> com.thoughtworks.qdox.library.SourceLibrary.parse(SourceLibrary.java:186)
>
[jira] [Updated] (MPLUGIN-290) Version 3.4 fails to parse enums with Regex patterns
[
https://issues.apache.org/jira/browse/MPLUGIN-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MPLUGIN-290:
---
Description:
When having the file attached as Java source file, maven-plugin-plugin fails
with the following error messages below.
Version 3.4 fails to parse the file, version 3.3 works fine.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor
(default-descriptor) on proje
ct extensionPointDocu-maven-plugin: Execution default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.
4:descriptor failed: syntax error @[7,22] in
file:/D:/D035816/repos/git-repos/fiori_extension_point_documenter/extension
PointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java -> [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-plugin-plu
gin:3.4:descriptor (default-descriptor) on project
extensionPointDocu-maven-plugin: Execution default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed: syntax
error @[7,22] in file:/D:/D035816/repos/git-
repos/fiori_extension_point_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-descriptor of goal org.apache.maven.plugi
ns:maven-plugin-plugin:3.4:descriptor failed: syntax error @[7,22] in
file:/D:/D035816/repos/git-repos/fiori_extension_p
oint_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: com.thoughtworks.qdox.parser.ParseException: syntax error @[7,22] in
file:/D:/D035816/repos/git-repos/fiori_e
xtension_point_documenter/extensionPointDocu-maven-plugin/src/main/java/com/sap/suite/arch/test/Test.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:1683)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:1805)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:1664)
at
com.thoughtworks.qdox.library.SourceLibrary.parse(SourceLibrary.java:210)
at
com.thoughtworks.qdox.library.SourceLibrary.parse(SourceLibrary.java:186)
at
com.thoughtworks.qdox.library.SourceLibrary.addSource(SourceLibrary.java:141)
at
com.thoughtworks.qdox.library.SortedClassLibraryBuilder.addSource(SortedClassLibraryBuilder.java:173)
at
com.thoughtworks.qdox.JavaProjectBuilder.addSource(JavaProjectBuilder.java:150)
at
com.thoughtworks.qdox.JavaProjectBuilder$2.visitFile(JavaProjectBuilder.java:222)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:103)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:91)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:91)
at
[jira] [Closed] (MPLUGIN-311) Goal "plugin:report": System Requirements -> Minimum Maven version is not correctly extracted from effective pom
[
https://issues.apache.org/jira/browse/MPLUGIN-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPLUGIN-311.
--
Assignee: Robert Scholte
> Goal "plugin:report": System Requirements -> Minimum Maven version is not
> correctly extracted from effective pom
>
>
> Key: MPLUGIN-311
> URL: https://issues.apache.org/jira/browse/MPLUGIN-311
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.4
>Reporter: Konrad Windszus
>Assignee: Robert Scholte
>
> Currently the minimum Maven version being exposed in {{plugin-info.html}}
> through the goal {{report}} only seems to be extracted from the current
> {{prerequisites->maven}} element in the current pom.xml. In case this is set
> in some parent pom, it falls back to the default of version {{2.0}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MPLUGIN-312) maven-plugin-tools-annotations visitors fail scanning java8 annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MPLUGIN-312.
--
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.5
Fixed in [r1757909|http://svn.apache.org/viewvc?rev=1757909=rev]
Thanks for the patch!
> maven-plugin-tools-annotations visitors fail scanning java8 annotations
> ---
>
> Key: MPLUGIN-312
> URL: https://issues.apache.org/jira/browse/MPLUGIN-312
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Affects Versions: 3.4
>Reporter: Yegor Borovikov
>Assignee: Robert Scholte
> Fix For: 3.5
>
> Attachments: MPLUGIN-312-maven-plugin-tools-annotations.patch,
> java6-plugin.zip
>
>
> Custom (Java 6) Maven plugin (relying on Java 5 annotations to generate the
> plugin descriptor file) with dependencies that have Java 8 classes (not
> necessarily referenced by plugin code - just present in the jars) which use
> Java 8 type-use or type-parameter annotations fails on `generate:descriptor`
> goal:
> {noformat}
> $ mvn plugin:descriptor -e
> [INFO] Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building java6-plugin 0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-plugin-plugin:3.4:descriptor (default-cli) @ java6-plugin ---
> [INFO] Using 'UTF-8' encoding to read mojo metadata.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.022 s
> [INFO] Finished at: 2016-08-25T17:14:54-07:00
> [INFO] Final Memory: 10M/245M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor (default-cli) on
> project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> RuntimeException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor
> (default-cli) on project java6-plugin: Execution default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 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:862)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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
> default-cli of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.4:descriptor failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
>
[jira] [Created] (MSHARED-581) Filtered resource copyFiles fails on pre-existing symlink
Steven Schlansker created MSHARED-581:
-
Summary: Filtered resource copyFiles fails on pre-existing symlink
Key: MSHARED-581
URL: https://issues.apache.org/jira/browse/MSHARED-581
Project: Maven Shared Components
Issue Type: Bug
Components: maven-shared-utils
Affects Versions: maven-filtering-3.1.1, maven-shared-utils-3.0.0
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.8.0_77, vendor: Oracle Corporation
Java home: /Users/steven/.jabba/jdk/1.8.77/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
Reporter: Steven Schlansker
I have a file shared between multiple projects via symlink:
{code}
-rw-r--r-- 1 steven staff 149 Mar 30 16:56
client/src/test/resources/simplelogger.properties
lrwxr-xr-x 1 steven staff 64 Oct 16 2014
integration-tests/jersey-client/src/test/resources/simplelogger.properties ->
../../../../../client/src/test/resources/simplelogger.properties
lrwxr-xr-x 1 steven staff 64 Oct 16 2014
integration-tests/resteasy-client/src/test/resources/simplelogger.properties ->
../../../../../client/src/test/resources/simplelogger.properties
{code}
This works fine from a clean build, but on an incremental build, it fails:
{code}
Caused by: org.apache.maven.plugin.MojoExecutionException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:348)
at
org.apache.maven.plugins.resources.TestResourcesMojo.execute(TestResourcesMojo.java:75)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.apache.maven.shared.filtering.MavenFilteringException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:128)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:232)
at
org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:342)
... 23 more
Caused by: java.nio.file.FileAlreadyExistsException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.createSymbolicLink(UnixFileSystemProvider.java:457)
at java.nio.file.Files.createSymbolicLink(Files.java:1043)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.shared.utils.io.Java7Support.createSymbolicLink(Java7Support.java:176)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:821)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1939)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:121)
... 25 more
{code}
Perhaps {{FileUtils.copyFile}} should not attempt to copy over an existing
symlink? It should leave it be if the target is the same, otherwise unlink it
first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439272#comment-15439272
]
Louis Lecaroz edited comment on MNG-5199 at 8/26/16 3:35 PM:
-
Yes sure Jason and Karel.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
was (Author: llecaroz):
Yes sure Jason.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://issues.apache.org/jira/browse/MNG-5199
> Project: Maven
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439272#comment-15439272
]
Louis Lecaroz commented on MNG-5199:
Yes sure Jason.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://issues.apache.org/jira/browse/MNG-5199
> Project: Maven
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439186#comment-15439186
]
Louis Lecaroz edited comment on MNG-5199 at 8/26/16 2:59 PM:
-
In CI environments, also having projects using Maven third parties plugins or
surefire, not taking care of a project settings.xml & in consequence the global
settings.xml is taken in account in place. But because some settings depends on
the CI build & multiple CI builds are running on the same slave. the global
settings.xml must be part of the build directory instead of the maven
installation dir. So the org.apache.maven.global-settings will be useful for
isolating global settings.xml read by third parties maven plugins in each
corresponding build.
The goal of such variables (org.apache.maven.user-settings and
org.apache.maven.global-settings properties) is to have only fixed file (like
binaries for ex...) in M2_HOME (or MAVEN_HOME) & all configuration files like
toolchain, settings.xml set thru the MAVEN_OPTS variable to fully isolate each
maven contexts in each build
Other reference link:
http://blog.vanpeerdevelopment.be/2013/12/26/maven3-and-org.apache.maven.user-settings/
was (Author: llecaroz):
In CI environments, also having projects using Maven third parties plugins or
surefire, not taking care of a project settings.xml & in consequence the global
settings.xml is taken in account in place. But because some settings depends on
the CI build & multiple CI builds are running on the same slave. the global
settings.xml must be part of the build directory instead of the maven
installation dir. So the org.apache.maven.global-settings will be useful for
isolating global settings.xml read by third parties maven plugins in each
corresponding build.
The goal of such variables (org.apache.maven.user-settings and
org.apache.maven.global-settings properties) is to have only fixed file (like
binaries for ex...) in M2_HOME (or MAVEN_HOME) & all configuration files like
toolchain, settings.xml set thru the MAVEN_OPTS variable to fully isolate each
maven contexts in each build
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://issues.apache.org/jira/browse/MNG-5199
> Project: Maven
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439186#comment-15439186
]
Louis Lecaroz commented on MNG-5199:
In CI environments, also having projects using Maven third parties plugins or
surefire, not taking care of a project settings.xml & in consequence the global
settings.xml is taken in account in place. But because some settings depends on
the CI build & multiple CI builds are running on the same slave. the global
settings.xml must be part of the build directory instead of the maven
installation dir. So the org.apache.maven.global-settings will be useful for
isolating global settings.xml read by third parties maven plugins in each
corresponding build.
The goal of such variables (org.apache.maven.user-settings and
org.apache.maven.global-settings properties) is to have only fixed file (like
binaries for ex...) in M2_HOME (or MAVEN_HOME) & all configuration files like
toolchain, settings.xml set thru the MAVEN_OPTS variable to fully isolate each
maven contexts in each build
> Return back org.apache.maven.user-settings and
> org.apache.maven.global-settings properties
> --
>
> Key: MNG-5199
> URL: https://issues.apache.org/jira/browse/MNG-5199
> Project: Maven
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 3.0.3
>Reporter: Karel Piwko
>
> According to discussion at
> http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
> I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned
> process. If the test in spawned process want to for example access remote
> repository defined in settings.xml, user has to specify settings.xml path in
> the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated
> to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MINSTALL-126) localRepositoryPath for install like for install-file
[ https://issues.apache.org/jira/browse/MINSTALL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439119#comment-15439119 ] Michael Vorburger commented on MINSTALL-126: Yes Karaf only updates Maven based URLs and Maven SNAPSHOTs, and that's exactly what this is for; a proposed new option to be able to install artifacts into an additional (!) local Maven repository. I use this regularly (we have it in https://github.com/opendaylight/odlparent/blob/master/odlparent-lite/pom.xml#L273). Would you like to elaborate in more details on what you mean by "you can use a file url or snapshots" - where? (Using maven-deploy-plugin (with a file:// URL parameter) instead of the maven-install-plugin in this context is no good, because deploy adds a unique time stamp to JAR file names (and its uniqueVersion option appears to be broken; see also issues MDEPLOY-44 and MDEPLOY-211).) BTW: I like my blog! You don't? Improvement Issues (without Fix Version) are perfectly fine for things like this IMHO. If you are the (sole?) current maintainer of maven-install-plugin, you are free to close issues where people try to contribute possible enhancements, of course. (To subscribe to mailing lists all over the universe to post an occasional suggestion like this, is too much email traffic overhead.) > localRepositoryPath for install like for install-file > - > > Key: MINSTALL-126 > URL: https://issues.apache.org/jira/browse/MINSTALL-126 > Project: Maven Install Plugin > Issue Type: Improvement >Reporter: Michael Vorburger > > I believe there are real world use cases where to have a localRepositoryPath > available for maven-install-plugin's install goal like it currently is for > the install-file goal would be useful. > http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html is a > Blog post I wrote with some background about why this would be useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+
[ https://issues.apache.org/jira/browse/WAGON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15438862#comment-15438862 ] Christian Kibsgaard Lunde edited comment on WAGON-405 at 8/26/16 12:22 PM: --- I also just wasted a whole day trying to figure out why the example in the documentation for preemptive authentication doesn't work, The documentation really needs to get updated! was (Author: christian.lu...@vegvesen.no): I also just wasted a whole day trying to figure out why the example i the documentation for preemptive authentication doesn't work, The documentation really needs to get updated! > Preemptive authentication still not working with Maven 3.0.4+ > - > > Key: WAGON-405 > URL: https://issues.apache.org/jira/browse/WAGON-405 > Project: Maven Wagon > Issue Type: Bug >Reporter: Konrad Windszus > Attachments: WAGON-405-MVN3.1.1.log > > > Although by default the preemptive authentication should work now with Maven > 3.0.4, a wireshare dump exposes, that each request for downloading a new > dependency does not initially come with the authentication header. Only after > Nexus replied with a 401 the right credentials are set in the authentication > header. According to [1], since Maven 3.0.4 the default HTTP wagon uses > preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 > it does not work. > [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 > [2] - > http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+
[ https://issues.apache.org/jira/browse/WAGON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15438862#comment-15438862 ] Christian Kibsgaard Lunde commented on WAGON-405: - I also just wasted a whole day trying to figure out why the example i the documentation for preemptive authentication doesn't work, The documentation really needs to get updated! > Preemptive authentication still not working with Maven 3.0.4+ > - > > Key: WAGON-405 > URL: https://issues.apache.org/jira/browse/WAGON-405 > Project: Maven Wagon > Issue Type: Bug >Reporter: Konrad Windszus > Attachments: WAGON-405-MVN3.1.1.log > > > Although by default the preemptive authentication should work now with Maven > 3.0.4, a wireshare dump exposes, that each request for downloading a new > dependency does not initially come with the authentication header. Only after > Nexus replied with a 401 the right credentials are set in the authentication > header. According to [1], since Maven 3.0.4 the default HTTP wagon uses > preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 > it does not work. > [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 > [2] - > http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MCOMPILER-275) Handle separate compilation of module-info.java
[
https://issues.apache.org/jira/browse/MCOMPILER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-275:
-
Description:
When you want to add a module-info.java file to your project AND want your code
to be compatible with older java version, then you need to call {{javac}} twice.
To prevent all kinds of magic for selecting the right files to compile with the
right version of Java it is probably better to just have a separate folder for
it, e.g. {{src/main/jigsaw}}. I'd prefer to call it 'jigsaw' instead of java9,
so it'll still makes sense once we're at java16
On the jigsaw mailinglist they actually expect the module-info file to be in
the {{src/main/java}} as well. Intuition of users might indeed be to simply put
it there and let Maven handle it. That should be possible, but it also depends
if IDEs can handle this too.
was:
When you want to add a module-info.java file to your project AND want your code
to be compatible with older java version, then you need to call {{javac}} twice.
To prevent all kinds of magic for selecting the right files to compile with the
right version of Java it is probably better to just have a separate folder for
it. I'd prefer to call it 'jigsaw' instead of java9, so it'll still makes sense
once we're at java16
> Handle separate compilation of module-info.java
> ---
>
> Key: MCOMPILER-275
> URL: https://issues.apache.org/jira/browse/MCOMPILER-275
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: Robert Scholte
>
> When you want to add a module-info.java file to your project AND want your
> code to be compatible with older java version, then you need to call
> {{javac}} twice.
> To prevent all kinds of magic for selecting the right files to compile with
> the right version of Java it is probably better to just have a separate
> folder for it, e.g. {{src/main/jigsaw}}. I'd prefer to call it 'jigsaw'
> instead of java9, so it'll still makes sense once we're at java16
> On the jigsaw mailinglist they actually expect the module-info file to be in
> the {{src/main/java}} as well. Intuition of users might indeed be to simply
> put it there and let Maven handle it. That should be possible, but it also
> depends if IDEs can handle this too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MCOMPILER-275) Handle separate compilation of module-info.java
[
https://issues.apache.org/jira/browse/MCOMPILER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-275:
-
Summary: Handle separate compilation of module-info.java (was: Introduce
src/main/jigsaw folder)
> Handle separate compilation of module-info.java
> ---
>
> Key: MCOMPILER-275
> URL: https://issues.apache.org/jira/browse/MCOMPILER-275
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Reporter: Robert Scholte
>
> When you want to add a module-info.java file to your project AND want your
> code to be compatible with older java version, then you need to call
> {{javac}} twice.
> To prevent all kinds of magic for selecting the right files to compile with
> the right version of Java it is probably better to just have a separate
> folder for it. I'd prefer to call it 'jigsaw' instead of java9, so it'll
> still makes sense once we're at java16
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MCOMPILER-275) Introduce src/main/jigsaw folder
Robert Scholte created MCOMPILER-275:
Summary: Introduce src/main/jigsaw folder
Key: MCOMPILER-275
URL: https://issues.apache.org/jira/browse/MCOMPILER-275
Project: Maven Compiler Plugin
Issue Type: New Feature
Reporter: Robert Scholte
When you want to add a module-info.java file to your project AND want your code
to be compatible with older java version, then you need to call {{javac}} twice.
To prevent all kinds of magic for selecting the right files to compile with the
right version of Java it is probably better to just have a separate folder for
it. I'd prefer to call it 'jigsaw' instead of java9, so it'll still makes sense
once we're at java16
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-505) Feature Request: useStrictFiltering option for FileSets
[ https://issues.apache.org/jira/browse/MASSEMBLY-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15438561#comment-15438561 ] Thomas Schloegl commented on MASSEMBLY-505: --- I would need this documented feature too. I tried version 2.6 but I get the error 'Unrecognised tag'. > Feature Request: useStrictFiltering option for FileSets > --- > > Key: MASSEMBLY-505 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-505 > Project: Maven Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2 > Environment: Maven 2.2.1, RHEL4 >Reporter: John Casey > Attachments: fail_strictfiltering.zip > > > *NOTE:* This is a clone of MASSEMBLY-488. The original issue will be closed > Won't Fix, since the plexus-utils class DirectoryScanner, which is the core > of the FileSet functionality, doesn't support strict include/exclude > filtering. > This issue is a feature request to have that added. > - > I'm trying to turn on useStrictFiltering in a fileSet in an assembly > descriptor, but maven doesn't fail when the file does not exist. Here > is an example of what the assembly descriptor looks like: > > > tar.gz > > > > true > src/main > > nonexistant.txt* > > > > > Running "mvn package" happily produces a tarball with no indication that > anything is wrong. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
