[jira] [Created] (MCOMPILER-547) NPE when --patch-module is used in non-module project
Robert Varga created MCOMPILER-547:
--
Summary: NPE when --patch-module is used in non-module project
Key: MCOMPILER-547
URL: https://issues.apache.org/jira/browse/MCOMPILER-547
Project: Maven Compiler Plugin
Issue Type: Bug
Affects Versions: 3.11.0, 3.10.1
Reporter: Robert Varga
Encountered while working on KARAF-7754:
{noformat}
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-compile of goal
org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile failed: Cannot
invoke "java.util.Map.get(Object)" because the return value of
"org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is
null
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:133)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
(SmartBuilderImpl.java:209)
at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
(SmartBuilderImpl.java:81)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:635)
at java.lang.Thread.run (Thread.java:833)
Caused by: java.lang.NullPointerException: Cannot invoke
"java.util.Map.get(Object)" because the return value of
"org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is
null
at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute
(AbstractCompilerMojo.java:1126)
at org.apache.maven.plugin.compiler.CompilerMojo.execute
(CompilerMojo.java:198)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject
(SmartBuilderImpl.java:209)
at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run
(SmartBuilderImpl.java:81)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:635)
at java.lang.Thread.run (Thread.java:833)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160197#comment-17160197
]
Robert Varga commented on SUREFIRE-1820:
Ah, sorry, --release takes a different argument than source/target:
{noformat}
nite@nitebug : ~/prj/maven-surefire on $ $JAVA_HOME/bin/javac --release 7
error: no source files
{noformat}
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
> at java.util.Scanner.hasNextLine(Scanner.java:1500)
> at
> org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
> {noformat}
> at least in the following configuration:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
> project pt-triemap: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
> test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
> /home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
> /home/nite/pt/triemap/pt-triemap/target/surefire
> 2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
> surefire_06735691049687446297tmp{noformat}
> Based on the discussion here:
> [https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
> cause is that surefire release was compiled with JDK9+ without setting
> --release to 8-or-lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160196#comment-17160196
]
Robert Varga commented on SUREFIRE-1820:
Yeah, for JDK11 targeting 1.7 is way too old:
{noformat}
nite@nitebug : ~$ $JAVA_HOME/bin/javac -version
javac 11.0.7
nite@nitebug : ~$ $JAVA_HOME/bin/javac --release 1.7
error: release version 1.7 not supported
Usage: javac
use --help for a list of possible options
nite@nitebug : ~$ $JAVA_HOME/bin/javac --release 8
error: no source files
{noformat}
so another option would be to downgrade the JDK used, for example to 8. I am
not sure what the driver behind using JDK11 is, though.
Baring that downgrade, though, there is another possibility:
{code:java}
int write( ByteBuffer src, boolean flush ) throws IOException {
Buffer compat = src;
// ...
compat.position( compat.limit() );
// ...
}{code}
which is very clunky, quite unreliable (need to hunt down all usages) and
unmaintainable in the long term :(
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
> at java.util.Scanner.hasNextLine(Scanner.java:1500)
> at
> org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
> {noformat}
> at least in the following configuration:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
> project pt-triemap: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
> test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
> /home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
> /home/nite/pt/triemap/pt-triemap/target/surefire
> 2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
> surefire_06735691049687446297tmp{noformat}
> Based on the discussion here:
> [https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
> cause is that surefire release was compiled with JDK9+ without setting
> --release to 8-or-lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160167#comment-17160167
]
Robert Varga commented on SUREFIRE-1820:
Yes, exactly – if the project is being built JDK is 9+ (I think you were using
JDK11 for 3.0.0-M5) – something like
[https://github.com/eclipse/jetty.project/blob/jetty-9.4.18.v20190429/pom.xml#L1843-L1858]
.
The problem is not the bytecode target:
{noformat}
nite@nitebug : ~/x$ file
./org/apache/maven/surefire/api/util/internal/AbstractNoninterruptibleWritableChannel.class
./org/apache/maven/surefire/api/util/internal/AbstractNoninterruptibleWritableChannel.class:
compiled Java class data, version 51.0 (Java 1.7)
{noformat}
but rather the library version observed by javac: without --release it will be
linking against JDK11, hence this call:
[https://github.com/apache/maven-surefire/blob/eb48f1b59ca5ccf6954ef33ecab03dbaf93214cd/surefire-api/src/main/java/org/apache/maven/surefire/api/util/internal/AbstractNoninterruptibleWritableChannel.java#L76]
will actually be linking to this method (i.e. a covariant override):
[https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/X-Buffer.java.template#L1364-L1368]
which was introduced as part of
[https://bugs.openjdk.java.net/browse/JDK-4774077]
This can be seen via 'javap -v':
{noformat}
nite@nitebug : ~/x$ javap -v
./org/apache/maven/surefire/api/util/internal/AbstractNoninterruptibleWritableChannel.class
Classfile
/home/nite/x/org/apache/maven/surefire/api/util/internal/AbstractNoninterruptibleWritableChannel.class
Last modified 10-Jun-2020; size 1862 bytes
MD5 checksum 367202c73bf1cedbf32c1e50987249bf
Compiled from "AbstractNoninterruptibleWritableChannel.java"
abstract class
org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel
implements
org.apache.maven.surefire.api.util.internal.WritableBufferedByteChannel
minor version: 0
major version: 51
flags: ACC_SUPER, ACC_ABSTRACT
[...]
int write(java.nio.ByteBuffer, boolean) throws java.io.IOException;
descriptor: (Ljava/nio/ByteBuffer;Z)I
flags:
Code:
stack=2, locals=4, args_size=3
0: aload_0
[...]
72: aload_1
73: aload_1
74: invokevirtual #16 // Method
java/nio/ByteBuffer.limit:()I
77: invokevirtual #17 // Method
java/nio/ByteBuffer.position:(I)Ljava/nio/ByteBuffer;
80: pop
81: iload_2
82: ifeq 89
85: aload_0
86: invokevirtual #18 // Method flushImpl:()V
89: iload_3
90: ireturn
{noformat}
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
>
[jira] [Commented] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157199#comment-17157199
]
Robert Varga commented on SUREFIRE-1820:
Specifically this comment:
[https://github.com/eclipse/jetty.project/issues/3244#issuecomment-495322586]
points towards using --release instead of source/target when building with
JDK9+, which should fix the issue even when building with newer JDK.
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
> at java.util.Scanner.hasNextLine(Scanner.java:1500)
> at
> org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
> {noformat}
> at least in the following configuration:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
> project pt-triemap: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
> test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
> /home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
> /home/nite/pt/triemap/pt-triemap/target/surefire
> 2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
> surefire_06735691049687446297tmp{noformat}
> Based on the discussion here:
> [https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
> cause is that surefire release was compiled with JDK9+ without setting
> --release to 8-or-lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated SUREFIRE-1820:
---
Description:
Attempting to use TCP channels for communication with JDK 1.8 results in the
following splat:
{noformat}
xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at
org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
at
org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
at
org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at
org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
at
org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
at
org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
at
org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.Reader.read(Reader.java:100)
at java.util.Scanner.readInput(Scanner.java:804)
at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
at java.util.Scanner.hasNextLine(Scanner.java:1500)
at
org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
{noformat}
at least in the following configuration:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
project pt-triemap: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
/home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
/home/nite/pt/triemap/pt-triemap/target/surefire
2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
surefire_06735691049687446297tmp{noformat}
Based on the discussion here:
[https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
cause is that surefire release was compiled with JDK9+ without setting
--release to 8-or-lower.
was:Attempting to use
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Dependency upgrade
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[
https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated SUREFIRE-1820:
---
Issue Type: Bug (was: Dependency upgrade)
> Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
>
>
> Key: SUREFIRE-1820
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1820
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
>Reporter: Robert Varga
>Priority: Major
>
> Attempting to use TCP channels for communication with JDK 1.8 results in the
> following splat:
> {noformat}
> xception in thread "commands-fork-1" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:76)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleWritableChannel.write(AbstractNoninterruptibleWritableChannel.java:44)
> at
> org.apache.maven.plugin.surefire.extensions.StreamFeeder.run(StreamFeeder.java:92)
> Exception in thread "fork-1-event-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.decode(EventConsumerThread.java:140)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:113)
> Exception in thread "fork-1-err-thread" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
> at
> org.apache.maven.surefire.api.util.internal.Channels$3.readImpl(Channels.java:217)
> at
> org.apache.maven.surefire.api.util.internal.AbstractNoninterruptibleReadableChannel.read(AbstractNoninterruptibleReadableChannel.java:54)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:274)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.Reader.read(Reader.java:100)
> at java.util.Scanner.readInput(Scanner.java:804)
> at java.util.Scanner.findWithinHorizon(Scanner.java:1685)
> at java.util.Scanner.hasNextLine(Scanner.java:1500)
> at
> org.apache.maven.surefire.extensions.util.LineConsumerThread.run(LineConsumerThread.java:67)
> {noformat}
> at least in the following configuration:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default) on
> project pt-triemap: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/nite/pt/triemap/pt-triemap/target/surefire-reports for the individual
> test results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/nite/pt/triemap/pt-triemap &&
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64/jre/bin/java -jar
> /home/nite/pt/triemap/pt-triemap/target/surefire/surefirebooter5389144270021152085.jar
> /home/nite/pt/triemap/pt-triemap/target/surefire
> 2020-07-14T09-05-53_813-jvmRun1 surefire4432899852251024839tmp
> surefire_06735691049687446297tmp{noformat}
> Based on the discussion here:
> [https://github.com/eclipse/jetty.project/issues/3244] , it would seem the
> cause is that surefire release was compiled with JDK9+ without setting
> --release to 8-or-lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[ https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SUREFIRE-1820: --- Description: Attempting to use > Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError > > > Key: SUREFIRE-1820 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1820 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: process forking >Affects Versions: 3.0.0-M5 >Reporter: Robert Varga >Priority: Major > > Attempting to use -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[ https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SUREFIRE-1820: --- Component/s: process forking > Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError > > > Key: SUREFIRE-1820 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1820 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: process forking >Affects Versions: 3.0.0-M5 >Reporter: Robert Varga >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[ https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SUREFIRE-1820: --- Affects Version/s: 3.0.0-M5 > Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError > > > Key: SUREFIRE-1820 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1820 > Project: Maven Surefire > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M5 >Reporter: Robert Varga >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1820) Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError
[ https://issues.apache.org/jira/browse/SUREFIRE-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Varga updated SUREFIRE-1820: --- Summary: Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError (was: Using TCP SurefireForkNodeFactory) > Using SurefireForkNodeFactory with JDK8 results in NoSuchMethodError > > > Key: SUREFIRE-1820 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1820 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Robert Varga >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1820) Using TCP SurefireForkNodeFactory
Robert Varga created SUREFIRE-1820: -- Summary: Using TCP SurefireForkNodeFactory Key: SUREFIRE-1820 URL: https://issues.apache.org/jira/browse/SUREFIRE-1820 Project: Maven Surefire Issue Type: Dependency upgrade Reporter: Robert Varga -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-649) javadoc:aggregate mis-determines whether a submodule was skipped
[
https://issues.apache.org/jira/browse/MJAVADOC-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated MJAVADOC-649:
--
Description:
The fix for MJAVADOC-613 ends up mis-detecting when a submodule is being
skipped in case there is an interplay between command-line and profile
activation.
In OpenDaylight we have a setup, where we have a profile doing roughly:
{code:java}
q
true
{code}
this profile is defined for each and every artifact we build.
We then have a job dedicated to extraction of javadoc which does:
{noformat}
mvn clean install javadoc:aggregate -e -Pq -Dmaven.javadoc.skip=false{noformat}
This works perfectly well with maven-javadoc-plugin-3.1.1, but breaks with
3.2.0: while each submodule generates its javadoc correctly (observing the
command-line override of the profile), the aggregate goal ends up skipping all
submodules, resulting in no aggregate being generated.
was:
The fix for MJAVADOC-613 ends up mis-detecting when a submodule is being
skipped in case there is an interplay between command-line and profile
activation.
In OpenDaylight we have a setup, where we have a profile doing roughly:
{code:java}
q
true
{code}
this profile is defined for each and every artifact we build.
We then have a job dedicated to extraction of javadoc which does:
{noformat}
mvn clean install javadoc:aggregate -e -Pq -Dmaven.javadoc.skip=false{noformat}
This works perfectly well with maven-javadoc-plugin-3.1.1, but breaks with
3.2.0: while each submodule generates is javadoc correctly (observing the
command-line override of the profile), the aggregate goal ends up skipping all
submodules, resulting in no aggregate being generated.
> javadoc:aggregate mis-determines whether a submodule was skipped
>
>
> Key: MJAVADOC-649
> URL: https://issues.apache.org/jira/browse/MJAVADOC-649
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Robert Varga
>Priority: Major
> Labels: regression
>
> The fix for MJAVADOC-613 ends up mis-detecting when a submodule is being
> skipped in case there is an interplay between command-line and profile
> activation.
> In OpenDaylight we have a setup, where we have a profile doing roughly:
> {code:java}
>
> q
>
> true
>
>
>
> {code}
> this profile is defined for each and every artifact we build.
> We then have a job dedicated to extraction of javadoc which does:
> {noformat}
> mvn clean install javadoc:aggregate -e -Pq
> -Dmaven.javadoc.skip=false{noformat}
> This works perfectly well with maven-javadoc-plugin-3.1.1, but breaks with
> 3.2.0: while each submodule generates its javadoc correctly (observing the
> command-line override of the profile), the aggregate goal ends up skipping
> all submodules, resulting in no aggregate being generated.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MJAVADOC-649) javadoc:aggregate mis-determines whether a submodule was skipped
[
https://issues.apache.org/jira/browse/MJAVADOC-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated MJAVADOC-649:
--
External issue URL: https://jira.opendaylight.org/browse/ODLPARENT-229
> javadoc:aggregate mis-determines whether a submodule was skipped
>
>
> Key: MJAVADOC-649
> URL: https://issues.apache.org/jira/browse/MJAVADOC-649
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Robert Varga
>Priority: Major
> Labels: regression
>
> The fix for MJAVADOC-613 ends up mis-detecting when a submodule is being
> skipped in case there is an interplay between command-line and profile
> activation.
> In OpenDaylight we have a setup, where we have a profile doing roughly:
> {code:java}
>
> q
>
> true
>
>
>
> {code}
> this profile is defined for each and every artifact we build.
> We then have a job dedicated to extraction of javadoc which does:
> {noformat}
> mvn clean install javadoc:aggregate -e -Pq
> -Dmaven.javadoc.skip=false{noformat}
> This works perfectly well with maven-javadoc-plugin-3.1.1, but breaks with
> 3.2.0: while each submodule generates is javadoc correctly (observing the
> command-line override of the profile), the aggregate goal ends up skipping
> all submodules, resulting in no aggregate being generated.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MJAVADOC-649) javadoc:aggregate mis-determines whether a submodule was skipped
Robert Varga created MJAVADOC-649:
-
Summary: javadoc:aggregate mis-determines whether a submodule was
skipped
Key: MJAVADOC-649
URL: https://issues.apache.org/jira/browse/MJAVADOC-649
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 3.2.0
Reporter: Robert Varga
The fix for MJAVADOC-613 ends up mis-detecting when a submodule is being
skipped in case there is an interplay between command-line and profile
activation.
In OpenDaylight we have a setup, where we have a profile doing roughly:
{code:java}
q
true
{code}
this profile is defined for each and every artifact we build.
We then have a job dedicated to extraction of javadoc which does:
{noformat}
mvn clean install javadoc:aggregate -e -Pq -Dmaven.javadoc.skip=false{noformat}
This works perfectly well with maven-javadoc-plugin-3.1.1, but breaks with
3.2.0: while each submodule generates is javadoc correctly (observing the
command-line override of the profile), the aggregate goal ends up skipping all
submodules, resulting in no aggregate being generated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816961#comment-16816961
]
Robert Varga commented on MJAVADOC-591:
---
Yes, I noticed that property. I agree, that was just the first cut before I
opened the project in an IDE :) The pull request is updated with a more correct
solution.
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816940#comment-16816940
]
Robert Varga commented on MJAVADOC-591:
---
Ah, right, it was just my local repo that got a candidate fix and there's no
3.1.1-SNAPSHOT in [http://repository.apache.org/snapshots/] and I did not
notice 'mvn -U' did not clear out my local version.
A candidate fix is here:
[https://github.com/apache/maven-javadoc-plugin/pull/25]
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816925#comment-16816925
]
Robert Varga commented on MJAVADOC-591:
---
It seems to work with 3.1.1-SNAPSHOT.
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16815912#comment-16815912
]
Robert Varga commented on MJAVADOC-591:
---
Since maven.compiler.release overrides maven.compiler.source, and '–release'
overrides '-source' in javac, it seems logical to default 'source' to the same
value as 'release'. It certainly fixes the issue in local testing.
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
[
https://issues.apache.org/jira/browse/MJAVADOC-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated MJAVADOC-591:
--
Description:
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1, defining source=8 or removing Automatic-Module-Name
works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
was:
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1 or defining source=8 works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
> javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
> -
>
> Key: MJAVADOC-591
> URL: https://issues.apache.org/jira/browse/MJAVADOC-591
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Robert Varga
>Priority: Major
>
> In a module, which defines an Automatic-Module-Name and (inherits)
> maven.compiler.release=8, but does not set source=8, javadoc generation fails
> with:
> {code:java}
> 16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
> target 8
> 16052 [ERROR] error: option --add-modules not allowed with target 8
> 16052 [ERROR] error: option --patch-module not allowed with target 8
> 16053 [ERROR]
> 16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options
> @packages
> {code}
> This occurs with both javadoc-11.0.2 and javadoc-12. Using either
> maven-javadoc-plugin-3.0.1, defining source=8 or removing
> Automatic-Module-Name works just fine.
> I think the problem is that maven.compiler.release is propagated to release
> property, but that is not taken into account when --add-modules is generated
> and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-591) javadoc fails with maven.compiler.release=8 and Automatic-Module-Name
Robert Varga created MJAVADOC-591:
-
Summary: javadoc fails with maven.compiler.release=8 and
Automatic-Module-Name
Key: MJAVADOC-591
URL: https://issues.apache.org/jira/browse/MJAVADOC-591
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.1.0
Reporter: Robert Varga
In a module, which defines an Automatic-Module-Name and (inherits)
maven.compiler.release=8, but does not set source=8, javadoc generation fails
with:
{code:java}
16052 [ERROR] Exit code: 2 - error: option --module-path not allowed with
target 8
16052 [ERROR] error: option --add-modules not allowed with target 8
16052 [ERROR] error: option --patch-module not allowed with target 8
16053 [ERROR]
16053 [ERROR] Command line was: /home/nite/jdk-12/bin/javadoc @options @packages
{code}
This occurs with both javadoc-11.0.2 and javadoc-12. Using either
maven-javadoc-plugin-3.0.1 or defining source=8 works just fine.
I think the problem is that maven.compiler.release is propagated to release
property, but that is not taken into account when --add-modules is generated
and propagated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRESOLVER-42) DefaultArtifact(String) is inefficient
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360161#comment-16360161 ] Robert Varga edited comment on MRESOLVER-42 at 2/11/18 11:09 PM: - Fix at [https://github.com/apache/maven-resolver/pull/16] should be backported to 1.0.x. was (Author: nite): Fix at [https://github.com/apache/maven-resolver/pull/16|https://github.com/apache/maven-resolver/pull/16,] should be backported to 1.0.x. > DefaultArtifact(String) is inefficient > -- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Priority: Major > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MRESOLVER-42) DefaultArtifact(String) is inefficient
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360161#comment-16360161 ] Robert Varga edited comment on MRESOLVER-42 at 2/11/18 11:08 PM: - Fix at [https://github.com/apache/maven-resolver/pull/16|https://github.com/apache/maven-resolver/pull/16,] should be backported to 1.0.x. was (Author: nite): Fix at [https://github.com/apache/maven-resolver/pull/16,] should be backported to 1.0.x. > DefaultArtifact(String) is inefficient > -- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Priority: Major > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOLVER-42) DefaultArtifact(String) is inefficient
[ https://issues.apache.org/jira/browse/MRESOLVER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360161#comment-16360161 ] Robert Varga commented on MRESOLVER-42: --- Fix at [https://github.com/apache/maven-resolver/pull/16,] should be backported to 1.0.x. > DefaultArtifact(String) is inefficient > -- > > Key: MRESOLVER-42 > URL: https://issues.apache.org/jira/browse/MRESOLVER-42 > Project: Maven Resolver > Issue Type: Improvement > Components: resolver >Affects Versions: Maven Artifact Resolver 1.0.3, Maven Artifact Resolver > 1.1.0 >Reporter: Robert Varga >Priority: Major > > DefaultArtifact(String) always compiles the coordinate matching pattern. This > leads to sub-optimal performance when this constructor is used. > The pattern being matched should be a constant, so that we instantiate only a > matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRESOLVER-42) DefaultArtifact(String) is inefficient
Robert Varga created MRESOLVER-42: - Summary: DefaultArtifact(String) is inefficient Key: MRESOLVER-42 URL: https://issues.apache.org/jira/browse/MRESOLVER-42 Project: Maven Resolver Issue Type: Improvement Components: resolver Affects Versions: Maven Artifact Resolver 1.1.0, Maven Artifact Resolver 1.0.3 Reporter: Robert Varga DefaultArtifact(String) always compiles the coordinate matching pattern. This leads to sub-optimal performance when this constructor is used. The pattern being matched should be a constant, so that we instantiate only a matcher, which is fast compared to Pattern.compile(String). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] Issue Comment Edited: (MCOMPILER-75) Add apt support for Java 6
[
http://jira.codehaus.org/browse/MCOMPILER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215840#action_215840
]
Robert Varga edited comment on MCOMPILER-75 at 3/28/10 8:09 PM:
The proper implementation of -processorpath is really not possible with Maven
as I see it at the moment.
The biggest problem is that Maven does not support a thing like tools
classpath, a path which jars which the compiler itself needs but must not be on
the compile or test or runtime classpath of the just compiled module.
This likely could be introduced possibly with yet another scope (or more).
Not only the processor path, but also the antrun plugin could also benefit from
such a new classpath entity.
Currently the only workaround which exists is defining such dependencies with
the provided scope, which at least does not trigger propagation of these
dependencies, but it still puts such dependencies on the compilation classpath
of the module, so compilation itself is possibly providing incorrect results.
Of course, this is just my opinion.
Best regards,
Robert Varga
was (Author: robvarga):
The proper implementation of -processorpath is really not possible with
Maven as I see it at the moment.
The biggest problem is that Maven does not support a thing like tools
classpath, a path which jars which the compiler itself needs but must not be on
the compile or test or runtime classpath of the just compiled module.
This likely could be introduced possibly with yet another scope (or more).
Not only the processor path, but also the antrun plugin could also benefit from
such a new classpath entity.
Currently the only workaround which exists is defining such dependencies with
the provided scope, which at least does not trigger propagation of these
dependencies.
Of course, this is just my opinion.
Best regards,
Robert Varga
> Add apt support for Java 6
> --
>
> Key: MCOMPILER-75
> URL: http://jira.codehaus.org/browse/MCOMPILER-75
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.2
>Reporter: Mark Hobson
>Assignee: Milos Kleint
> Fix For: 2.2
>
>
> Apt (Annotation Processing Tool) was merged into javac in Java 6. The
> compiler plugin should support this new functionality, which means supporting
> the following new arguments:
> {noformat}
> -proc:{none,only} Control whether annotation processing and/or
> compilation is done.
> -processor [,,...]Names of the annotation
> processors to run; bypasses default discovery process
> -processorpath Specify where to find annotation processors
> -s Specify where to place generated source files
> -implicit:{none,class} Specify whether or not to generate class files
> for implicitly referenced files
> -Akey[=value] Options to pass to annotation processors
> {noformat}
> Note that this should supersede the Apt Maven Plugin at Mojo by encompassing
> all of its functionality:
> http://mojo.codehaus.org/apt-maven-plugin/index.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-75) Add apt support for Java 6
[
http://jira.codehaus.org/browse/MCOMPILER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215840#action_215840
]
Robert Varga commented on MCOMPILER-75:
---
The proper implementation of -processorpath is really not possible with Maven
as I see it at the moment.
The biggest problem is that Maven does not support a thing like tools
classpath, a path which jars which the compiler itself needs but must not be on
the compile or test or runtime classpath of the just compiled module.
This likely could be introduced possibly with yet another scope (or more).
Not only the processor path, but also the antrun plugin could also benefit from
such a new classpath entity.
Currently the only workaround which exists is defining such dependencies with
the provided scope, which at least does not trigger propagation of these
dependencies.
Of course, this is just my opinion.
Best regards,
Robert Varga
> Add apt support for Java 6
> --
>
> Key: MCOMPILER-75
> URL: http://jira.codehaus.org/browse/MCOMPILER-75
> Project: Maven 2.x Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.2
>Reporter: Mark Hobson
>Assignee: Milos Kleint
> Fix For: 2.2
>
>
> Apt (Annotation Processing Tool) was merged into javac in Java 6. The
> compiler plugin should support this new functionality, which means supporting
> the following new arguments:
> {noformat}
> -proc:{none,only} Control whether annotation processing and/or
> compilation is done.
> -processor [,,...]Names of the annotation
> processors to run; bypasses default discovery process
> -processorpath Specify where to find annotation processors
> -s Specify where to place generated source files
> -implicit:{none,class} Specify whether or not to generate class files
> for implicitly referenced files
> -Akey[=value] Options to pass to annotation processors
> {noformat}
> Note that this should supersede the Apt Maven Plugin at Mojo by encompassing
> all of its functionality:
> http://mojo.codehaus.org/apt-maven-plugin/index.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
