[jira] [Commented] (MCOMPILER-308) Compiler failure but no compiler message on the console
[
https://issues.apache.org/jira/browse/MCOMPILER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284966#comment-16284966
]
Robert Scholte commented on MCOMPILER-308:
--
See paragraph of "links" below the description of this issue.
It also contains a link to the Plexus Compiler Javac to improve output parsing.
> Compiler failure but no compiler message on the console
> ---
>
> Key: MCOMPILER-308
> URL: https://issues.apache.org/jira/browse/MCOMPILER-308
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Gary Gregory
>
> Using:
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> Steps to reproduce:
> * git clone https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> * git checkout tags/log4j-2.9.1-rc1
> * mvn -e verify
> Will give you:
> {noformat}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
> log4j-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 530 source files to
> C:\temp\rc\apache-log4j-2.9.1-src\log4j-core\target\test-classes
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [ 3.890
> s]
> [INFO] Apache Log4j API Java 9 support SUCCESS [ 8.330
> s]
> [INFO] Apache Log4j API ... SUCCESS [ 37.451
> s]
> [INFO] Apache Log4j Core .. FAILURE [ 55.364
> s]
> [INFO] Apache Log4j Core Integration Tests SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:47 min
> [INFO] Finished at: 2017-09-18T10:00:51-06:00
> [INFO] Final Memory: 41M/137M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleM
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16285183#comment-16285183
]
Robert Scholte commented on MNG-6308:
-
javadoc and sources are attachments, but in the end it is only packaging,
installing and deploying.
I've talked with [~stephenc] about this for Model 5.0.0. My example is the
soapui-maven-plugin, which can generate a web archive for a mockservice. The
packaging should be war based on the resulting file type, but that comes with
too much overhead. the pom-lifecycle should be enough.
This example shows that packaging is not always interesting, IMHO adding
package info can cause unintended confusion.
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286335#comment-16286335
]
Robert Scholte commented on MNG-6308:
-
How about combining it with my wish to show the groupId and artifactId as well,
centered:
{noformat}
[INFO]
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO] < org.apache.maven:apache-maven:pom >---
{noformat}
or
{noformat}
[INFO] < org.apache.maven:apache-maven:pom >---
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Moved] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-6287 to MSHADE-268: Key: MSHADE-268 (was: MNG-6287) Project: Maven Shade Plugin (was: Maven) > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286356#comment-16286356 ] Robert Scholte commented on MSHADE-268: --- If you're working on a library and want to shade, you probably want to relocate as well. In that case downloading the sources won't be enough. Those sources must be relocated as well. There's no option yet to shade attachments like sources and javadoc. If you're working on an apllication, I don't see the need for these sources. Shading is done during packaging, so during development you can still use the original sources. > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286488#comment-16286488
]
Robert Scholte commented on MNG-6308:
-
I don't want to duplicate the version, so that would mean shifting it, like:
{noformat}
[INFO] --< org.apache.maven:apache-maven:pom:3.5.3-SNAPSHOT >--
[INFO] Building Apache Maven Distribution [15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286565#comment-16286565
]
Robert Scholte commented on MNG-6308:
-
when 80 is not enough... We might need to do the same as Twitter: double the
length (or best fit)
{noformat}
[INFO] -<
org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:3.5.3-SNAPSHOT >-
[INFO] Building Apache Maven Compiler Plugin[15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288209#comment-16288209
]
Robert Scholte commented on MNG-6308:
-
Yes, I think that's the best option. Without version it is compact, better
readable. And it is the value that will never change (the version is variable,
will change with every release).
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292225#comment-16292225
]
Robert Scholte commented on MNG-6308:
-
I've updated the display. Only question is: do we want to add colors here?
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-318:
-
Description:
Compiling java9+ groovy + maven code base does not compile groovy files.
Attached is the sample project
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project api: Compilation failure: Compilation failure:
[ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
or on patch path for module
[ERROR]
/Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
cannot find symbol
[ERROR] symbol: class GroovyService
[ERROR] location: package com.allstate.jigsaw
[ERROR] -> [Help 1]
[ERROR]
{noformat}
was:
Compiling java9+ groovy + maven code base does not compile groovy files.
Attached is the sample project
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project api: Compilation failure: Compilation failure:
[ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
or on patch path for module
[ERROR]
/Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
cannot find symbol
[ERROR] symbol: class GroovyService
[ERROR] location: package com.allstate.jigsaw
[ERROR] -> [Help 1]
[ERROR]
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Priority: Critical
> Attachments: JigsawTest.zip
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292228#comment-16292228
]
Robert Scholte commented on MCOMPILER-318:
--
On my machine if fails with the following error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project services: Fatal error compiling: java.lang.NoSuchFieldError: pid
{noformat}
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Priority: Critical
> Attachments: JigsawTest.zip
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-308) Compiler failure but no compiler message on the console
[
https://issues.apache.org/jira/browse/MCOMPILER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292296#comment-16292296
]
Robert Scholte commented on MCOMPILER-308:
--
We've found the root cause.
After recovering the error messages I received the following analysis:
bq. Looking at the JarFileSystem code involved in the stacktrace, it seems that
the jar file claims to be a MR-jar (it has the MULTI-RELEASE attribute) but
does not have any versions (/META-INF/versions).
This was enough for me to continue and I found the troubling jar:
{{log4j-api-2.10.1-SNAPSHOT-tests.jar}}
So this is something you should fix yourself: ensure that the Multi-Release
attribute is *only* used for the jar and not the test-jar.
I will leave this issue open to remind me to upgrade the plexus-compiler-javac.
> Compiler failure but no compiler message on the console
> ---
>
> Key: MCOMPILER-308
> URL: https://issues.apache.org/jira/browse/MCOMPILER-308
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Gary Gregory
>
> Using:
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> java version "9"
> Java(TM) SE Runtime Environment (build 9+181)
> Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)
> Steps to reproduce:
> * git clone https://git-wip-us.apache.org/repos/asf/logging-log4j2.git
> * git checkout tags/log4j-2.9.1-rc1
> * mvn -e verify
> Will give you:
> {noformat}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @
> log4j-core ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 530 source files to
> C:\temp\rc\apache-log4j-2.9.1-src\log4j-core\target\test-classes
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Log4j 2 . SUCCESS [ 3.890
> s]
> [INFO] Apache Log4j API Java 9 support SUCCESS [ 8.330
> s]
> [INFO] Apache Log4j API ... SUCCESS [ 37.451
> s]
> [INFO] Apache Log4j Core .. FAILURE [ 55.364
> s]
> [INFO] Apache Log4j Core Integration Tests SKIPPED
> [INFO] Apache Log4j 1.x Compatibility API . SKIPPED
> [INFO] Apache Log4j SLF4J Binding . SKIPPED
> [INFO] Apache Log4j to SLF4J Adapter .. SKIPPED
> [INFO] Apache Log4j Commons Logging Bridge SKIPPED
> [INFO] Apache Log4j Flume Bridge .. SKIPPED
> [INFO] Apache Log4j Web ... SKIPPED
> [INFO] Apache Log4j Tag Library ... SKIPPED
> [INFO] Apache Log4j JMX GUI ... SKIPPED
> [INFO] Apache Log4j Samples ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Common ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Remote ... SKIPPED
> [INFO] Apache Log4j Samples: Flume - Embedded . SKIPPED
> [INFO] Apache Log4j Samples: Configuration SKIPPED
> [INFO] Apache Log4j Samples: LoggerProperties . SKIPPED
> [INFO] Apache Log4j OSGi .. SKIPPED
> [INFO] Apache Log4j BOM ... SKIPPED
> [INFO] Apache Log4j NoSQL . SKIPPED
> [INFO] Apache Log4J Performance Tests . SKIPPED
> [INFO] Apache Log4j Streaming Interface ... SKIPPED
> [INFO] Apache Log4j JUL Adapter ... SKIPPED
> [INFO] Apache Log4j Liquibase Binding . SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:47 min
> [INFO] Finished at: 2017-09-18T10:00:51-06:00
> [INFO] Final Memory: 41M/137M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project log4j-core: Compilation failure
> at
[jira] [Closed] (MCOMPILER-319) Maven Compiler not compatible with Java 1.6
[
https://issues.apache.org/jira/browse/MCOMPILER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-319.
Resolution: Not A Problem
Assignee: Robert Scholte
The required *runtime* version is documented on the [Summary
page|https://maven.apache.org/plugins/maven-compiler-plugin/project-summary.html]
Be aware there's a difference between the required Java runtime for Maven and
the compiler version. These can be 2 different Java instances.
If you want to use Maven Compiler 3.7.0, then Maven must run with Java 7.
To compile with Java 6 at the same time you can use
[toolchains|https://maven.apache.org/guides/mini/guide-using-toolchains.html].
With the recent Maven Compiler Plugin you can also refer to a toolchain with
the
[jdkToolchain|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#jdkToolchain]
parameter.
One option I'd like to mention is [Animal
Sniffer|http://www.mojohaus.org/animal-sniffer/] which can ensure only Java6
code is used.
> Maven Compiler not compatible with Java 1.6
> ---
>
> Key: MCOMPILER-319
> URL: https://issues.apache.org/jira/browse/MCOMPILER-319
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: T:\apache-maven\apache-maven-3.0.5
> Java version: 1.6.0_141, vendor: Sun Microsystems Inc.
> Java home: C:\opt\Java\jdk1.6.0_141\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Benoît Berthonneau
>Assignee: Robert Scholte
>Priority: Critical
>
> With Maven projects using Java 1.6, the Maven Compiler plugin is not usable.
> The following error is raised :
> {code:java}
> [WARNING] Error injecting: org.apache.maven.plugin.compiler.CompilerMojo
> java.lang.TypeNotPresentException: Type
> org.apache.maven.plugin.compiler.CompilerMojo not present
> at
> org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:115)
> at org.eclipse.sisu.space.NamedClass.load(NamedClass.java:46)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> at
> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> at
> org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:459)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:97)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 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
[jira] [Commented] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292369#comment-16292369
]
Robert Scholte commented on MCOMPILER-318:
--
It seems to be a lombok issue, running it with an additional {{-e}} I get
{noformat}
Caused by: java.lang.NoSuchFieldError: pid
at lombok.javac.JavacAST.packageDeclaration (JavacAST.java:107)
at lombok.javac.JavacAST. (JavacAST.java:81)
at lombok.javac.JavacTransformer.transform (JavacTransformer.java:67)
at lombok.javac.apt.Processor.process (Processor.java:250)
at lombok.core.AnnotationProcessor$JavacDescriptor.process
(AnnotationProcessor.java:115)
at lombok.core.AnnotationProcessor.process (AnnotationProcessor.java:165)
at lombok.launch.AnnotationProcessorHider$AnnotationProcessor.process
(AnnotationProcessor.java:58)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor
(JavacProcessingEnvironment.java:968)
{noformat}
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Priority: Critical
> Attachments: JigsawTest.zip
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292425#comment-16292425
]
Robert Scholte commented on MCOMPILER-318:
--
Can you share {{mvn --version}}?
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Priority: Critical
> Attachments: JigsawTest.zip
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6320) Apparently wrong encoding of non-ascii java class filename in error messages in the maven log
[ https://issues.apache.org/jira/browse/MNG-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292489#comment-16292489 ] Robert Scholte commented on MNG-6320: - Seems related to MNG-6205 > Apparently wrong encoding of non-ascii java class filename in error messages > in the maven log > - > > Key: MNG-6320 > URL: https://issues.apache.org/jira/browse/MNG-6320 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 3.5.2 > Environment: Windows 10 >Reporter: Eugene Pliskin >Priority: Minor > Attachments: maven.3.3.9.log, maven.3.5.2.log > > > Attached please find two build logs, one from maven version 3.3.9, and > another from maven version 3.5.2. Both log files were made for the same Java > project on Windows 10 machine, with "mvn compile > log" command. Java > platform default encoding is UTF-8. > One Java source file contains intentional error, which is reported in lines > 433-435 of file "maven.3.3.9.log", and in lines 437-439 of file > "maven.3.5.2.log". > Class name is non-ascii and version 3.3.9 log appears right. But in version > 3.5.2 this same filename appears unreadable in the error message in the maven > log. > Notice that if I view the file "maven.3.5.2.log" with different encoding > (cp866), then this error message becomes readable. It looks like this > non-ascii filename gets inserted into UTF-8 encoded log file in wrong "cp866" > encoding, in maven version 3.5.2. > Still, version 3.3.9 of maven does the right thing, and the error message is > readable in UTF-8 log. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MJAVADOC-506) Javadoc plugin broken on Java 8 when module-info.java present
[ https://issues.apache.org/jira/browse/MJAVADOC-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MJAVADOC-506: --- Assignee: Robert Scholte > Javadoc plugin broken on Java 8 when module-info.java present > - > > Key: MJAVADOC-506 > URL: https://issues.apache.org/jira/browse/MJAVADOC-506 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.0 >Reporter: Stephen Colebourne >Assignee: Robert Scholte > > The fix to MJAVADOC-498 causes the command line flag `--class-path` to be > used on Java 8, a flag that is not recognised. This happens when the project > contains `module-info.java`, but the module-info file is excluded by the > configuration of the plugin. > The problem is here: > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java?r1=1802722&r2=1813672&pathrev=1813672 > where the code checks whether `src/main/java/module-info.java` exists without > considering whether the file has been excluded by configuration. (I am simply > trying to setup a build that uses Java 9 tooling on Java 9 and Java 8 tooling > when running on Java 8) > There is no workaround to this in v3.0.0 that I can see, so I have to > rollback to v3.0.0-M1. The solution is to check the includes/excludes when > trying to obtain the module-info file. Or to check what version of the > Javadoc tool is being used (as per MJAVADOC-499). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-319) Maven Compiler not compatible with Java 1.6
[
https://issues.apache.org/jira/browse/MCOMPILER-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16293750#comment-16293750
]
Robert Scholte commented on MCOMPILER-319:
--
We're quite slow in changing the minimum requirements. To let Maven require
Java7 was a long time after Java7 was released. To let plugins require at least
Maven3 also happened a long time after Maven3 was released.
I noticed you're still on Maven 3.0.5 and my guess is that you want to compile
Java code with the same version as the runtime of Maven, even though these are
two different things.
And this is not just a compiler-plugin issue, but this plugin has had some
extra attention due to the required changes that came with Java 9. In the end
*every* plugin you want to use must be compiled with at most the runtime
version of Maven. In general there should be no issue if you Maven version is
not too old, and 3.0.5 is quite old by now.
So consider upgrading Maven. If you want to be sure your own code still runs on
Java 6 I have the following advices:
- Install Java 9 (yes, really!) and set the
[release|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release]
parameter to {{6}}. This is effectively the same as using animal sniffer.
- Use the
[enforceBytecodeVersion|http://www.mojohaus.org/extra-enforcer-rules/enforceBytecodeVersion.html]
enforcer rule to ensure your dependencies are Java6 compatible.
- Toolchain is by far the safest solution, because with this you can really
compile with JDK6.
The quote you mention about source/target has nothing to do with this
discussion. It only claims that the values are fixed and are not related to the
JDK you use. In fact, Java9 doesn't support source/target 1.5 anymore, which
means you must change these values anyway, unless you use toolchains.
To answer your question: 3.6.2 is the latest Java6 compatible version, but you
must ask this question for *every* plugin you use.
> Maven Compiler not compatible with Java 1.6
> ---
>
> Key: MCOMPILER-319
> URL: https://issues.apache.org/jira/browse/MCOMPILER-319
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: T:\apache-maven\apache-maven-3.0.5
> Java version: 1.6.0_141, vendor: Sun Microsystems Inc.
> Java home: C:\opt\Java\jdk1.6.0_141\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
>Reporter: Benoît Berthonneau
>Assignee: Robert Scholte
>Priority: Critical
>
> With Maven projects using Java 1.6, the Maven Compiler plugin is not usable.
> The following error is raised :
> {code:java}
> [WARNING] Error injecting: org.apache.maven.plugin.compiler.CompilerMojo
> java.lang.TypeNotPresentException: Type
> org.apache.maven.plugin.compiler.CompilerMojo not present
> at
> org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:115)
> at org.eclipse.sisu.space.NamedClass.load(NamedClass.java:46)
> at
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at
> org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:109)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:47)
> at
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:997)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1047)
> at
> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:993)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(L
[jira] [Updated] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-318:
-
Attachment: JigsawTest-cleanup.zip
Attached the cleaned up project. Please try this project from commandline.
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Priority: Critical
> Attachments: JigsawTest-cleanup.zip, JigsawTest.zip
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6317) mvn clean install fails with index out of bounds exception
[ https://issues.apache.org/jira/browse/MNG-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6317. --- Resolution: Cannot Reproduce Assignee: Robert Scholte I cannot reproduce it, but I'm pretty sure you're hitting one of the subissues of MNG-6216. Assuming it is a corrupt pom, you should clean your local repo. Otherwise upgrade to Maven 3.5.2 > mvn clean install fails with index out of bounds exception > -- > > Key: MNG-6317 > URL: https://issues.apache.org/jira/browse/MNG-6317 > Project: Maven > Issue Type: Bug > Components: Command Line >Affects Versions: 3.5.0 > Environment: Windows 10 64-bit >Reporter: Tom Sheckells >Assignee: Robert Scholte > Labels: maven > Attachments: HW3.zip, debug.log > > > I'm trying to build and deploy a Red Hat BRMS Hello World project. All of a > sudden, something happened and I can't do a command line build anymore. I > have been trying to switch from Intellij to Eclipse based environment due to > Red Hat editor. This may have hosed something. > I attached the project directory with the whole project. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MNG-6300) Multi module release creates empty directories in war file instead of jars
[
https://issues.apache.org/jira/browse/MNG-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6300:
---
Assignee: Robert Scholte
> Multi module release creates empty directories in war file instead of jars
> --
>
> Key: MNG-6300
> URL: https://issues.apache.org/jira/browse/MNG-6300
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: Linux, Oracle java 1.8.0_152
>Reporter: Andreas Kurth
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.5.3
>
> Attachments: build.log, mm.zip
>
>
> After updating to maven 3.5.2 we encounter the following reproducible bug
> with multi module builds.
> If one of the modules is a war module and depends on another module, the
> dependency module will not be included as a jar file in WEB-INF/lib of the
> war file, but as an empty directory instead. Non module dependencies will be
> included correctly.
> This bug does occur when the following conditions are met:
> - running release:prepare/release:perform
> - element is present, so that release goals
> are "deploy site-deploy"
> - element contains javadoc-maven-plugin
> Please note that when running "mvn install" or "mvn deploy" the resulting war
> file is ok, while "mvn release:perform" creates corrupt files as described.
> Also, if javadoc-maven-plugin is not present in block, the war
> file is fine, too.
> I have no idea whether this bug is maven core or rather release-plugin or
> even javadoc-plugin related, so I file it here. I prepared a minimal self
> contained example and attach it as mm.zip. To run the example, the following
> steps are needed:
> {code}
> cd /tmp
> unzip /path/to/mm.zip
> cd mm
> git init
> git add pom.xml mm-lib mm-war .gitignore
> git commit
> mvn release:prepare
> mvn release:perform
> {code}
> After building the resulting corrupt war file can be found here:
> repo/com/example/mm/mm-war/1.0.0/mm-war-1.0.0.war
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-318.
Resolution: Not A Problem
Assignee: Robert Scholte
Cool, now we have the same error: {{java.lang.NoSuchFieldError: pid}}
This is not a Maven issue, but a Lombok issue. I know Lombok has some Java9
issues, don't know if this is one of them. You should contact that project for
further help.
Anyhow, this is not a maven-compiler-plugin, so closing it as "not our problem"
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: JigsawTest-cleanup.zip, JigsawTest.zip, a.txt
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MNG-6324) multithread build: DefaultProjectDependenciesResolver.resolve waits for a lock indenfinetly causing the build to hang
[
https://issues.apache.org/jira/browse/MNG-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6324.
---
Resolution: Duplicate
Assignee: Robert Scholte
Duplicate of MNG-6323
> multithread build: DefaultProjectDependenciesResolver.resolve waits for a
> lock indenfinetly causing the build to hang
> -
>
> Key: MNG-6324
> URL: https://issues.apache.org/jira/browse/MNG-6324
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Zoltan Haindrich
>Assignee: Robert Scholte
>
> This issue have given me a very bad day about 2 weeks ago...and after I was
> able to get going - I've just dropped my {{-T9}} switch...
> but today I've seen it again in travis-ci runs also...and again dropping {{-T
> n}} fixed it.
> So I've checked it: {{3.3.9}} and {{3.5.0}} are not affected - seems like the
> problem is introduced in {{3.5.2}}.
> It might be possible that this is something which is specific to Hive..please
> let me know if that's the matter.
> steps to reproduce:
> {code}
> git clone https://github.com/apache/hive
> cd hive
> mvn install -Pitests -Dmaven.repo.local=$PWD/_empty_repo -T9 -pl itests/qtest
> -Dtest=TestCliDriver#*[udf_power] -DinitScript=asd.sql -am -q
> {code}
> the above should normally take around 8-10 minutes; if you have a caching
> repository configured nearby...
> environment info:
> {code}
> 00:02:06.741 Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> 00:02:06.742 Maven home:
> /home/jenkins/ws/workspace/hive-mvn-checker/MAVEN_VERSION/3.5.2/jdk/j8/node/Sustwork/apache-maven-3.5.2
> 00:02:06.743 Java version: 1.8.0_144, vendor: Oracle Corporation
> 00:02:06.743 Java home: /home/jenkins/ws/tools/hudson.model.JDK/j8/jre
> 00:02:06.744 Default locale: en_US, platform encoding: UTF-8
> 00:02:06.744 OS name: "linux", version: "4.4.0-101-generic", arch: "amd64",
> family: "unix"
> {code}
> relevant stacktrace parts (other threads are idle):
> {code}
> @@@ a thread in this states was always present ; when I've seen the lockup
> "BuilderThread 8" #91 prio=5 os_prio=0 tid=0x7fafcc691000 nid=0x5f2b
> waiting on condition [0x7faf99b6c000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.eclipse.aether.connector.basic.PartialFile$LockFile.lock(PartialFile.java:113)
> at
> org.eclipse.aether.connector.basic.PartialFile$LockFile.(PartialFile.java:69)
> at
> org.eclipse.aether.connector.basic.PartialFile$Factory.newInstance(PartialFile.java:278)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:438)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
> at
> org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
> at
> org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:498)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:399)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:223)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:246)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:200)
> at
> org.
[jira] [Updated] (MNG-6322) tag result in propertityPlaceHolder replace error
[
https://issues.apache.org/jira/browse/MNG-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6322:
Description:
{code:xml}
4.0.0
FH
data-center-outchannel
war
0.0.2
FHM Maven Webapp
{color:red}http://maven.apache.org{color}
UTF-8
1.1
4.0.4.RELEASE
5.1.34
7.0.61
5.1.30
1.3.4-SNAPSHOT
true
src/main/resources/autogen/generatorConfig.xml
${project.build.directory}/generated-sources/mybatis-generator
2.5.3
2.2.2
0.5
3.4.6
2.0.0
dev
dev
product
product
org.springframework
spring-aop
${spring.version}
org.springframework
spring-aspects
${spring.version}
org.springframework
spring-beans
${spring.version}
org.springframework
spring-context
${spring.version}
org.springframework
spring-context-support
${spring.version}
org.springframework
spring-core
${spring.version}
org.springframework
spring-dao
2.0.8
org.springframework
spring-expression
${spring.version}
org.springframework
spring-jdbc
${spring.version}
org.springframework
spring-mock
2.0.8
org.springframework
spring-orm
${spring.version}
org.springframework
spring-test
${spring.version}
org.springframework
spring-tx
${spring.version}
org.springframework
spring-web
${spring.version}
org.springframework
spring-test
${spring.version}
org.springframework
spring-webmvc
${spring.version}
com.alibaba
dubbo
${dubbo.version}
org.springframework
spring
com.treefinance.commonservice
guid-service-facade
${uid-worker.version}
com.github.diamond
super-diamond-client
${super-diamond-client.version}
io.netty
netty-all
4.0.42.Final
com.google.guava
guava
20.0
com.101tec
zkclient
${zk-client.version}
org.slf4j
slf4j-log4j12
[jira] [Closed] (MNG-6322) tag result in propertityPlaceHolder replace error
[
https://issues.apache.org/jira/browse/MNG-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6322.
---
Resolution: Not A Problem
Assignee: Robert Scholte
The following snippet is causing your issue:
{code:xml}
src/main/resources
WEB-INF/classes
true
**/diamond.properties
{code}
You should also exclude the {{applicationContext.xml}} from being filtered,
otherwise this file will be filled with Maven specific properties, such as the
url.
> tag result in propertityPlaceHolder replace error
>
>
> Key: MNG-6322
> URL: https://issues.apache.org/jira/browse/MNG-6322
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
> Environment: spring 4.2.0.RELEASE,maven 3.3.9,mac os x 10.11,
> jdk1.8,
>Reporter: yongma
>Assignee: Robert Scholte
> Labels: maven
> Attachments: ApplicationContext-mvc.xml, ApplicationContext.xml
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> {code:xml}
> 4.0.0
> FH
> data-center-outchannel
> war
> 0.0.2
> FHM Maven Webapp
> {color:red}http://maven.apache.org{color}
>
>
> UTF-8
> 1.1
> 4.0.4.RELEASE
>
> 5.1.34
> 7.0.61
> 5.1.30
>
> 1.3.4-SNAPSHOT
> true
>
> src/main/resources/autogen/generatorConfig.xml
>
>
> ${project.build.directory}/generated-sources/mybatis-generator
>
> 2.5.3
> 2.2.2
> 0.5
> 3.4.6
>
> 2.0.0
>
>
>
> dev
>
> dev
>
>
>
> product
>
> product
>
>
>
>
>
>
> org.springframework
> spring-aop
> ${spring.version}
>
>
> org.springframework
> spring-aspects
> ${spring.version}
>
>
> org.springframework
> spring-beans
> ${spring.version}
>
>
> org.springframework
> spring-context
> ${spring.version}
>
>
> org.springframework
> spring-context-support
> ${spring.version}
>
>
> org.springframework
> spring-core
> ${spring.version}
>
>
> org.springframework
> spring-dao
> 2.0.8
>
>
> org.springframework
> spring-expression
> ${spring.version}
>
>
> org.springframework
> spring-jdbc
> ${spring.version}
>
>
> org.springframework
> spring-mock
> 2.0.8
>
>
> org.springframework
> spring-orm
> ${spring.version}
>
>
> org.springframework
> spring-test
> ${spring.version}
>
>
> org.springframework
> spring-tx
> ${spring.version}
>
>
> org.springframework
> spring-web
> ${spring.version}
>
>
> org.springframework
>
[jira] [Deleted] (MNG-6325) qtests: semijoin_hint.q breaks hybridgrace_hashjoin_2.q
[
https://issues.apache.org/jira/browse/MNG-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte deleted MNG-6325:
> qtests: semijoin_hint.q breaks hybridgrace_hashjoin_2.q
> ---
>
> Key: MNG-6325
> URL: https://issues.apache.org/jira/browse/MNG-6325
> Project: Maven
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>
> {code}
> mvn install -q -am -pl itests/qtest -DskipSparkTests
> -Dtest=TestMiniLlapLocalCliDriver
> -Dqfile=semijoin_hint.q,hybridgrace_hashjoin_2.q
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-317) Plugin generates wrong modulepath (dependencies listed in wrong order)
[
https://issues.apache.org/jira/browse/MCOMPILER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298962#comment-16298962
]
Robert Scholte commented on MCOMPILER-317:
--
That's kind of what I meant with "There might be a deeper problem here ..." I
am really surprised if the order on the classpath is different to how we
explain it to the world. Requires further investigation.
> Plugin generates wrong modulepath (dependencies listed in wrong order)
> --
>
> Key: MCOMPILER-317
> URL: https://issues.apache.org/jira/browse/MCOMPILER-317
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T03:58:13-04:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gili
>
> Testcase: https://github.com/cowwoc/maven-java9-class-shadowing
> If a project contains dependencies with the same module name (which is valid
> according to https://stackoverflow.com/a/46573805/14731) then
> maven-compile-plugin invokes {{javac}} with a modulepath containing
> dependencies in an (apparently) arbitrary order. If I place the project in
> one directory, I get one order. If I place the project in another directory,
> I get another order. This is 100% reproducible across multiple runs, across
> different computers.
> I suspect that somewhere deep inside the code someone is using {{HashMap}}
> which is leading to undefined iteration order depending on the path being
> used.
> Expected behavior: dependencies should be listed in the same order as
> declared in pom.xml (see https://stackoverflow.com/a/793193/14731)
> Actual behavior: regardless of whether I list {{ExtensionPresent}} before or
> after {{MyLibrary}}, the wrong order gets passed to {{javac}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCOMPILER-316) maven should *always* print classpath used to compile the java files
[
https://issues.apache.org/jira/browse/MCOMPILER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-316.
Resolution: Not A Problem
Assignee: Robert Scholte
> maven should *always* print classpath used to compile the java files
>
>
> Key: MCOMPILER-316
> URL: https://issues.apache.org/jira/browse/MCOMPILER-316
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Environment: ALL
>Reporter: Vimal
>Assignee: Robert Scholte
>
> mostly i use "{{maven clean install}}" to build my packages
> by default maven doesnt print the classpath used to compile java files. It
> should.
> it prints information like which jars it is downloading. thats fine.
> but it should *always* print the classpath used.
> there is a "-X" option which prints classpath , but it prints TONS and TONS
> of information which i think no one is interested in (except perhaps the
> maven developers)
> so there is no easy way to get the classpath used.
> Please make maven to print classpath for each java file compiled, by default.
> OR give a easy option to enable it along with other options.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298998#comment-16298998
]
Robert Scholte commented on MNG-6323:
-
MNG-6324 seems to have a reproducable project. Then it is a matter of
git-bisect to find the trouble making commit.
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the deadlocks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAR-238) Allow setting of module main class
[
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479528#comment-16479528
]
Robert Scholte commented on MJAR-238:
-
Plexus Archiver has been changed to support this. Final step would be to
rewrite the plugin a bit to support those new features.
> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
> Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Assignee: Robert Scholte
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the
> manifest/mainclass does not set the module main class. Therefore the module
> is not executable without specifying the main class. Executing the module
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class
> set. If I understand correctly it's inside the module-info.class as a
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the
> module-info.class.
> {noformat}
> -e, --main-class=CLASSNAME The application entry point for stand-alone
> applications bundled into a modular, or
> executable,
> jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item
> since the mainclass entry in the manifest file is not needed in 'module mode'
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't
> find any existing issues related to this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-323) Support multi-release jars
[ https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479551#comment-16479551 ] Robert Scholte commented on MCOMPILER-323: -- I've been inspired by Russels http://www.russgold.net/sw/2018/03/looking-for-mr-good-jar/ while improving https://github.com/codehaus-plexus/plexus-languages/issues/5 and it works quite well. There's only one huge BUT: the fix for plexus-languages works because we have a Travis CI-server which verifies multiple Java versions. And this also means that the unittests are verified for a specific Java version as well. Downside: IDE doesn't understand it and sees it as a duplicate class. Please take a look at the blog and see what matches your situation best. Creating mrjars will be complex and should be avoided. However, if you need it we should be able to configure several execution blocks properly to reach the goal. I'm still interested in the solutions others have. And this should be possible without buildhelper-maven-plugin, just maven-compiler-plugin and execution-blocks (and ignore the testing part, that's an issue for another plugin) > Support multi-release jars > -- > > Key: MCOMPILER-323 > URL: https://issues.apache.org/jira/browse/MCOMPILER-323 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mike Drob >Priority: Major > > Java 9 allows for JRE version specific code in the form of "multi-release > jars" > Older JREs will treat them as normal jars, while newer JREs will load the > appropriate specific classes. AFAICT, maven does not currently support this. > Compiler plugin should automatically detect when there are multiple source > levels and set MRJAR=True in the manifest. > Source directories could potentially be src/main/java, src/main/java9, > src/main/java10, etc. These probably need to be configurable as well, or some > deeper discussion about what makes sense and is intuitive for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MCOMPILER-336) Dependency that should be on modulepath sometime put on classpath
[
https://issues.apache.org/jira/browse/MCOMPILER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-336.
Resolution: Fixed
Fix Version/s: 3.7.1
Fixed in
[bc99395b15f2b3062431c41269fb97efa9df5671|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=bc99395b15f2b3062431c41269fb97efa9df5671]
> Dependency that should be on modulepath sometime put on classpath
> -
>
> Key: MCOMPILER-336
> URL: https://issues.apache.org/jira/browse/MCOMPILER-336
> Project: Maven Compiler Plugin
> Issue Type: Task
>Affects Versions: 3.7.0
>Reporter: Martin Desruisseaux
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: module-vs-classpath.zip
>
>
> {{maven-compiler-plugin}} sometime puts modularized dependencies on the
> {{javac}} {{-classpath}} option instead than {{-modulepath}}, which cause
> compilation failure. A test case is attached. Step to reproduce:
> {noformat}
> cd module-vs-classpath
> cd a
> mvn install
> cd ../b
> mvn clean install
> mvn install
> {noformat}
> The last command fail with the following error message:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project b: Compilation failure
> [ERROR] module not found: test.a
> {noformat}
> Execution with the {{-X}} option shows that the {{test.a}} dependency is
> correctly declared in {{-modulepath}} when executing {{mvn clean install}},
> but is wrongly declared in {{-classpath}} when executing {{mvn install}}.
> A workaround is to remove the
> {{false}} option in
> the {{pom.xml}} files, or to execute {{touch src/main/java/module-info.java}}
> before {{mvn install}}. However the same error message occurs when attempting
> to execute {{mvn site}}, for which case I have found no workaround yet (note:
> the {{mvn site}} problem is not reproduced by the attached
> {{module-vs-classpath.zip}} file).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MCOMPILER-323) Support multi-release jars
[ https://issues.apache.org/jira/browse/MCOMPILER-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MCOMPILER-323: Assignee: Robert Scholte > Support multi-release jars > -- > > Key: MCOMPILER-323 > URL: https://issues.apache.org/jira/browse/MCOMPILER-323 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Mike Drob >Assignee: Robert Scholte >Priority: Major > > Java 9 allows for JRE version specific code in the form of "multi-release > jars" > Older JREs will treat them as normal jars, while newer JREs will load the > appropriate specific classes. AFAICT, maven does not currently support this. > Compiler plugin should automatically detect when there are multiple source > levels and set MRJAR=True in the manifest. > Source directories could potentially be src/main/java, src/main/java9, > src/main/java10, etc. These probably need to be configurable as well, or some > deeper discussion about what makes sense and is intuitive for users. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6281) ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML
[
https://issues.apache.org/jira/browse/MNG-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16480569#comment-16480569
]
Robert Scholte commented on MNG-6281:
-
No, this is not a duplicate of MNG-6216, but a subtask. The MNG-6216 shows the
issue, however there are multiple causes, each requires their own solution. In
this case the {{pom.xml}} is corrupt, but Maven doesn't show which pom is
causing the issue.
> ArrayIndexOutOfBoundsException caused by pom.xml with invalid/duplicate XML
> ---
>
> Key: MNG-6281
> URL: https://issues.apache.org/jira/browse/MNG-6281
> Project: Maven
> Issue Type: Sub-task
> Components: POM
>Affects Versions: 3.5.0
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 3.5.x-candidate
>
>
> This is a hard one to recognize and to reproduce, but there are cases where
> (for unknown reasons) that the content of the XML is duplicated in the pom
> file.
> Up until version 3.5.0 this was not an issue, because the XML parser stopped
> parsing once hitting the closing project-tag, ignoring any content afterwards.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPLUGIN-339) maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10
[
https://issues.apache.org/jira/browse/MPLUGIN-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16481902#comment-16481902
]
Robert Scholte commented on MPLUGIN-339:
My guess is a multirelease jar using the {{jdk.javadoc.doclet}} package for 9+,
see
https://docs.oracle.com/javase/9/docs/api/index.html?jdk.javadoc-summary.html
> maven-plugin-tools-javadoc broken by com.sun.tools.doclets removal in Java 10
> -
>
> Key: MPLUGIN-339
> URL: https://issues.apache.org/jira/browse/MPLUGIN-339
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-javadoc
>Affects Versions: 3.5.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Fix For: 3.6
>
>
> The com.sun.tools.doclets API is no longer available in Java 10, this breaks
> the maven-plugin-tools-javadoc module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-522) Javadoc generation broken on JDK 10 (Commons Lang3 gives NullPointerException)
[
https://issues.apache.org/jira/browse/MJAVADOC-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-522.
---
Resolution: Duplicate
Assignee: Robert Scholte
> Javadoc generation broken on JDK 10 (Commons Lang3 gives NullPointerException)
> --
>
> Key: MJAVADOC-522
> URL: https://issues.apache.org/jira/browse/MJAVADOC-522
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.0
> Environment: * JDK 10
> * Maven 3.5.3
> * Maven Javadoc plugin 3.0.0
>Reporter: Daniel Fernández
>Assignee: Robert Scholte
>Priority: Major
>
> Executing {{javadoc:javadoc}} in JDK 10 throws a {{NullPointerException}}
> caused by Apache Commons Lang 3.5:
> {code}
> Caused by: java.lang.NullPointerException at
> org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
> (SystemUtils.java:1626) at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.getJavadocExecutable
> (AbstractJavadocMojo.java:3683) at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport
> (AbstractJavadocMojo.java:2001) at
> org.apache.maven.plugins.javadoc.JavadocReport.generate
> (JavadocReport.java:134) at
> org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:329) at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1909) at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81) at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute
> (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute
> (MavenCli.java:956) at org.apache.maven.cli.MavenCli.doMain
> (MavenCli.java:290) at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> ...
> {code}
> The reason for this is
> [LANG-1365|https://issues.apache.org/jira/browse/LANG-1365] which was fixed
> in [this
> commit|https://github.com/apache/commons-lang/commit/a618b844c5a261ced37385ab3947de6e215d46f7].
> Updating to Apache Commons Lang 3.7 should solve the issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-524) Running javadoc plugin under JDK 10 fails with NPE
[
https://issues.apache.org/jira/browse/MJAVADOC-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-524.
---
Resolution: Duplicate
Assignee: Robert Scholte
Fix Version/s: (was: 3.0.1)
> Running javadoc plugin under JDK 10 fails with NPE
> --
>
> Key: MJAVADOC-524
> URL: https://issues.apache.org/jira/browse/MJAVADOC-524
> Project: Maven Javadoc Plugin
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Blocker
>
> Running under JDK 10 produces the following:
> {code}
> [INFO] [INFO]
>
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (attach-javadocs) on
> project maven-dependency-analyzer: Execution attach-javadocs of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar failed.:
> NullPointerException -> [Help 1]
> [INFO] [ERROR]
> [INFO] [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [INFO] [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [INFO] [ERROR]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/
[ https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-520: Description: * plexus-utils to 3.1.0 * qdox to 2.0-M8 * plexus-archiver 3.5, 3.6.0 * plexus-utils-3.1.0 * maven-archiver 3.2.0 * plexus-interactivity-api 1.0-alpha-6 * plexus-java 0.9.8 was: * plexus-utils to 3.1.0 * qdox to 2.0-M8 * plexus-archiver 3.5, 3.6.0 * plexus-utils-3.1.0 * maven-archiver 3.2.0 * plexus-interactivity-api 1.0-alpha-6 > Upgrade plexus-utils/qdox/plexus-archiver/ > -- > > Key: MJAVADOC-520 > URL: https://issues.apache.org/jira/browse/MJAVADOC-520 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.1 > > > * plexus-utils to 3.1.0 > * qdox to 2.0-M8 > * plexus-archiver 3.5, 3.6.0 > * plexus-utils-3.1.0 > * maven-archiver 3.2.0 > * plexus-interactivity-api 1.0-alpha-6 > * plexus-java 0.9.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors
[ https://issues.apache.org/jira/browse/MJAVADOC-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MJAVADOC-447: --- Assignee: Robert Scholte (was: Siveton Vincent) > Command line dump reveals proxy user/password in case of errors > --- > > Key: MJAVADOC-447 > URL: https://issues.apache.org/jira/browse/MJAVADOC-447 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: > "windows xp" version: "5.1" arch: "x86" >Reporter: Christian K. >Assignee: Robert Scholte >Priority: Minor > > If http proxy is set, in case of error calling javadoc, the whole command > line call is dumped out on console. > This can reveal sensible information about personal proxy settings (user and > password) which are passed > via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc > executable. > For example: > Command line was:"C:\Program > Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" > -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true > -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 > -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" > -J-Dhttp.proxyPassword="BAR" @options @packages > If this can be an issue, consider hiding these values in the dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors
[ https://issues.apache.org/jira/browse/MJAVADOC-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-447: Fix Version/s: 3.0.1 > Command line dump reveals proxy user/password in case of errors > --- > > Key: MJAVADOC-447 > URL: https://issues.apache.org/jira/browse/MJAVADOC-447 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: > "windows xp" version: "5.1" arch: "x86" >Reporter: Christian K. >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.0.1 > > > If http proxy is set, in case of error calling javadoc, the whole command > line call is dumped out on console. > This can reveal sensible information about personal proxy settings (user and > password) which are passed > via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc > executable. > For example: > Command line was:"C:\Program > Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" > -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true > -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 > -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" > -J-Dhttp.proxyPassword="BAR" @options @packages > If this can be an issue, consider hiding these values in the dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/
[ https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-520: Description: * -plexus-utils to 3.1.0- * qdox to 2.0-M8 * plexus-archiver 3.5, 3.6.0 * plexus-utils-3.1.0 * maven-archiver 3.2.0 * plexus-interactivity-api 1.0-alpha-6 * plexus-java 0.9.8 was: * plexus-utils to 3.1.0 * qdox to 2.0-M8 * plexus-archiver 3.5, 3.6.0 * plexus-utils-3.1.0 * maven-archiver 3.2.0 * plexus-interactivity-api 1.0-alpha-6 * plexus-java 0.9.8 > Upgrade plexus-utils/qdox/plexus-archiver/ > -- > > Key: MJAVADOC-520 > URL: https://issues.apache.org/jira/browse/MJAVADOC-520 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.1 > > > * -plexus-utils to 3.1.0- > * qdox to 2.0-M8 > * plexus-archiver 3.5, 3.6.0 > * plexus-utils-3.1.0 > * maven-archiver 3.2.0 > * plexus-interactivity-api 1.0-alpha-6 > * plexus-java 0.9.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/
[
https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482456#comment-16482456
]
Robert Scholte commented on MJAVADOC-520:
-
Reverted upgrade of plexus-utils to 3.1.0, the proxyTest fails, which also
exposes another issue: the generated
{{target/test/unit/proxy-test/target/site/apidocs/javadoc.bat}} is useless
because the generated commandline is invalid.
> Upgrade plexus-utils/qdox/plexus-archiver/
> --
>
> Key: MJAVADOC-520
> URL: https://issues.apache.org/jira/browse/MJAVADOC-520
> Project: Maven Javadoc Plugin
> Issue Type: Dependency upgrade
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.1
>
>
> * -plexus-utils to 3.1.0-
> * qdox to 2.0-M8
> * plexus-archiver 3.5, 3.6.0
> * plexus-utils-3.1.0
> * maven-archiver 3.2.0
> * plexus-interactivity-api 1.0-alpha-6
> * plexus-java 0.9.8
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/
[ https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MJAVADOC-520: --- Assignee: Robert Scholte (was: Karl Heinz Marbaise) > Upgrade plexus-utils/qdox/plexus-archiver/ > -- > > Key: MJAVADOC-520 > URL: https://issues.apache.org/jira/browse/MJAVADOC-520 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.0.1 > > > * -plexus-utils to 3.1.0- > * qdox to 2.0-M8 > * plexus-archiver 3.5, 3.6.0 > * plexus-utils-3.1.0 > * maven-archiver 3.2.0 > * plexus-interactivity-api 1.0-alpha-6 > * plexus-java 0.9.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-520) Upgrade plexus-utils/qdox/plexus-archiver/
[ https://issues.apache.org/jira/browse/MJAVADOC-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-520. --- Resolution: Fixed Fixed in [8e47dca880c40c69a59af03e36c59f76e4c14ef7|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=8e47dca880c40c69a59af03e36c59f76e4c14ef7] > Upgrade plexus-utils/qdox/plexus-archiver/ > -- > > Key: MJAVADOC-520 > URL: https://issues.apache.org/jira/browse/MJAVADOC-520 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.0.1 > > > * -plexus-utils to 3.1.0- > * qdox to 2.0-M8 > * plexus-archiver 3.5, 3.6.0 > * plexus-utils-3.1.0 > * maven-archiver 3.2.0 > * plexus-interactivity-api 1.0-alpha-6 > * plexus-java 0.9.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-519) IT detectLinks fails on Windows
[
https://issues.apache.org/jira/browse/MJAVADOC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482499#comment-16482499
]
Robert Scholte commented on MJAVADOC-519:
-
I cannot reproduce this issue, can we close it?
> IT detectLinks fails on Windows
> ---
>
> Key: MJAVADOC-519
> URL: https://issues.apache.org/jira/browse/MJAVADOC-519
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 3.0.1
>
> Attachments: failing-javadoc-it.log
>
>
> [Currently|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commitdiff;h=e637834a1aecaaa835fe2cdcda67664156f3630d]
> the following IT is failing:
> {code}
> [windows-jdk9] [INFO] Passed: 35, Failed: 1, Errors: 0, Skipped: 0
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] The following builds failed:
> [windows-jdk9] [WARNING] * detectLinks\pom.xml
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] Ignoring that 1 build failed.
> [windows-jdk9] [INFO]
>
> [windows-jdk9] [INFO] BUILD SUCCESS
> [windows-jdk9] [INFO] ---
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors
[ https://issues.apache.org/jira/browse/MJAVADOC-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-447: Fix Version/s: (was: 3.0.1) > Command line dump reveals proxy user/password in case of errors > --- > > Key: MJAVADOC-447 > URL: https://issues.apache.org/jira/browse/MJAVADOC-447 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: > "windows xp" version: "5.1" arch: "x86" >Reporter: Christian K. >Assignee: Robert Scholte >Priority: Minor > > If http proxy is set, in case of error calling javadoc, the whole command > line call is dumped out on console. > This can reveal sensible information about personal proxy settings (user and > password) which are passed > via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc > executable. > For example: > Command line was:"C:\Program > Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" > -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true > -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 > -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" > -J-Dhttp.proxyPassword="BAR" @options @packages > If this can be an issue, consider hiding these values in the dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-447) Command line dump reveals proxy user/password in case of errors
[ https://issues.apache.org/jira/browse/MJAVADOC-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482501#comment-16482501 ] Robert Scholte commented on MJAVADOC-447: - Needs to be investigated again after upgrading to plexus-utils 3.1.0 > Command line dump reveals proxy user/password in case of errors > --- > > Key: MJAVADOC-447 > URL: https://issues.apache.org/jira/browse/MJAVADOC-447 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Environment: Maven version: 2.0.7 Java version: 1.4.2 OS name: > "windows xp" version: "5.1" arch: "x86" >Reporter: Christian K. >Assignee: Robert Scholte >Priority: Minor > > If http proxy is set, in case of error calling javadoc, the whole command > line call is dumped out on console. > This can reveal sensible information about personal proxy settings (user and > password) which are passed > via -J-Dhttp.proxyUser= and -J-Dhttp.proxyPassword= arguments to the javadoc > executable. > For example: > Command line was:"C:\Program > Files\IBM\WebSphere\AppServer\java\jre\..\bin\javadoc.exe" > -J-DproxyHost=urlofmyproxy -J-DproxyPort=8080 -J-Dhttp.proxySet=true > -J-Dhttp.proxyHost=urlofmyproxy -J-Dhttp.proxyPort=8080 > -J-Dhttp.nonProxyHosts="myinternalrepo" -J-Dhttp.proxyUser="FOO" > -J-Dhttp.proxyPassword="BAR" @options @packages > If this can be an issue, consider hiding these values in the dump. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-510) Investigate JavadocUtil.invokeMaven
[ https://issues.apache.org/jira/browse/MJAVADOC-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-510: Fix Version/s: (was: 3.0.1) 3.1.0 > Investigate JavadocUtil.invokeMaven > --- > > Key: MJAVADOC-510 > URL: https://issues.apache.org/jira/browse/MJAVADOC-510 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Stephen Connolly >Priority: Major > Fix For: 3.1.0 > > > Spotted while fine-tuning the Jenkinsfile builds. Unclear why Javadoc plugin > needs to fork Maven and whether it is doing it the correct way if the > requirement is actually valid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-516) Replace usage of deprecated HttpClient code
[
https://issues.apache.org/jira/browse/MJAVADOC-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-516:
Fix Version/s: (was: 3.0.1)
3.1.0
> Replace usage of deprecated HttpClient code
> ---
>
> Key: MJAVADOC-516
> URL: https://issues.apache.org/jira/browse/MJAVADOC-516
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
>Priority: Minor
> Fix For: 3.1.0
>
>
> Since HttpClient 4.3, classes like {{DefaultHttpClient}} [were
> deprecated|https://archive.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.3.x.txt]
> in favor of using builder classes to create immutable {{HttpClient}}
> instances. As a consequence, we should update the code to use the newer APIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-521) Add documentation information for GitHub
[ https://issues.apache.org/jira/browse/MJAVADOC-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482508#comment-16482508 ] Robert Scholte commented on MJAVADOC-521: - [~khmarbaise] is the branch ready to be merged? > Add documentation information for GitHub > > > Key: MJAVADOC-521 > URL: https://issues.apache.org/jira/browse/MJAVADOC-521 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6413) Redesign proxies in Settings
Robert Scholte created MNG-6413: --- Summary: Redesign proxies in Settings Key: MNG-6413 URL: https://issues.apache.org/jira/browse/MNG-6413 Project: Maven Issue Type: Task Components: Settings Reporter: Robert Scholte The design of proxies doesn't match the with the real world anymore. It is important that multiple protocols are supported, quite often handled by the same proxy. Also, the non-proxy is a global setting, not a per-proxy one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPLUGIN-323) create @Requirement annotation to replace @Component (should be deprecated)
[
https://issues.apache.org/jira/browse/MPLUGIN-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483529#comment-16483529
]
Robert Scholte commented on MPLUGIN-323:
Let's keep https://wiki.eclipse.org/Sisu/PlexusMigration in mind. To me
@Component to @Requirement is like @Named to @Inject ,so I'm not sure if this
would be an improvement.
> create @Requirement annotation to replace @Component (should be deprecated)
> ---
>
> Key: MPLUGIN-323
> URL: https://issues.apache.org/jira/browse/MPLUGIN-323
> Project: Maven Plugin Tools
> Issue Type: Wish
> Components: maven-plugin-annotations, maven-plugin-tools-javadoc
>Affects Versions: 3.5
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: 3.6
>
>
> injecting a Plexus component into a mojo is currently marked through
> {{@Component}} annotation (or {{@component}} javadoc tag)
> This "component" term is misleading for 2 reasons:
> 1. in plugin descriptor, it creates a {{}} XML element:
> http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html#class_requirement
> 2. in Plexus, injecting is marked with {{@Requirement}} annotation, when
> {{@Component}} is used to define a component:
> http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/
> This annotation creates great confusion for years, then even if Plexus is
> being dropped for javax.inject, fixing this misleading terms would be
> beneficial IMHO
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[ https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484254#comment-16484254 ] Robert Scholte commented on MNG-6415: - Nice catch. This might explain why packaging one of my springboot apps failed with 3.5.2 and not before. > Project Artifacts Cache does not retain the order of classpath entries. > --- > > Key: MNG-6415 > URL: https://issues.apache.org/jira/browse/MNG-6415 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.2 > Environment: Windows 7, JDK8u144 >Reporter: Seckin Onur SELAMET >Priority: Major > Labels: CLASSPATH > Attachments: > [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > > > Project artifact cache introduced does not retain the order of classpath > entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements contained. > In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. > > Possible fix is provided in comments section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484315#comment-16484315
]
Robert Scholte commented on MCOMPILER-343:
--
Can you try {{plexus-java 0.9.8}} (it currently the most recent version)
> Tests fail to compile in modularized project due to wrong module descriptor
> path being passed to plexus-java
>
>
> Key: MCOMPILER-343
> URL: https://issues.apache.org/jira/browse/MCOMPILER-343
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Guy Mahieu
>Priority: Major
>
> When running a maven build on a maven project that has a module-info file and
> that has tests to compile, the build fails with the following message:
> {quote}{{Execution default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to modu}}
> {{le descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> {quote}
> And I see that in the TestCompilerMojo class (line 273), the absolute output
> directory is passed in as the module descriptor, while in the compile of the
> production sources, the full path to the module-info.java file is passed in:
> ResolvePathsRequest request =
> ResolvePathsRequest.withStrings( testPath )
> .setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
>
> For completeness I should maybe also add that I have changed my dependencies
> for the compiler plugin to be able to use java 10 and depend on multi-release
> jars (like log4j2 2.11):
> {quote}{{}}
> \{{ }}
> \{{ org.ow2.asm}}
> \{{ asm}}
> \{{ 6.1.1 }}
> \{{ }}
> \{{ }}
> \{{ org.codehaus.plexus}}
> \{{ plexus-java}}
> \{{ 0.9.4 }}
> \{{ }}
> {{}}
> {quote}
>
> Full stacktrace:
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project dcm-nct-tcp-connector: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to modu}}
> {{le descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)}}
> \{{ at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)}}
> \{{ at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)}}
> \{{ 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:309)}}
> \{{ at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)}}
> \{{ at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)}}
> \{{ at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)}}
> \{{ at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)}}
> \{{ at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)}}
> \{{ 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:497)}}
> \{{ 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-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes}}
> \{{ at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)}}
> \{{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)}}
> \{{ ... 20 more}}
> {{Caused by: java.lang.RuntimeEx
[jira] [Updated] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-343:
-
Description:
When running a maven build on a maven project that has a module-info file and
that has tests to compile, the build fails with the following message:
{noformat}Execution default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
{noformat}
And I see that in the TestCompilerMojo class (line 273), the absolute output
directory is passed in as the module descriptor, while in the compile of the
production sources, the full path to the module-info.java file is passed in:
{code}
ResolvePathsRequest request =
ResolvePathsRequest.withStrings( testPath )
.setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
{code}
For completeness I should maybe also add that I have changed my dependencies
for the compiler plugin to be able to use java 10 and depend on multi-release
jars (like log4j2 2.11):
{code:xml}
org.ow2.asm
asm
6.1.1
org.codehaus.plexus
plexus-java
0.9.4
{code}
Full stacktrace:
{noformat}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
(default-testCompile) on project dcm-nct-tcp-connector: Execution
default-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:497)
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-testCompile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:285)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
Caused by: java.io.IOException: Invalid path to module descriptor:
D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
at
org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:87)
at
org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:281)
... 24 more
{noformat}
was:
When running a maven build on a maven project that has a mod
[jira] [Commented] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484523#comment-16484523
]
Robert Scholte commented on MCOMPILER-343:
--
I think I know what's happening here. The plexus-java is still in its 0.9-phase
and we've decided that the MainModuleDescriptor must point to the actual file,
not anymore to the directory containing the module descriptor.
Conclusion, you either have to path the compiler-plugin yourself or have to
wait a little bit for the next release. And I cannot give you a date for it,
just the hope it'll be in June.
> Tests fail to compile in modularized project due to wrong module descriptor
> path being passed to plexus-java
>
>
> Key: MCOMPILER-343
> URL: https://issues.apache.org/jira/browse/MCOMPILER-343
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Guy Mahieu
>Priority: Major
>
> When running a maven build on a maven project that has a module-info file and
> that has tests to compile, the build fails with the following message:
> {noformat}Execution default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> {noformat}
> And I see that in the TestCompilerMojo class (line 273), the absolute output
> directory is passed in as the module descriptor, while in the compile of the
> production sources, the full path to the module-info.java file is passed in:
> {code}
> ResolvePathsRequest request =
> ResolvePathsRequest.withStrings( testPath )
> .setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
> {code}
>
> For completeness I should maybe also add that I have changed my dependencies
> for the compiler plugin to be able to use java 10 and depend on multi-release
> jars (like log4j2 2.11):
> {code:xml}
>
>
> org.ow2.asm
> asm
> 6.1.1
>
>
> org.codehaus.plexus
> plexus-java
> 0.9.4
>
>
> {code}
>
> Full stacktrace:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project dcm-nct-tcp-connector: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:497)
> 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-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Defau
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[
https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484595#comment-16484595
]
Robert Scholte commented on MNG-6415:
-
With Maven the dependency resolution defines the order, there's no such thing
as wildcards, the order is always predictable. Depending on the way the
application is created it is possible to respect the order. With MNG-6025 that
order changed.
I do understand the claim from Thomas, especially when referring to a directory
instead of explicit jars, if you know that
[File.html#listFiles()|https://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles()]
says
{quote}There is no guarantee that the name strings in the resulting array will
appear in any specific order; they are not, in particular, guaranteed to appear
in alphabetical order.{quote}
Maven is a different story, it should not change the order if applications
relies on that (on purpose and on their own risk). Otherwise we should add an
option to randomize the order of the classpath.
> Project Artifacts Cache does not retain the order of classpath entries.
> ---
>
> Key: MNG-6415
> URL: https://issues.apache.org/jira/browse/MNG-6415
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.2
> Environment: Windows 7, JDK8u144
>Reporter: Seckin Onur SELAMET
>Priority: Major
> Labels: CLASSPATH
> Attachments:
> [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch
>
>
> Project artifacts cache does not retain the order of classpath entries.
> Wrong Object type used in implementation. HashSet can not guarantee the order
> of elements.
> In runtime ProjectArtifacts passed as LinkedHashSet already which is safe.
>
> Possible fix is provided in comments section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[
https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487809#comment-16487809
]
Robert Scholte commented on MNG-6415:
-
{quote}We have never documented this to be retained throughout.{quote}
Maybe not explicit, but surely implicit. The result of a build is consistent
which is possible because the order of jars stays the same. It is a known
practice that if you have classpath-order issues, you can put that dependency
more up in your pom.
Anyway, this is how dependency resolution worked for years, we're now hit by an
unintended change which can easily be fixed. Better to change the documentation
than to disappoint the projects that relied on this "bug/feature".
> Project Artifacts Cache does not retain the order of classpath entries.
> ---
>
> Key: MNG-6415
> URL: https://issues.apache.org/jira/browse/MNG-6415
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.2
> Environment: Windows 7, JDK8u144
>Reporter: Seckin Onur SELAMET
>Priority: Major
> Labels: CLASSPATH
> Attachments:
> [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch
>
>
> Project artifacts cache does not retain the order of classpath entries.
> Wrong Object type used in implementation. HashSet can not guarantee the order
> of elements.
> In runtime ProjectArtifacts passed as LinkedHashSet already which is safe.
>
> Possible fix is provided in comments section.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-519) IT detectLinks fails on Windows
[
https://issues.apache.org/jira/browse/MJAVADOC-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-519.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte (was: Karl Heinz Marbaise)
Fix Version/s: (was: 3.0.1)
> IT detectLinks fails on Windows
> ---
>
> Key: MJAVADOC-519
> URL: https://issues.apache.org/jira/browse/MJAVADOC-519
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: failing-javadoc-it.log
>
>
> [Currently|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commitdiff;h=e637834a1aecaaa835fe2cdcda67664156f3630d]
> the following IT is failing:
> {code}
> [windows-jdk9] [INFO] Passed: 35, Failed: 1, Errors: 0, Skipped: 0
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] The following builds failed:
> [windows-jdk9] [WARNING] * detectLinks\pom.xml
> [windows-jdk9] [INFO] -
> [windows-jdk9] [WARNING] Ignoring that 1 build failed.
> [windows-jdk9] [INFO]
>
> [windows-jdk9] [INFO] BUILD SUCCESS
> [windows-jdk9] [INFO] ---
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJAVADOC-521) Add documentation information for GitHub
[ https://issues.apache.org/jira/browse/MJAVADOC-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-521. --- Resolution: Fixed Fixed in [3df4a85a0c4e8b75d57a53e83007581c474e6253|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=3df4a85a0c4e8b75d57a53e83007581c474e6253] > Add documentation information for GitHub > > > Key: MJAVADOC-521 > URL: https://issues.apache.org/jira/browse/MJAVADOC-521 > Project: Maven Javadoc Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6157) org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/MNG-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490260#comment-16490260
]
Robert Scholte edited comment on MNG-6157 at 5/25/18 7:12 AM:
--
[~rfscholte], I'm able to reproduce this issue from command line.
!image-2018-05-25-11-05-24-862.png!
Here is the complete stack trace:
{noformat}
[ERROR] Failed to execute goal
com.portware:portware-maven-plugin:1.6:genIniFile (generate-ini) on project
pw-configdescriptors: Unable to retrieve component configurator
include-project-dependencies for configuration of mojo
com.portware:portware-maven-plugin:1.6:genIniFile:
java.util.NoSuchElementException
[ERROR] role:
org.codehaus.plexus.component.configurator.ComponentConfigurator
[ERROR] roleHint: include-project-dependencies
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
com.portware:portware-maven-plugin:1.6:genIniFile (generate-ini) on project
pw-configdescriptors: Unable to retrieve component configurator
include-project-dependencies for configuration of mojo
com.portware:portware-maven-plugin:1.6:genIniFile
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
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.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.PluginConfigurationException: Unable to
retrieve component configurator include-project-dependencies for configuration
of mojo com.portware:portwaremaven-plugin:1.6:genIniFile
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
(DefaultMavenPluginManager.java:670)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo
(DefaultMavenPluginManager.java:596)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:121)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
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:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcce
[jira] [Commented] (MNG-6157) org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/MNG-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490340#comment-16490340
]
Robert Scholte commented on MNG-6157:
-
[~sdyapa] key issue is this:
{noformat}
[ERROR] role:
org.codehaus.plexus.component.configurator.ComponentConfigurator
[ERROR] roleHint: include-project-dependencies
{noformat}
This might be a component that existed in Maven 2, but I'm not aware of its
existience in Maven 3. You should ask the maintainers of portware-maven-plugin
to update their code, this is not a Maven bug.
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> -
>
> Key: MNG-6157
> URL: https://issues.apache.org/jira/browse/MNG-6157
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Michael Vorburger
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: image-2018-05-25-11-05-24-862.png
>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=496944 (and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=510439) report an issue
> encountered in M2E which shows a
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException as the root caused by, so the underlying
> problem may be here in Maven core?
> May be a concurrency issue - could it be made more multi thread safe?
> {code}org.apache.maven.plugin.PluginExecutionException: Execution
> default-testResources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.1:testResources failed:
> Unable to load the mojo 'testResources' (or one of its required components)
> from the plugin 'org.apache.maven.plugins:maven-resources-plugin:3.0.1'
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:153)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1360)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:137)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBu
[jira] [Commented] (MNG-6157) org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException
[
https://issues.apache.org/jira/browse/MNG-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490426#comment-16490426
]
Robert Scholte commented on MNG-6157:
-
Be sure to add {{true}} to the port-maven-plugin, see
[https://maven.apache.org/guides/mini/guide-using-extensions.html]
If this doesn't help, please switch to the [user
mailinglist|https://maven.apache.org/mail-lists.html], because this topic has
nothing to do with the original issue anymore.
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> -
>
> Key: MNG-6157
> URL: https://issues.apache.org/jira/browse/MNG-6157
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: Michael Vorburger
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: IncludeProjectDependenciesComponentConfigurator.java,
> image-2018-05-25-11-05-24-862.png, image-2018-05-25-14-03-01-554.png,
> image-2018-05-25-14-03-45-626.png
>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=496944 (and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=510439) report an issue
> encountered in M2E which shows a
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException as the root caused by, so the underlying
> problem may be here in Maven core?
> May be a concurrency issue - could it be made more multi thread safe?
> {code}org.apache.maven.plugin.PluginExecutionException: Execution
> default-testResources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.1:testResources failed:
> Unable to load the mojo 'testResources' (or one of its required components)
> from the plugin 'org.apache.maven.plugins:maven-resources-plugin:3.0.1'
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:153)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1360)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:137)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at
> org.eclipse.core.interna
[jira] [Commented] (MCOMPILER-332) Java 10 not supported
[
https://issues.apache.org/jira/browse/MCOMPILER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490620#comment-16490620
]
Robert Scholte commented on MCOMPILER-332:
--
[~akorzhuev] your issue is diffferent, according to the stacktrace you're
having issues with the maven-shade-plugin, not with the maven-compiler-plugin.
> Java 10 not supported
> -
>
> Key: MCOMPILER-332
> URL: https://issues.apache.org/jira/browse/MCOMPILER-332
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 10, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
> Default locale: en_DK, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"
>Reporter: Troels Nørgaard
>Assignee: Robert Scholte
>Priority: Major
>
> Running on Java 10 on Mac OS X (Latest), compile and test-compile works at
> source/target/release level 9. However, setting the level to 10 causes an
> IllegalArgumentException from ASM, even if no local type inference code is
> present.
> Exception:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.:
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.parse(AsmModuleInfoParser.java:80)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.getModuleDescriptor(AsmModuleInfoParser.java:54)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:83)
> at
> org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:281)
> at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(
[jira] [Commented] (MCOMPILER-335) Update default source/target
[ https://issues.apache.org/jira/browse/MCOMPILER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491152#comment-16491152 ] Robert Scholte commented on MCOMPILER-335: -- Changing a default value means that there is actually no real default. Right now both source/ and arget have a value, otherwise the result depends on the JDK you use. Requiring to set source/target will be kind of painful for starters. The whole idea idea is that with a minimal pom you must be able to compile, test and package a standard java project. If people update this plugin without noticing the defaults have changed, the results can be dramatic. Hence, I suggest that if we change the default value, we must add a warning in case source/target or release are not explicitly set. > Update default source/target > > > Key: MCOMPILER-335 > URL: https://issues.apache.org/jira/browse/MCOMPILER-335 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Fred Bricon >Priority: Major > > default source/target have been set to 1.5 in 2010 (MCOMPILER-80). I think > it's about time to update the default. > 1.8 would be my preference, as 9 /10 would probably be a tad too ambitious. > But, since Maven requires at least Java 1.7 to run, 1.7 is probably the > safest option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-335) Update default source/target
[ https://issues.apache.org/jira/browse/MCOMPILER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491554#comment-16491554 ] Robert Scholte commented on MCOMPILER-335: -- I didn't mean dropping the value. source+target or release must be required parameters as they are right now, otherwise the results depend on the JDK version, that's not what I want. I'd prefer not to change the value, it is good enough to make a "Hello World" application. Developers should be motivated to always set this value, in case somebody decides in the future to change the default value (again). But _if_ we do, then go for the lowest version supported by the highest JDK. That would mean 1.6. > Update default source/target > > > Key: MCOMPILER-335 > URL: https://issues.apache.org/jira/browse/MCOMPILER-335 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Fred Bricon >Priority: Major > > default source/target have been set to 1.5 in 2010 (MCOMPILER-80). I think > it's about time to update the default. > 1.8 would be my preference, as 9 /10 would probably be a tad too ambitious. > But, since Maven requires at least Java 1.7 to run, 1.7 is probably the > safest option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-335) Update default source/target
[ https://issues.apache.org/jira/browse/MCOMPILER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491563#comment-16491563 ] Robert Scholte commented on MCOMPILER-335: -- If the value is dropped, we should break the build in my opinion if these values aren't set. But that's too painful for starters. So leaving the value to 1.5 is actually consistent, results are predictable and when developers need newer language features, they must set source/target or release anyway. Adding the hint how to set these values is probably already an improvement. > Update default source/target > > > Key: MCOMPILER-335 > URL: https://issues.apache.org/jira/browse/MCOMPILER-335 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Fred Bricon >Priority: Major > > default source/target have been set to 1.5 in 2010 (MCOMPILER-80). I think > it's about time to update the default. > 1.8 would be my preference, as 9 /10 would probably be a tad too ambitious. > But, since Maven requires at least Java 1.7 to run, 1.7 is probably the > safest option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MCOMPILER-335) Update default source/target
[ https://issues.apache.org/jira/browse/MCOMPILER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491603#comment-16491603 ] Robert Scholte commented on MCOMPILER-335: -- Yes, that's the only place I can think of. And if MNG-6065 gets implemented CI servers could fail if developers missed this hint. > Update default source/target > > > Key: MCOMPILER-335 > URL: https://issues.apache.org/jira/browse/MCOMPILER-335 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Fred Bricon >Priority: Major > > default source/target have been set to 1.5 in 2010 (MCOMPILER-80). I think > it's about time to update the default. > 1.8 would be my preference, as 9 /10 would probably be a tad too ambitious. > But, since Maven requires at least Java 1.7 to run, 1.7 is probably the > safest option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1497) Flag to select modulepath or classpath
[ https://issues.apache.org/jira/browse/SUREFIRE-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated SUREFIRE-1497: - Labels: jigsaw (was: ) > Flag to select modulepath or classpath > -- > > Key: SUREFIRE-1497 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1497 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.21.0 >Reporter: Stephen Colebourne >Priority: Major > Labels: jigsaw > Attachments: maven-issue4.zip > > > SUREFIRE-1262 added the ability to run tests using the modulepath, which is > great. However, as a library developer I cannot guarantee that the code will > be run on the modulepath, it might well be run on the classpath. > As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on > and off? This would allow a single pom.xml to run surefire twice, once with > the code on the modulepath and once with the code on the classpath, to ensure > that the behaviour always works however the code is run. (Other solutions to > achieve the same goal may be possible, but this seems the most obvious). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MCOMPILER-342) Unsupported class file major version 55
[
https://issues.apache.org/jira/browse/MCOMPILER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MCOMPILER-342:
Assignee: Robert Scholte
> Unsupported class file major version 55
> ---
>
> Key: MCOMPILER-342
> URL: https://issues.apache.org/jira/browse/MCOMPILER-342
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Mincong Huang
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: log.txt
>
>
> Maven compiler plugin does not support classes created by JDK 11 (major
> version 55). If you have classes created by JDK 11 in your classpath when
> using Maven Compiler, you've the following errors:
> {quote}
> Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project java-examples-dev-core: Execution
> default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed:
> Unsupported class file major version 55 -> [Help 1]
> {quote}
> See https://github.com/mincong-h/MCOMPILER-342 for reproduction
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-342) Unsupported class file major version 55
[
https://issues.apache.org/jira/browse/MCOMPILER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492892#comment-16492892
]
Robert Scholte commented on MCOMPILER-342:
--
asm is a transitive dependency via plexus-java. WIll update it.
> Unsupported class file major version 55
> ---
>
> Key: MCOMPILER-342
> URL: https://issues.apache.org/jira/browse/MCOMPILER-342
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Mincong Huang
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: log.txt
>
>
> Maven compiler plugin does not support classes created by JDK 11 (major
> version 55). If you have classes created by JDK 11 in your classpath when
> using Maven Compiler, you've the following errors:
> {quote}
> Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project java-examples-dev-core: Execution
> default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed:
> Unsupported class file major version 55 -> [Help 1]
> {quote}
> See https://github.com/mincong-h/MCOMPILER-342 for reproduction
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6419) Error if debug log enabled in multithreaded builds
[ https://issues.apache.org/jira/browse/MNG-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6419. --- Resolution: Duplicate Assignee: Robert Scholte > Error if debug log enabled in multithreaded builds > -- > > Key: MNG-6419 > URL: https://issues.apache.org/jira/browse/MNG-6419 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.3 > Environment: Maven 3.5.3 > Java 1.8.0_161 >Reporter: Stefan Mueller >Assignee: Robert Scholte >Priority: Major > > If running parallel builds of multi-module projects with enabled debug logs > Maven stops with an error durcing logging of output. > Command to reproduce: *mvn -X -T 5 clean install* > See the stacktrace below. > java.lang.NumberFormatException: For input string: "36m" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.lang.Integer.parseInt(Integer.java:580) > at java.lang.Integer.(Integer.java:867) > at > org.fusesource.jansi.AnsiPrintStream.filter(AnsiPrintStream.java:129) > at > org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:97) > at > org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107) > at > org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156) > at > org.slf4j.impl.MavenSimpleLogger.writeThrowable(MavenSimpleLogger.java:69) > at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:319) > at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295) > at org.slf4j.impl.SimpleLogger.error(SimpleLogger.java:593) > at > org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:309) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:194) > 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.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) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6419) Error if debug log enabled in multithreaded builds
[
https://issues.apache.org/jira/browse/MNG-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6419:
Description:
If running parallel builds of multi-module projects with enabled debug logs
Maven stops with an error durcing logging of output.
Command to reproduce: *mvn -X -T 5 clean install*
See the stacktrace below.
{noformat}
java.lang.NumberFormatException: For input string: "36m"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.(Integer.java:867)
at
org.fusesource.jansi.AnsiPrintStream.filter(AnsiPrintStream.java:129)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:97)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107)
at
org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156)
at
org.slf4j.impl.MavenSimpleLogger.writeThrowable(MavenSimpleLogger.java:69)
at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:319)
at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
at org.slf4j.impl.SimpleLogger.error(SimpleLogger.java:593)
at
org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:309)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
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.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)
{noformat}
was:
If running parallel builds of multi-module projects with enabled debug logs
Maven stops with an error durcing logging of output.
Command to reproduce: *mvn -X -T 5 clean install*
See the stacktrace below.
java.lang.NumberFormatException: For input string: "36m"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.(Integer.java:867)
at
org.fusesource.jansi.AnsiPrintStream.filter(AnsiPrintStream.java:129)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:97)
at
org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107)
at
org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156)
at
org.slf4j.impl.MavenSimpleLogger.writeThrowable(MavenSimpleLogger.java:69)
at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:319)
at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
at org.slf4j.impl.SimpleLogger.error(SimpleLogger.java:593)
at
org.apache.maven.cli.CLIReportingUtils.showError(CLIReportingUtils.java:138)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:309)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
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.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)
> Error if debug log enabled in multithreaded builds
> --
>
> Key: MNG-6419
> URL: https://issues.apache.org/jira/browse/MNG-6419
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
> Environment: Maven 3.5.3
> Java 1.8.0_161
>Reporter: Stefan Mueller
>Assignee: Robert Scholte
>Priority: Major
>
> If running parallel builds of multi-module projects with enabled debug logs
> Maven stops with an error durcing logging of output.
> Command to reproduce: *mvn -X -T 5 clean install*
> See the stacktrace below.
> {noformat}
> java.lang.NumberFormatException: For input s
[jira] [Closed] (MNG-6418) Parallel builds with empty local repository hang
[ https://issues.apache.org/jira/browse/MNG-6418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6418. --- Resolution: Duplicate Assignee: Robert Scholte > Parallel builds with empty local repository hang > > > Key: MNG-6418 > URL: https://issues.apache.org/jira/browse/MNG-6418 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.2 > Environment: Build on Windows or Linux (happens on both environments) > Java 1.8.0_161 > Company central Maven repo is Nexus Repository Manager >Reporter: Stefan Mueller >Assignee: Robert Scholte >Priority: Blocker > Attachments: maven-3.5.2-hang-dump.txt > > > Parallel builds of multi-module Projects using multiple threads (like mvn -T > 5 clean install) usually run fine if most or all dependencies already exist > in the local Maven repository. > If the local Maven repository is *empty*, such builds will sporadically hang. > The hang seems at random points but always related to downloading or > uploading artifacts from/to a central repo (in our case a company-wide Nexus > Repository Manager). > Using Maven *3.2.5* there are no such issues! > Parallel builds with an empty repository are especially important for the CI > builds on Jenkins, as Jenkins uses a fresh new job-local repository for each > build. This leads to most Jenkins build hang after upgrading from Maven 3.2.5 > to 3.5.2. > See the attached thread-dump while hanging (seems to be related to > org.eclipse.aether.connector.basic.PartialFile$LockFile) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MCOMPILER-341) Compile module-info.java files located in test sources
[
https://issues.apache.org/jira/browse/MCOMPILER-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-341.
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.7.1
Fixed in
[c2d6a4bc977a17caf280809f6b8d95f603e67ae4|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=c2d6a4bc977a17caf280809f6b8d95f603e67ae4]
> Compile module-info.java files located in test sources
> --
>
> Key: MCOMPILER-341
> URL: https://issues.apache.org/jira/browse/MCOMPILER-341
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.7.0
>Reporter: Christian Stein
>Assignee: Robert Scholte
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.7.1
>
>
> Support compilation of projects with test sources containing modules – along
> with explicit module descriptors ({{module-info.java}} files).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-330) Add java.* JPMS modules for testing only is hard
[
https://issues.apache.org/jira/browse/MCOMPILER-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499037#comment-16499037
]
Robert Scholte commented on MCOMPILER-330:
--
I'm still looking for a proper solution. Fact is that you have to specify it
somewhere, either in the pom or a separate file (to be interpreted by the
plugin). I don't think there's a 100% reliable solution by scanning the sources
and it would probably overcomplicate things for rare cases.
With MCOMPILER-341 being merged you could solve it with a module descriptor in
the test source directory, which must be an extended version of the one in the
main sources directory.
One option I'd like to investigate is doing it with a {{META-INF/jpms.args}}
which is already generated when there are additional arguments.
> Add java.* JPMS modules for testing only is hard
>
>
> Key: MCOMPILER-330
> URL: https://issues.apache.org/jira/browse/MCOMPILER-330
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.7.0
> Environment: Windows 10, Maven v3.5.2
>Reporter: Stephen Colebourne
>Priority: Major
> Attachments: maven-issue3.zip
>
>
> Attached is a project demonstrating this issue (which affects both compiler
> and surefire). The basic problem here is where the project depends on a
> java.* module for testing but not at compile time. For example, the test code
> depends on `java.desktop` module, but the main code does not.
> While this has similarities with MCOMPILER-320 it is different because there
> is no way to refer to the `java.*` JPMS modules as dependencies.
> Right now the workaround is to add both --add-modules and --add-reads, as
> shown in the attachment. This is painful low-level stuff that Maven should be
> hiding the user from.
> NOTE: the attachment will succeed when run. Delete the compiler/surefire
> plugin config to see the issue.
> Rather than tackle this problem directly, my preference would be to have a
> module-patch.java file that allows users to declare additional
> dependencies/exports/services that only apply at testing time. This would be
> interpreted whenever --patch-module is being used. (As well as the example
> explained here, I've also run into the need to export packages that only
> exist in tests, and this currently also requires low-level argLine
> manipulation).
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MCOMPILER-342) Unsupported class file major version 55
[
https://issues.apache.org/jira/browse/MCOMPILER-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-342.
Resolution: Fixed
Fix Version/s: 3.7.1
Fixed in
[3e8d8af5131315f0d831f9f4a77a8a5f58b31ac9|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=3e8d8af5131315f0d831f9f4a77a8a5f58b31ac9]
> Unsupported class file major version 55
> ---
>
> Key: MCOMPILER-342
> URL: https://issues.apache.org/jira/browse/MCOMPILER-342
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Mincong Huang
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 3.7.1
>
> Attachments: log.txt
>
>
> Maven compiler plugin does not support classes created by JDK 11 (major
> version 55). If you have classes created by JDK 11 in your classpath when
> using Maven Compiler, you've the following errors:
> {quote}
> Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project java-examples-dev-core: Execution
> default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile failed:
> Unsupported class file major version 55 -> [Help 1]
> {quote}
> See https://github.com/mincong-h/MCOMPILER-342 for reproduction
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MCOMPILER-332) Java 10 not supported
[
https://issues.apache.org/jira/browse/MCOMPILER-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-332.
Resolution: Fixed
Fix Version/s: 3.7.1
> Java 10 not supported
> -
>
> Key: MCOMPILER-332
> URL: https://issues.apache.org/jira/browse/MCOMPILER-332
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /opt/local/share/java/maven3
> Java version: 10, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home
> Default locale: en_DK, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.3", arch: "x86_64", family: "mac"
>Reporter: Troels Nørgaard
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
>
> Running on Java 10 on Mac OS X (Latest), compile and test-compile works at
> source/target/release level 9. However, setting the level to 10 causes an
> IllegalArgumentException from ASM, even if no local type inference code is
> present.
> Exception:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.:
> IllegalArgumentException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project company-example-domain: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.IllegalArgumentException
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at org.objectweb.asm.ClassReader.(Unknown Source)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.parse(AsmModuleInfoParser.java:80)
> at
> org.codehaus.plexus.languages.java.jpms.AsmModuleInfoParser.getModuleDescriptor(AsmModuleInfoParser.java:54)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:83)
> at
> org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths(TestCompilerMojo.java:281)
> at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:762)
> at
> org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:176)
> at
>
[jira] [Updated] (MCOMPILER-286) Detect if dependencies should be added to classpath or modulpath
[ https://issues.apache.org/jira/browse/MCOMPILER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MCOMPILER-286: - Fix Version/s: 3.7.0 > Detect if dependencies should be added to classpath or modulpath > > > Key: MCOMPILER-286 > URL: https://issues.apache.org/jira/browse/MCOMPILER-286 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.6.0, 3.6.1 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Labels: jigsaw > Fix For: 3.7.0 > > > With 3.6.0 if the project is a module all the dependencies end up on the > modulepath. > It would be better to analyze every module-info.class (requires up to date > ASM) and verify per dependency if it is part of the module requirements (both > direct and transitive). The rest ends up on the classpath. > Auto modules are a special chapter. Right now I would ignore auto modules to > prevent collisions. Instead one could define the G:As explicitly to be added > to the modulePath. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MCOMPILER-343) Tests fail to compile in modularized project due to wrong module descriptor path being passed to plexus-java
[
https://issues.apache.org/jira/browse/MCOMPILER-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-343.
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.7.1
> Tests fail to compile in modularized project due to wrong module descriptor
> path being passed to plexus-java
>
>
> Key: MCOMPILER-343
> URL: https://issues.apache.org/jira/browse/MCOMPILER-343
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Guy Mahieu
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
>
> When running a maven build on a maven project that has a module-info file and
> that has tests to compile, the build fails with the following message:
> {noformat}Execution default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> {noformat}
> And I see that in the TestCompilerMojo class (line 273), the absolute output
> directory is passed in as the module descriptor, while in the compile of the
> production sources, the full path to the module-info.java file is passed in:
> {code}
> ResolvePathsRequest request =
> ResolvePathsRequest.withStrings( testPath )
> .setMainModuleDescriptor( *mainOutputDirectory.getAbsolutePath()* );
> {code}
>
> For completeness I should maybe also add that I have changed my dependencies
> for the compiler plugin to be able to use java 10 and depend on multi-release
> jars (like log4j2 2.11):
> {code:xml}
>
>
> org.ow2.asm
> asm
> 6.1.1
>
>
> org.codehaus.plexus
> plexus-java
> 0.9.4
>
>
> {code}
>
> Full stacktrace:
> {noformat}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project dcm-nct-tcp-connector: Execution
> default-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> 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:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:497)
> 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-testCompile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile failed:
> java.io.IOException: Invalid path to module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 20 more
> Caused by: java.lang.RuntimeException: java.io.IOException: Invalid path to
> module descriptor:
> D:\projects\DCM\dcm-nct-tcp-connector-c.v-SNAPSHOT\target\classes
> at
> or
[jira] [Updated] (MCOMPILER-321) Problematic Java 9 modules are silently ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MCOMPILER-321:
-
Fix Version/s: 3.7.1
> Problematic Java 9 modules are silently ignored
> ---
>
> Key: MCOMPILER-321
> URL: https://issues.apache.org/jira/browse/MCOMPILER-321
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Marcel Kolsteren
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: maven-compiler-plugin-bug.zip
>
>
> Before the compilation starts, the compiler plugin prepares the module path
> and the class path. Unfortunately, this process is very lenient. If the
> plugin cannot find a module that is specified in the module-info file, it
> doesn't report this problem, and it just carries on. In the end, the compiler
> will give a "module not found", giving no clue about the root cause.
> As an example, I attached a simple maven project with a module info file that
> refers to an automatic module named {{jython-standalone}}. The dependencies
> contain a jar file {{jython-standalone-2.7.0.jar}}. That jar file contains no
> module information, and it would normally be resolvable as an automatic
> module. However, when building the project, the Java compiler fails with this
> error:
> {{module not found: jython.standalone}}
> The root cause of the error is that the jar file contains a class at top
> level, which is illegal for a module. So, the error message "module not
> found" is misleading.
> I think this is a bug, because the maven-compiler-plugin fails to perform its
> task of building a correct module path, but doesn't tell, and just carries
> on. Instead, it should stop, and give an informative error message.
> Relevant source code:
> * [https://github.com/apache/maven-compiler-plugin], class {{CompilerMojo}}
> * [https://github.com/codehaus-plexus/plexus-languages], class
> {{LocationManager}} and {{MainClassModuleNameExtractor}}
> *
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html]
> The {{MainClassModuleNameExtractor}} uses the {{ModuleFinder}} class of the
> JDK to find modules. I think that these two error situations should lead to
> an error and a clear description of possible causes:
> * {{ModuleFinder#findAll}} returns an empty set.
> * {{ModuleFinder#findAll}} results in a {{FindException}}. When this happens
> is well documented in the {{ModuleFinder#of}} method. This exception is
> currently swallowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MCOMPILER-311) NPE when --patch-module is used
[
https://issues.apache.org/jira/browse/MCOMPILER-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-311.
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.7.1
Fixed in
[e258b6572a31496c8a10cd3d3d035b2da12a343e|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=e258b6572a31496c8a10cd3d3d035b2da12a343e]
> NPE when --patch-module is used
> ---
>
> Key: MCOMPILER-311
> URL: https://issues.apache.org/jira/browse/MCOMPILER-311
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Java 10 in Windows 10
>Reporter: Zhihong Zhang
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
>
> When "--patch-module" argument is added to the compiler, the plugin always
> throws NullPointerException. For example,
> {code:xml}
>
> --patch-module
> java.xml.ws.annotation=jsr305-3.0.1.jar
>
> {code}
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1004)
> at
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> {code}
> The bug is caused by an unimplemented method in CompilerMOJO.java,
> {code:title=CompilerMOJO.java|borderStyle=solid}
> @Override
> protected Map getPathElements()
> {
> // TODO Auto-generated method stub
> return null;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MCOMPILER-321) Problematic Java 9 modules are silently ignored
[
https://issues.apache.org/jira/browse/MCOMPILER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-321.
Resolution: Fixed
Assignee: Robert Scholte
Fixed in
[ce26802e6cc93320267482cc7c3a1947bfc34be6|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=ce26802e6cc93320267482cc7c3a1947bfc34be6]
> Problematic Java 9 modules are silently ignored
> ---
>
> Key: MCOMPILER-321
> URL: https://issues.apache.org/jira/browse/MCOMPILER-321
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Marcel Kolsteren
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.1
>
> Attachments: maven-compiler-plugin-bug.zip
>
>
> Before the compilation starts, the compiler plugin prepares the module path
> and the class path. Unfortunately, this process is very lenient. If the
> plugin cannot find a module that is specified in the module-info file, it
> doesn't report this problem, and it just carries on. In the end, the compiler
> will give a "module not found", giving no clue about the root cause.
> As an example, I attached a simple maven project with a module info file that
> refers to an automatic module named {{jython-standalone}}. The dependencies
> contain a jar file {{jython-standalone-2.7.0.jar}}. That jar file contains no
> module information, and it would normally be resolvable as an automatic
> module. However, when building the project, the Java compiler fails with this
> error:
> {{module not found: jython.standalone}}
> The root cause of the error is that the jar file contains a class at top
> level, which is illegal for a module. So, the error message "module not
> found" is misleading.
> I think this is a bug, because the maven-compiler-plugin fails to perform its
> task of building a correct module path, but doesn't tell, and just carries
> on. Instead, it should stop, and give an informative error message.
> Relevant source code:
> * [https://github.com/apache/maven-compiler-plugin], class {{CompilerMojo}}
> * [https://github.com/codehaus-plexus/plexus-languages], class
> {{LocationManager}} and {{MainClassModuleNameExtractor}}
> *
> [https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html]
> The {{MainClassModuleNameExtractor}} uses the {{ModuleFinder}} class of the
> JDK to find modules. I think that these two error situations should lead to
> an error and a clear description of possible causes:
> * {{ModuleFinder#findAll}} returns an empty set.
> * {{ModuleFinder#findAll}} results in a {{FindException}}. When this happens
> is well documented in the {{ModuleFinder#of}} method. This exception is
> currently swallowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MRESOLVER-46) Add support InputStream/OutputStream transformers
Robert Scholte created MRESOLVER-46: --- Summary: Add support InputStream/OutputStream transformers Key: MRESOLVER-46 URL: https://issues.apache.org/jira/browse/MRESOLVER-46 Project: Maven Resolver Issue Type: New Feature Reporter: Robert Scholte Assignee: Robert Scholte There are several ideas to generate new files based on the pom or even rewrite/optimize the pom file itself . At this time Maven Resolver always falls back to a file. The generated file must be reliable, so there should be no need for temporary storage as a file (which could be adjusted by some). Instead is must be possible to specify Stream Filters, so the transformation is done in memory. Register once, picked up for both install/deploy -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507359#comment-16507359
]
Robert Scholte commented on MNG-6391:
-
I thought the conclusion was: only drop the version from the last line, keep
the first one. In case the version is different compared to its parent the
version will be added to the summary too. I'd prefer to keep the version after
the module line when required.
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEP-617) Use plexus-java for showing module info during dependency:resolve
Robert Scholte created MDEP-617: --- Summary: Use plexus-java for showing module info during dependency:resolve Key: MDEP-617 URL: https://issues.apache.org/jira/browse/MDEP-617 Project: Maven Dependency Plugin Issue Type: Dependency upgrade Components: resolve Affects Versions: 3.1.1 Reporter: Robert Scholte Assignee: Robert Scholte The base for plexus-java was in this project. That library is now much stronger so the code should be replaced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MENFORCER-303) Upgrade mave-surefire/failsafe-plugin 2.21.0
[ https://issues.apache.org/jira/browse/MENFORCER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MENFORCER-303. Resolution: Fixed Assignee: Robert Scholte (was: Karl Heinz Marbaise) Fixed in [8b7c40a778bc14cba433a5e917857a1ef071a0f2|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=8b7c40a778bc14cba433a5e917857a1ef071a0f2] > Upgrade mave-surefire/failsafe-plugin 2.21.0 > > > Key: MENFORCER-303 > URL: https://issues.apache.org/jira/browse/MENFORCER-303 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte >Priority: Blocker > Fix For: 3.0.0 > > > For JDK 10 also Mockito must be updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MENFORCER-268) Usage of CI friendly version placeholders does not work
[
https://issues.apache.org/jira/browse/MENFORCER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-268:
-
Fix Version/s: 3.0.0-M2
> Usage of CI friendly version placeholders does not work
> ---
>
> Key: MENFORCER-268
> URL: https://issues.apache.org/jira/browse/MENFORCER-268
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 1.4.1, 3.0.0-M1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0-M2, 3.0.0
>
>
> If I use the placeholders in a project based on the [CI
> Friendly|http://maven.apache.org/maven-ci-friendly.html] currently
> maven-enforcer-plugin fails like this:
> {code}
> [INFO] --- flatten-maven-plugin:1.0.0:clean (flatten.clean) @ domain ---
> [INFO] Deleting /Users/kama/ws-git/javaee/domain/.flattened-pom.xml
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven) @ domain ---
> Downloading:
> http://localhost:8081/nexus/content/groups/public/com/soebes/examples/j2ee/parent/$%7Brevision%7D$%7Bsha1%7D$%7Bchangelist%7D/parent-$%7Brevision%7D$%7Bsha1%7D$%7Bchangelist%7D.pom
> [WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireNoRepositories
> failed with message:
> Could not find artifact
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist} in nexus
> (http://localhost:8081/nexus/content/groups/public)
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist}
> from the specified remote repositories:
> nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
> snapshots=true)
> [WARNING] Rule 4: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist} in
> http://localhost:8081/nexus/content/groups/public was cached in the local
> repository, resolution will not be reattempted until the update interval of
> nexus has elapsed or updates are forced
> com.soebes.examples.j2ee:parent:pom:${revision}${sha1}${changelist}
> from the specified remote repositories:
> nexus (http://localhost:8081/nexus/content/groups/public, releases=true,
> snapshots=true)
> {code}
> This is currently based on reading the pom file itself instead of using the
> parts which are offered via Maven Core...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MENFORCER-299) Failure with ${revision}
[
https://issues.apache.org/jira/browse/MENFORCER-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-299.
Resolution: Duplicate
Assignee: Robert Scholte
Fix Version/s: (was: 3.0.0)
> Failure with ${revision}
>
>
> Key: MENFORCER-299
> URL: https://issues.apache.org/jira/browse/MENFORCER-299
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Karl Heinz Marbaise
>Assignee: Robert Scholte
>Priority: Blocker
>
> Currently the build fail in case of usage of the {{${revision}}}
> {code}
> [WARNING] Rule 2: org.apache.maven.plugins.enforcer.RequirePluginVersions
> failed with message:
> Failure to find io.x.parent:parent:pom:${revision} in
> http://localhost:8081/nexus/content/groups/public was cached in the local
> repository, resolution will not be reattempted until the update interval of
> nexus has elapsed or updates are forced
> io..parent:parent:pom:${revision}
> {code}
> {code}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce
> (enforce-maven) on project conference-root: Some Enforcer rules have failed.
> Look above for specific messages explaining why the rule failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> 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.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.MojoExecutionException: Some Enforcer
> rules have failed. Look above for specific messages explaining why the rule
> failed.
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:243)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImp
[jira] [Closed] (SCM-890) scm-provider-gitexe do not find the repository on latest version
[
https://issues.apache.org/jira/browse/SCM-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SCM-890.
--
Resolution: Not A Problem
Assignee: Robert Scholte
> scm-provider-gitexe do not find the repository on latest version
>
>
> Key: SCM-890
> URL: https://issues.apache.org/jira/browse/SCM-890
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 1.10.0
>Reporter: Charlie Mordant
>Assignee: Robert Scholte
>Priority: Major
>
> Using the latest version, gitexe isn't able to find remote git repository
> (works with 1.8.1).
> I'm using ssh key, do not work with either release or site
> wagon-scm:3.1.0
> {code:java}
> // code placeholder
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare from plugin realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-release-plugin:2.5.3,
> parent: java.net.URLClassLoader@4a574795]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare' with basic
> configurator -->
> [DEBUG] (f) addSchema = true
> [DEBUG] (f) allowReleasePluginSnapshot = false
> [DEBUG] (f) allowTimestampedSnapshots = false
> [DEBUG] (f) autoVersionSubmodules = true
> [DEBUG] (s) basedir = /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] (f) commitByProject = false
> [DEBUG] (f) dryRun = false
> [DEBUG] (f) generateReleasePoms = false
> [DEBUG] (f) javaHome = /usr/lib/jvm/java-8-openjdk-amd64/jre
> [DEBUG] (f) mavenExecutorId = invoker
> [DEBUG] (f) mavenHome =
> /var/lib/jenkins/.m2/wrapper/dists/apache-maven-3.5.3-bin/2c22a6s60afpuloj4v181qvild/apache-maven-3.5.3
> [DEBUG] (f) preparationGoals = clean verify
> [DEBUG] (f) project = MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml
> [DEBUG] (f) projectVersionPolicyId = default
> [DEBUG] (f) pushChanges = true
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.yyy.tce.service.project:project:0.0.1-SNAPSHOT @
> /var/lib/jenkins/workspace/xxx/project-int-deployment/pom.xml]
> [DEBUG] (f) remoteTagging = true
> [DEBUG] (f) resume = true
> [DEBUG] (f) scmCommentPrefix = [ci-skip][maven-release-plugin]
> [DEBUG] (f) session = org.apache.maven.execution.MavenSession@44c5a16f
> [DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7a6ebe1e
> [DEBUG] (f) suppressCommitBeforeTag = false
> [DEBUG] (f) tagNameFormat = @{project.artifactId}-@{project.version}
> [DEBUG] (f) updateDependencies = true
> [DEBUG] (f) updateWorkingCopyVersions = true
> [DEBUG] (f) useEditMode = false
> [DEBUG] (f) waitBeforeTagging = 0
> [DEBUG] -- end configuration --
> [INFO] Resuming release from phase 'scm-commit-release'
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git add -- pom.xml
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git rev-parse
> --show-prefix
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git status
> --porcelain .
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [DEBUG] ?? pom.xml.releaseBackup
> [WARNING] Ignoring unrecognized line: ?? pom.xml.releaseBackup
> [DEBUG] ?? release.properties
> [WARNING] Ignoring unrecognized line: ?? release.properties
> [INFO] Tagging release with the label project-0.0.1...
> [DEBUG] ScmTagPhase :: scmTagParameters remotingTag true
> [DEBUG] ScmTagPhase :: scmTagParameters scmRevision null
> [DEBUG] ScmTagPhase :: fileSet basedir =
> /var/lib/jenkins/workspace/xxx/project-int-deployment; files = []
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git tag -F
> /tmp/maven-scm-2076768482.commit project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO] Executing: /bin/sh -c cd
> /var/lib/jenkins/workspace/xxx/project-int-deployment && git push
> git@xxx:tiss/xxx/xxx.git refs/tags/project-0.0.1
> [INFO] Working directory:
> /var/lib/jenkins/workspace/xxx/project-int-deployment
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.271 s
> [INFO] Finished at: 2018-06-12T18:01:37+02:00
> [INFO]
> ---
[jira] [Commented] (MPLUGIN-341) Make the plugin tool modular or at least module-ready
[
https://issues.apache.org/jira/browse/MPLUGIN-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514158#comment-16514158
]
Robert Scholte commented on MPLUGIN-341:
The usage of {{Automatic-Module-Name}} should only be used if the project is
Java 9 ready, but its dependencies don't have a module name yet. Both are not
in place for Maven and I don't expect it to happen. The only possibility to
solve the split packages issues is to make a monolith of it again, which is
exactly the opposite of modularization. And the most interesting Maven module
is maven-compat, which will always cause split packages, and we don't want them
to return in the base code.
If Maven wants to use Java modularization, it has to be rewritten with new
packages. That would imply that *all* current plugins become useless and must
be rewritten as well.
Java modules don't add much regarding reliable configuration compared to Maven.
Strong encapsulation would be cool, but that only works in combination with the
module-descriptor.
> Make the plugin tool modular or at least module-ready
> -
>
> Key: MPLUGIN-341
> URL: https://issues.apache.org/jira/browse/MPLUGIN-341
> Project: Maven Plugin Tools
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Lukas Eder
>Priority: Critical
>
> When implementing custom maven modules, it is currently not possible to make
> those plugins modular on JDK 9+. The reason for this is that there are a lot
> of split packages among the various libraries, such as the
> org.apache.maven.plugin package between:
> * org.apache.maven:maven-core:3.5.3
> * org.apache.maven:maven-plugin-api:3.5.3
> This, and the fact that there are not Automatic-Module-Name entries in the
> manifests (see
> [http://branchandbound.net/blog/java/2017/12/automatic-module-name/),] means
> that no one can currently reasonably create modular maven plugins.
> It would be cool if these two things could be fixed in the next minor or
> major release
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPLUGIN-341) Make the plugin tool modular or at least module-ready
[ https://issues.apache.org/jira/browse/MPLUGIN-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MPLUGIN-341: --- Priority: Minor (was: Critical) > Make the plugin tool modular or at least module-ready > - > > Key: MPLUGIN-341 > URL: https://issues.apache.org/jira/browse/MPLUGIN-341 > Project: Maven Plugin Tools > Issue Type: Improvement >Affects Versions: 3.5.2 >Reporter: Lukas Eder >Priority: Minor > > When implementing custom maven modules, it is currently not possible to make > those plugins modular on JDK 9+. The reason for this is that there are a lot > of split packages among the various libraries, such as the > org.apache.maven.plugin package between: > * org.apache.maven:maven-core:3.5.3 > * org.apache.maven:maven-plugin-api:3.5.3 > This, and the fact that there are not Automatic-Module-Name entries in the > manifests (see > [http://branchandbound.net/blog/java/2017/12/automatic-module-name/),] means > that no one can currently reasonably create modular maven plugins. > It would be cool if these two things could be fixed in the next minor or > major release -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-3525) Settings.xml allowing mirror definitions inside profiles
[ https://issues.apache.org/jira/browse/MNG-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-3525: Fix Version/s: (was: Issues to be reviewed for 3.x) Issues to be reviewed for 4.x > Settings.xml allowing mirror definitions inside profiles > > > Key: MNG-3525 > URL: https://issues.apache.org/jira/browse/MNG-3525 > Project: Maven > Issue Type: Improvement > Components: Profiles >Affects Versions: 2.0.9 > Environment: N/A >Reporter: Paul Gribben >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > I currently use Maven in 2 places > 1. At work > 2. Not at work > At work we have a repository manager thus we have mirror properties in the > settings.xml for the whole teams global settings. We also have a defined a > number of repositories in our work profile so we can mirror these to > different repo's managed by Archiva. Now when I work from home I have to > comment out the mirror definitions and activate a home profile which does not > define any repos so Maven just goes out to the WWW as normal. So the pain is > having to comment out and un-comment the mirror settings every time I go from > work to home and visa-versa. > Can we not have the option to add mirrors inside profiles? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-3525) Settings.xml allowing mirror definitions inside profiles
[ https://issues.apache.org/jira/browse/MNG-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MNG-3525: Component/s: Settings > Settings.xml allowing mirror definitions inside profiles > > > Key: MNG-3525 > URL: https://issues.apache.org/jira/browse/MNG-3525 > Project: Maven > Issue Type: Improvement > Components: Profiles, Settings >Affects Versions: 2.0.9 > Environment: N/A >Reporter: Paul Gribben >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > I currently use Maven in 2 places > 1. At work > 2. Not at work > At work we have a repository manager thus we have mirror properties in the > settings.xml for the whole teams global settings. We also have a defined a > number of repositories in our work profile so we can mirror these to > different repo's managed by Archiva. Now when I work from home I have to > comment out the mirror definitions and activate a home profile which does not > define any repos so Maven just goes out to the WWW as normal. So the pain is > having to comment out and un-comment the mirror settings every time I go from > work to home and visa-versa. > Can we not have the option to add mirrors inside profiles? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-3525) Settings.xml allowing mirror definitions inside profiles
[
https://issues.apache.org/jira/browse/MNG-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514179#comment-16514179
]
Robert Scholte commented on MNG-3525:
-
Changing the settings.xml will have a huge impact. One of the known issues is:
should still be called settings.xml, or should it contain the version? The
reason is that developers might have multiple versions of Maven ( I have all
3.0+ released version on my machine) which should share the same settings.xml.
Including the version implies duplication of configuration.
For now: better to have multiple settings.xml and use {{\-s/\-\-settings
}} or {{\-gs/\-\-global-settings }} to separate them per environment
> Settings.xml allowing mirror definitions inside profiles
>
>
> Key: MNG-3525
> URL: https://issues.apache.org/jira/browse/MNG-3525
> Project: Maven
> Issue Type: Improvement
> Components: Profiles, Settings
>Affects Versions: 2.0.9
> Environment: N/A
>Reporter: Paul Gribben
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> I currently use Maven in 2 places
> 1. At work
> 2. Not at work
> At work we have a repository manager thus we have mirror properties in the
> settings.xml for the whole teams global settings. We also have a defined a
> number of repositories in our work profile so we can mirror these to
> different repo's managed by Archiva. Now when I work from home I have to
> comment out the mirror definitions and activate a home profile which does not
> define any repos so Maven just goes out to the WWW as normal. So the pain is
> having to comment out and un-comment the mirror settings every time I go from
> work to home and visa-versa.
> Can we not have the option to add mirrors inside profiles?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6310) settings.xml allow proxy activation by expression
[
https://issues.apache.org/jira/browse/MNG-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516288#comment-16516288
]
Robert Scholte commented on MNG-6310:
-
I don't expect that any pom element will support expressions in Maven. However,
I've seen people writing their own extensions like
https://github.com/kpiwko/el-profile-activator-extension which might be a
solution already right now, although in the end I would prefer improvements on
the settings.xml
> settings.xml allow proxy activation by expression
> -
>
> Key: MNG-6310
> URL: https://issues.apache.org/jira/browse/MNG-6310
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap & Build
>Affects Versions: 3.5.2
>Reporter: Brett Randall
>Priority: Minor
>
> Currently it appears that {{settings.xml}} proxies can only be activated via
> a boolean {{active}} element, which does not appear to be evaluated, so you
> cannot use a property (e.g. set by a profile), nor a system or environment
> property.
> This comes up a lot on discussions from developers trying to automate whether
> Maven's proxies are enabled or not, based on a system or environment property
> etc.
> Possible solutions:
> * Change the model for (generate) {{Proxy.active}} allowing an expression to
> then be evaluated.
> * Copy {{profiles}} approach and add an {{}} element, but this
> requires a settings schema rev.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5901) Export org.eclipse.aether.util.artifact.SubArtifact
[
https://issues.apache.org/jira/browse/MNG-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516295#comment-16516295
]
Robert Scholte commented on MNG-5901:
-
Yes and no. maven-artifact-transfer contains a workaround that works. I
thinking about a new feature of the plugin API, which might superceed this
issue.
{code}
@Deliverable
private File targetFile; // can either be Path, File or String
@Deliverable ( classifier = "sources" )
private File attachedFile;
{code}
If Maven supports something like this, there's no need to expose the
(Sub)Artifact. Only in that case there's no need to fix this.
> Export org.eclipse.aether.util.artifact.SubArtifact
> ---
>
> Key: MNG-5901
> URL: https://issues.apache.org/jira/browse/MNG-5901
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3, 3.2.5, 3.3.1, 3.3.3
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> Without exporting {{org.eclipse.aether.util.artifact.SubArtifact}} you will
> get a {{ClassNotFoundException}} when trying to deploy/upload attachments
> using the pure Aether solution by Eclipse.
> This is also the reason why maven-artifact-transfer shades this class, so
> this component will still work with all Maven versions between 3.1.1 and 3.3.3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6175) Whitespace gets deleted in properties value text
[
https://issues.apache.org/jira/browse/MNG-6175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6175:
Description:
Leading and trailing whitespaces in the "pom.xml" get deleted.
Exemplary excerpt of a "pom.xml" file:
{code:xml}
1
{code}
Checking the "effective pom" results in:
{code:xml}
...
1
...
{code}
So the leading and trailing whitespaces have been deleted. [MNG-5380] states
this to be resolved since version 3.0.4.
was:
Leading and trailing whitespaces in the "pom.xml" get deleted.
Exemplary excerpt of a "pom.xml" file:
...
1
...
Checking the "effective pom" results in:
...
...
1
...
...
So the leading and trailing whitespaces have been deleted. [MNG-5380] states
this to be resolved since version 3.0.4.
> Whitespace gets deleted in properties value text
>
>
> Key: MNG-6175
> URL: https://issues.apache.org/jira/browse/MNG-6175
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.3.9
>Reporter: Jesko Jochum
>Priority: Minor
>
> Leading and trailing whitespaces in the "pom.xml" get deleted.
> Exemplary excerpt of a "pom.xml" file:
> {code:xml}
>
> 1
>
> {code}
> Checking the "effective pom" results in:
> {code:xml}
>
> ...
> 1
> ...
>
> {code}
> So the leading and trailing whitespaces have been deleted. [MNG-5380] states
> this to be resolved since version 3.0.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[
https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6112.
---
Resolution: Won't Fix
Assignee: Robert Scholte
Fix Version/s: (was: 3.6.x-candidate)
Closed as {{Won't Fix}} based on comments
> Central repository in the 4.0.0 super POM should declare update policy
> 'never'.
> ---
>
> Key: MNG-6112
> URL: https://issues.apache.org/jira/browse/MNG-6112
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0-beta-1
>Reporter: Christian Schulte
>Assignee: Robert Scholte
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6422) Maven by default does not check checksums; Maven lacks reproducible builds capability
[ https://issues.apache.org/jira/browse/MNG-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MNG-6422. --- Resolution: Duplicate Assignee: Robert Scholte Fix Version/s: (was: waiting-for-feedback) Kind of duplicate of MNG-5728, which will very likely be fixed in the next major version. > Maven by default does not check checksums; Maven lacks reproducible builds > capability > - > > Key: MNG-6422 > URL: https://issues.apache.org/jira/browse/MNG-6422 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Martin Vysny >Assignee: Robert Scholte >Priority: Major > > Maven by default does not check checksums of downloaded jar files. That leads > to ridiculous situations like for example when a misconfigured Artifactory > instance provides HTML directory listing instead of an actual jar file > (because of incorrect path or access denied or other reason). Maven should > reject such jar file (since it can't match the check sum), but instead it > happily stores it into the local repository and then later fails that it's > not a valid zip file. > This issue exposes something even worse - you actually can't have > reproducible builds with Maven since the reproducibility of the build depends > on whatever you have in your local .m2 repository. So for example the build > fails for me (since my local .m2 is populated by borked jar files which are > really html files), but it succeeds for my colleagues (simply because they > populated their local .m2 repo at different time and they have proper actual > jar files). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
