[jira] [Commented] (SUREFIRE-1573) PpidChecker inherits and blocks resources from tests while checking if the forked VM is still alive
[
https://issues.apache.org/jira/browse/SUREFIRE-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160282#comment-17160282
]
Tibor Digana commented on SUREFIRE-1573:
[~asynchronos] The project has several modules which are built with Java 7 but
there is already one built with Java 8 because it is used for JUnit5. So it
might be the same case here and the new module would have to be compiled twice.
If some open source project already has a facade built with Java 7 calling the
{{ProcessHandle.onExit()}} then we can use it.
> PpidChecker inherits and blocks resources from tests while checking if the
> forked VM is still alive
> ---
>
> Key: SUREFIRE-1573
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1573
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.0
> Environment: Windows, our tests create temporary files using
> native-code (std::fstream) and remove or rename them using boost::filesystem.
> Java 1.8.
>Reporter: Marcus Ackermann
>Priority: Critical
>
> On Windows, the PpidChecker executes wmic through cmd by starting a new
> process. Java calls {{CreateProcess}} with the flag {{bInheritHandles=TRUE}}.
> When I create a temporary file in a test, it happens that this file can
> neither be removed nor deleted. The error code is the following (from
> https://docs.microsoft.com/en-us/windows/desktop/debug/system-error-codes--0-499-)
> {code:java}
> ERROR_SHARING_VIOLATION
> 32 (0x20)
> The process cannot access the file because it is being used by another
> process.{code}
> I found out that this sharing violation is due to the fact that the process
> started from PpidChecker also owns the file inherited from the test process.
> This seems to be a side-effect of the new monitoring mechanism for the forked
> VM introduced in 2.20.1 with SUREFIRE-1302.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1824) failsafe-summary.xml should properly use UTF-8
[ https://issues.apache.org/jira/browse/SUREFIRE-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1824. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=2f4ed6fd20b1ddaa4280c33005ebf61490d18559 > failsafe-summary.xml should properly use UTF-8 > -- > > Key: SUREFIRE-1824 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1824 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1824) failsafe-summary.xml should properly use UTF-8
[ https://issues.apache.org/jira/browse/SUREFIRE-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1824: --- Fix Version/s: 3.0.0-M6 > failsafe-summary.xml should properly use UTF-8 > -- > > Key: SUREFIRE-1824 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1824 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Failsafe Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1824) failsafe-summary.xml should properly use UTF-8
Tibor Digana created SUREFIRE-1824: -- Summary: failsafe-summary.xml should properly use UTF-8 Key: SUREFIRE-1824 URL: https://issues.apache.org/jira/browse/SUREFIRE-1824 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Reporter: Tibor Digana Assignee: Tibor Digana -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1573) PpidChecker inherits and blocks resources from tests while checking if the forked VM is still alive
[
https://issues.apache.org/jira/browse/SUREFIRE-1573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160262#comment-17160262
]
Dave Cox commented on SUREFIRE-1573:
[~tibordigana], ProcessHandle.onExit() was apparently introduced in Java 9, but
it looks like Surefire Plugin aims to support back to Java 7.
> PpidChecker inherits and blocks resources from tests while checking if the
> forked VM is still alive
> ---
>
> Key: SUREFIRE-1573
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1573
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.0
> Environment: Windows, our tests create temporary files using
> native-code (std::fstream) and remove or rename them using boost::filesystem.
> Java 1.8.
>Reporter: Marcus Ackermann
>Priority: Critical
>
> On Windows, the PpidChecker executes wmic through cmd by starting a new
> process. Java calls {{CreateProcess}} with the flag {{bInheritHandles=TRUE}}.
> When I create a temporary file in a test, it happens that this file can
> neither be removed nor deleted. The error code is the following (from
> https://docs.microsoft.com/en-us/windows/desktop/debug/system-error-codes--0-499-)
> {code:java}
> ERROR_SHARING_VIOLATION
> 32 (0x20)
> The process cannot access the file because it is being used by another
> process.{code}
> I found out that this sharing violation is due to the fact that the process
> started from PpidChecker also owns the file inherited from the test process.
> This seems to be a side-effect of the new monitoring mechanism for the forked
> VM introduced in 2.20.1 with SUREFIRE-1302.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (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
]
Tibor Digana closed SUREFIRE-1820.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=24328c5ce9bc71dabab7801ffe8ccb74bad8aab3
> 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
>Assignee: Tibor Digana
>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] [Assigned] (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
]
Tibor Digana reassigned SUREFIRE-1820:
--
Assignee: Tibor Digana
> 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
>Assignee: Tibor Digana
>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=17160201#comment-17160201
]
Tibor Digana commented on SUREFIRE-1820:
I think we have to create an additional Maven profile anyway.
So it will be easy to force the release process to JDK 8 until the Maven
Compiler 3.8.1 will fix the order of .
> 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=17160199#comment-17160199
]
Tibor Digana commented on SUREFIRE-1820:
I think the Maven Compiler order and <--release> wrong.
The sources should be preceeded by --release.
> 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=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=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=17160190#comment-17160190
]
Tibor Digana commented on SUREFIRE-1820:
[~nite]
I have checkedit out but th native compiler fails with command line error. This
should not happen.
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException:
Compilation failure
javac: invalid flag: --release
Usage: javac
use -help for a list of possible options
{noformat}
[DEBUG] -d C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\target\classes
-classpath C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\target\classes;
-sourcepath
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java;C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\target\generated-sources\annotations;C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\target\generated-sources\annotations;
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\PrintStreamLogger.java
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\NullConsoleLogger.java
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\ConsoleLogger.java
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\ConsoleLoggerDecorator.java
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\ConsoleLoggerUtils.java
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\src\main\java\org\apache\maven\plugin\surefire\log\api\Level.java
-s
C:\vcs\release\RELEASE-3.0.0-M1\surefire-logger-api\target\generated-sources\annotations
-g -nowarn --release 7 -encoding UTF-8 -Xdoclint:all
{noformat}
We can force the team to use JDK 8 during the release otherwise the build fails.
This is maybe also the way to go.
> 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
[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=17160174#comment-17160174
]
Tibor Digana commented on SUREFIRE-1820:
hm,i have to check it out.
I am not sure if such old version 1.7 is supported in the switch --release.
If the compiler would not fail then we have to alter the behavior with extra
maven profile for jdk 9+ having --release 1.7.
> 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=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)
> at
[jira] [Commented] (SUREFIRE-1823) Surefire plugin giving error
[
https://issues.apache.org/jira/browse/SUREFIRE-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160164#comment-17160164
]
Tibor Digana commented on SUREFIRE-1823:
The versions 2.22.x and 3.0.0-M1 to 3.0.0-M5 are compatible with Java 1.8.
Also compatible with 1.7, and also 9 up to 15.
> Surefire plugin giving error
>
>
> Key: SUREFIRE-1823
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1823
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Prashant katiyar
>Assignee: Tibor Digana
>Priority: Major
>
> Hi,
>
> I am migrating one application from java 6 to java 8. i am using
> maven-surefile-plugin 2.5 version.
> --
> Configuration -
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> C:\Program Files\Java\jdk1.8.0_251\bin\java
> true
>
>
>
>
> ${project.build.directory}/${caf-lib-path}
>
>
>
> ${project.build.directory}/${caf-lib-path}:${project.build.directory}/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/apps/IRDtools/pkgs/pd/gcc/4.4.3/lib
>
>
> ${sonar.junit.reportsPath}
>
> **/${foundry.test.suite}.java
>
>
> true
> false
>
> ${argLine} -server -Xmx${maxHeap} -XX:+UseConcMarkSweepGC
> -XX:MaxPermSize=${maxPermSize} -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true
> -Dcom.sun.management.jmxremote.port=${jmxPort}
> -Dcom.sun.management.jmxremote.authenticate=false -Dfoundry.partitioncount=23
>
>
> true
>
> false
>
> ${jmxport}
> false
> ${hostname}
> foundry-log4j.xml
> ${hostname}
> foundry-processing-combined-cache-config.xml
>
> ${hostname}-cluster
>
> ${clusteraddress}
>
> ${clusterport}
> ${hostname}
> ${localport}
> all
>
> true
> dev
>
> foundry-cluster-config.xml
> 0
> 120
> 1000
> true
> 5
> 10
> 1
>
> ${foundry.integration-test.storagenodes}
>
>
> true
> true
> true
>
> false
> 23
> 23
> true
>
> false
>
> true
> ${project.basedir}/target/caf/bin
> test
>
>
>
> ${project.basedir}/../foundry-config/target/classes/env/integrationtest
>
>
> ${project.basedir}/../foundry-config/target/classes/env/all
>
> ${project.basedir}/target/test-classes/server0
>
>
>
>
>
> --
> Whenever i do mvn clean install test i get below error
> [DEBUG] Setting system property
> [caf.lib.path]=[E:\Project\0707\steel\mdx-integration-tests/target/caf/bin]
> [DEBUG] Setting system property
> [localRepository]=[C:\Users\katikpt\.m2\repository]
> [DEBUG] Setting system property [com.sun.management.jmxremote.port]=[3699]
> [DEBUG] Setting system property [foundry-rest.sso.inactive]=[true]
> [DEBUG] Setting system property [com.sun.management.jmxremote.ssl]=[false]
> [DEBUG] Setting environment variable
> [LD_LIBRARY_PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin:E:\Project\0707\steel\mdx-integration-tests\t
> arget/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/a
> pps/IRDtools/pkgs/pd/gcc/4.4.3/lib]
> [DEBUG] Setting environment variable
> [PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin]
> [INFO] Surefire report directory:
> E:\Project\0707\steel\mdx-integration-tests\..\target\surefire-reports
> Forking command line: cmd.exe /X /C ""C:\Program
> Files\Java\jdk1.8.0_251\bin\java"
> -javaagent:C:\\Users\\katikpt\\.m2\\repository\\org\\jacoco\\org.jacoco.agent
> \\0.7.9\\org.jacoco.agent-0.7.9-runtime.jar=destfile=E:\\Project\\0707\\steel\\mdx-integration-tests\\..\\target\\jacoco-it.exec,append=true
> -server -Xmx6g -XX:
> +UseConcMarkSweepGC -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=28002
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dfoundry.partitioncount=23 -jar
> C:\Users\katikpt\AppData\Local\Temp\surefirebooter5432316427063681014.jar C:
> \Users\katikpt\AppData\Local\Temp\surefire8919841153855074616tmp
> C:\Users\katikpt\AppData\Local\Temp\surefire7540265933895363746tmp"
> Usage: java [-options] class [args...]
> (to execute a class)
> or java [-options] -jar jarfile [args...]
> (to execute a jar file)
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> -server to select the "server" VM
> The default VM is server.
> -cp
> -classpath
> A ; separated list of directories, JAR archives,
> and ZIP archives to
[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=17160155#comment-17160155
]
Tibor Digana commented on SUREFIRE-1820:
You think that we should use *--release 1.7*?
We are at Java 1.7.
> 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=17160154#comment-17160154
]
Tibor Digana commented on SUREFIRE-1820:
I do not know what we can do about it because
*java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer*
appears in the JavaDoc API of JDK 8
https://docs.oracle.com/javase/8/docs/api/java/nio/Buffer.html#position-int-
Can you check the bytecode version of the class
*AbstractNoninterruptibleWritableChannel* ?
It has to be Java 1.7.
It appears in Javadoc with Java 1.7 as well
https://docs.oracle.com/javase/7/docs/api/java/nio/Buffer.html#position(int)
Do you have some Mock of ByteBuffer or Buffer in your tests?
> 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] [Comment Edited] (SUREFIRE-1819) MAVEN_OPTS=-Dmaven.repo.local env variable not used when running tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160150#comment-17160150
]
Tibor Digana edited comment on SUREFIRE-1819 at 7/17/20, 7:08 PM:
--
[~jorsol]
It is under the control of Maven and not the Surefire. If it was this problem
then we would have such problems in the Apache. It is hardly probable case.
Anyway investigate your logs, run the tests with debug level {{mvn -X test}}
and see all the paths for the *classpaths* and you should see the expected
paths pointing to the artifacts in your local repo.
was (Author: tibor17):
[~jorsol]
It is under the control of Maven and not the Surefire. If it was this problem
then we would have such problems in the Apache. It is hardly probable case.
Anyway investigate your lost, run the tests with debug level {{mvn -X test}}
and see all the paths for the *classpaths* and you should see the expected
paths pointing to the artifacts in your local repo.
> MAVEN_OPTS=-Dmaven.repo.local env variable not used when running tests
> --
>
> Key: SUREFIRE-1819
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1819
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jorge Solorzano
>Priority: Major
>
> The local repo configuration using:
>
> {color:#569cd6}MAVEN_OPTS{color}={color:#ce9178}-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository{color}
>
> Is not working when running the tests, it downloads all the dependencies
> again in the $HOME directory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1819) MAVEN_OPTS=-Dmaven.repo.local env variable not used when running tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160150#comment-17160150
]
Tibor Digana commented on SUREFIRE-1819:
[~jorsol]
It is under the control of Maven and not the Surefire. If it was this problem
then we would have such problems in the Apache. It is hardly probable case.
Anyway investigate your lost, run the tests with debug level {{mvn -X test}}
and see all the paths for the *classpaths* and you should see the expected
paths pointing to the artifacts in your local repo.
> MAVEN_OPTS=-Dmaven.repo.local env variable not used when running tests
> --
>
> Key: SUREFIRE-1819
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1819
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jorge Solorzano
>Priority: Major
>
> The local repo configuration using:
>
> {color:#569cd6}MAVEN_OPTS{color}={color:#ce9178}-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository{color}
>
> Is not working when running the tests, it downloads all the dependencies
> again in the $HOME directory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1823) Surefire plugin giving error
[
https://issues.apache.org/jira/browse/SUREFIRE-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160143#comment-17160143
]
Prashant katiyar commented on SUREFIRE-1823:
[~tibordigana]
Can you please confirm which version is compatible with jdk 8.
> Surefire plugin giving error
>
>
> Key: SUREFIRE-1823
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1823
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Prashant katiyar
>Assignee: Tibor Digana
>Priority: Major
>
> Hi,
>
> I am migrating one application from java 6 to java 8. i am using
> maven-surefile-plugin 2.5 version.
> --
> Configuration -
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> C:\Program Files\Java\jdk1.8.0_251\bin\java
> true
>
>
>
>
> ${project.build.directory}/${caf-lib-path}
>
>
>
> ${project.build.directory}/${caf-lib-path}:${project.build.directory}/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/apps/IRDtools/pkgs/pd/gcc/4.4.3/lib
>
>
> ${sonar.junit.reportsPath}
>
> **/${foundry.test.suite}.java
>
>
> true
> false
>
> ${argLine} -server -Xmx${maxHeap} -XX:+UseConcMarkSweepGC
> -XX:MaxPermSize=${maxPermSize} -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true
> -Dcom.sun.management.jmxremote.port=${jmxPort}
> -Dcom.sun.management.jmxremote.authenticate=false -Dfoundry.partitioncount=23
>
>
> true
>
> false
>
> ${jmxport}
> false
> ${hostname}
> foundry-log4j.xml
> ${hostname}
> foundry-processing-combined-cache-config.xml
>
> ${hostname}-cluster
>
> ${clusteraddress}
>
> ${clusterport}
> ${hostname}
> ${localport}
> all
>
> true
> dev
>
> foundry-cluster-config.xml
> 0
> 120
> 1000
> true
> 5
> 10
> 1
>
> ${foundry.integration-test.storagenodes}
>
>
> true
> true
> true
>
> false
> 23
> 23
> true
>
> false
>
> true
> ${project.basedir}/target/caf/bin
> test
>
>
>
> ${project.basedir}/../foundry-config/target/classes/env/integrationtest
>
>
> ${project.basedir}/../foundry-config/target/classes/env/all
>
> ${project.basedir}/target/test-classes/server0
>
>
>
>
>
> --
> Whenever i do mvn clean install test i get below error
> [DEBUG] Setting system property
> [caf.lib.path]=[E:\Project\0707\steel\mdx-integration-tests/target/caf/bin]
> [DEBUG] Setting system property
> [localRepository]=[C:\Users\katikpt\.m2\repository]
> [DEBUG] Setting system property [com.sun.management.jmxremote.port]=[3699]
> [DEBUG] Setting system property [foundry-rest.sso.inactive]=[true]
> [DEBUG] Setting system property [com.sun.management.jmxremote.ssl]=[false]
> [DEBUG] Setting environment variable
> [LD_LIBRARY_PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin:E:\Project\0707\steel\mdx-integration-tests\t
> arget/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/a
> pps/IRDtools/pkgs/pd/gcc/4.4.3/lib]
> [DEBUG] Setting environment variable
> [PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin]
> [INFO] Surefire report directory:
> E:\Project\0707\steel\mdx-integration-tests\..\target\surefire-reports
> Forking command line: cmd.exe /X /C ""C:\Program
> Files\Java\jdk1.8.0_251\bin\java"
> -javaagent:C:\\Users\\katikpt\\.m2\\repository\\org\\jacoco\\org.jacoco.agent
> \\0.7.9\\org.jacoco.agent-0.7.9-runtime.jar=destfile=E:\\Project\\0707\\steel\\mdx-integration-tests\\..\\target\\jacoco-it.exec,append=true
> -server -Xmx6g -XX:
> +UseConcMarkSweepGC -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=28002
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dfoundry.partitioncount=23 -jar
> C:\Users\katikpt\AppData\Local\Temp\surefirebooter5432316427063681014.jar C:
> \Users\katikpt\AppData\Local\Temp\surefire8919841153855074616tmp
> C:\Users\katikpt\AppData\Local\Temp\surefire7540265933895363746tmp"
> Usage: java [-options] class [args...]
> (to execute a class)
> or java [-options] -jar jarfile [args...]
> (to execute a jar file)
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> -server to select the "server" VM
> The default VM is server.
> -cp
> -classpath
> A ; separated list of directories, JAR archives,
> and ZIP archives to search for class files.
> -D=
>
[jira] [Commented] (SUREFIRE-1822) XML report with empty name attribute by 3.0.0-M5 when failing in @BeforeAll/@BeforeClass
[
https://issues.apache.org/jira/browse/SUREFIRE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160140#comment-17160140
]
Tibor Digana commented on SUREFIRE-1822:
This is the XSD definition of "name"
{code:xml}
{code}
So there must be empty string at least due to there's "required" and not
"optional". Otherwise we would delete the attribute.
I think nobody has considered the corner cases in the XSD design.
> XML report with empty name attribute by 3.0.0-M5 when failing in
> @BeforeAll/@BeforeClass
>
>
> Key: SUREFIRE-1822
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1822
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Marc Guillemot
>Priority: Major
>
> If a JUnit test fails in @BeforeAll (or a JUnit 4 test in @BeforeClass), then
> Surefire reports it correctly on the console and fails the build (what was
> not the case with 3.0.0-M4 with @BeforeAll) *but the testcase name attribute
> in the XML report is now empty*:
> Example:
> {code:java}
>time="0.017">
> type="org.opentest4j.AssertionFailedError">
>
>
> {code}
> As a reference, Surefire 2.2 writes the same content in the classname and
> name attributes:
> {code:java}
>classname="test.TestJUnit5FailingInBeforeAll" time="0.016">
> type="org.opentest4j.AssertionFailedError">org.opentest4j.AssertionFailedError:
> Failure in @BeforeAll method
> at
> test.TestJUnit5FailingInBeforeAll.setup(TestJUnit5FailingInBeforeAll.java:14)
>
>
>
> {code}
> It is not really wrong to consider that the testcase node has no name here
> but it would be a change compared to prior versions that other systems need
> to handle (Jenkins for instance doesn't display the report correctly in this
> case).
> Bug or feature? If this considered as a bug, I can try to provide a patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6961) extensions profile option
[ https://issues.apache.org/jira/browse/MNG-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Patrick updated MNG-6961: -- Issue Type: New Feature (was: Improvement) > extensions profile option > - > > Key: MNG-6961 > URL: https://issues.apache.org/jira/browse/MNG-6961 > Project: Maven > Issue Type: New Feature > Components: core, Profiles >Reporter: John Patrick >Priority: Major > > I use the https://github.com/khmarbaise/maven-buildtime-profiler via > .mvn/extensions.xml > But at the moment we checkin .mvn/extensions.xml.disabled. Then when someone > wants to execute the profiler they rename it locally. > Can .mvn/extensions.xml had a profiles option added. > So extensions can be enabled via settings.xml activeProfiles and also command > line switches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6963) mirrors and proxies options via profiles
[ https://issues.apache.org/jira/browse/MNG-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Patrick updated MNG-6963: -- Issue Type: New Feature (was: Improvement) > mirrors and proxies options via profiles > > > Key: MNG-6963 > URL: https://issues.apache.org/jira/browse/MNG-6963 > Project: Maven > Issue Type: New Feature > Components: core, Profiles >Reporter: John Patrick >Priority: Major > > Depending what office I'm working in, if I'm at home, if I'm a vpn or not I > have to change my mirror and proxy settings. > One office has a slow internet connection so has a local mirror (aka nexus). > Another office also has a local mirror (but artifactory not nexus) so it's on > a different url. > So being able to enable mirrors and proxies via profiles would be very > helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6962) jvm.config via command line flags
[
https://issues.apache.org/jira/browse/MNG-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Patrick updated MNG-6962:
--
Issue Type: New Feature (was: Improvement)
> jvm.config via command line flags
> -
>
> Key: MNG-6962
> URL: https://issues.apache.org/jira/browse/MNG-6962
> Project: Maven
> Issue Type: New Feature
> Components: core
>Reporter: John Patrick
>Priority: Major
>
> Command line flag to provide location of .mvn/jvm.config
> On Jenkins I use https://plugins.jenkins.io/config-file-provider/ to provide
> a jvm.config file as jenkins is running on a private openshift. So that maven
> wrapper can download etc it needs to know the http proxy to use. That proxy
> is different to the developers so we can't check in the file that works for
> both environments.
> At the moment we something likes this;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh 'mkdir .mvn'
> sh 'cp ${MAVEN_JVM_OPTIONS} .mvn/jvm.config'
> sh './mvnw -s ${MAVEN_SETTINGS} clean package'
> }
> ```
> Which feels 2 lines more than it needs to be, ideally it can be collapsed to
> something like;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh './mvnw -s ${MAVEN_SETTINGS} --jvm-options ${MAVEN_JVM_OPTIONS}
> clean verify'
> }
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6963) mirrors and proxies options via profiles
John Patrick created MNG-6963: - Summary: mirrors and proxies options via profiles Key: MNG-6963 URL: https://issues.apache.org/jira/browse/MNG-6963 Project: Maven Issue Type: Improvement Components: core, Profiles Reporter: John Patrick Depending what office I'm working in, if I'm at home, if I'm a vpn or not I have to change my mirror and proxy settings. One office has a slow internet connection so has a local mirror (aka nexus). Another office also has a local mirror (but artifactory not nexus) so it's on a different url. So being able to enable mirrors and proxies via profiles would be very helpful. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] pzygielo opened a new pull request #70: (doc) Fix javadoc
pzygielo opened a new pull request #70: URL: https://github.com/apache/maven-enforcer/pull/70 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1822) XML report with empty name attribute by 3.0.0-M5 when failing in @BeforeAll/@BeforeClass
[
https://issues.apache.org/jira/browse/SUREFIRE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160136#comment-17160136
]
Tibor Digana commented on SUREFIRE-1822:
Logically how can you consider the test method (instance method) to run if the
class and static context fails?
You cannot. The class fails, not the method because no method was executed in
real.
> XML report with empty name attribute by 3.0.0-M5 when failing in
> @BeforeAll/@BeforeClass
>
>
> Key: SUREFIRE-1822
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1822
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, xml generation
>Affects Versions: 3.0.0-M5
>Reporter: Marc Guillemot
>Priority: Major
>
> If a JUnit test fails in @BeforeAll (or a JUnit 4 test in @BeforeClass), then
> Surefire reports it correctly on the console and fails the build (what was
> not the case with 3.0.0-M4 with @BeforeAll) *but the testcase name attribute
> in the XML report is now empty*:
> Example:
> {code:java}
>time="0.017">
> type="org.opentest4j.AssertionFailedError">
>
>
> {code}
> As a reference, Surefire 2.2 writes the same content in the classname and
> name attributes:
> {code:java}
>classname="test.TestJUnit5FailingInBeforeAll" time="0.016">
> type="org.opentest4j.AssertionFailedError">org.opentest4j.AssertionFailedError:
> Failure in @BeforeAll method
> at
> test.TestJUnit5FailingInBeforeAll.setup(TestJUnit5FailingInBeforeAll.java:14)
>
>
>
> {code}
> It is not really wrong to consider that the testcase node has no name here
> but it would be a change compared to prior versions that other systems need
> to handle (Jenkins for instance doesn't display the report correctly in this
> case).
> Bug or feature? If this considered as a bug, I can try to provide a patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1823) Surefire plugin giving error
[
https://issues.apache.org/jira/browse/SUREFIRE-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1823.
--
Assignee: Tibor Digana
Resolution: Won't Fix
The version 2.5 is too old. See the Maven Central because it is Maven
repository and see the history of versions.
> Surefire plugin giving error
>
>
> Key: SUREFIRE-1823
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1823
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Prashant katiyar
>Assignee: Tibor Digana
>Priority: Major
>
> Hi,
>
> I am migrating one application from java 6 to java 8. i am using
> maven-surefile-plugin 2.5 version.
> --
> Configuration -
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> C:\Program Files\Java\jdk1.8.0_251\bin\java
> true
>
>
>
>
> ${project.build.directory}/${caf-lib-path}
>
>
>
> ${project.build.directory}/${caf-lib-path}:${project.build.directory}/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/apps/IRDtools/pkgs/pd/gcc/4.4.3/lib
>
>
> ${sonar.junit.reportsPath}
>
> **/${foundry.test.suite}.java
>
>
> true
> false
>
> ${argLine} -server -Xmx${maxHeap} -XX:+UseConcMarkSweepGC
> -XX:MaxPermSize=${maxPermSize} -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true
> -Dcom.sun.management.jmxremote.port=${jmxPort}
> -Dcom.sun.management.jmxremote.authenticate=false -Dfoundry.partitioncount=23
>
>
> true
>
> false
>
> ${jmxport}
> false
> ${hostname}
> foundry-log4j.xml
> ${hostname}
> foundry-processing-combined-cache-config.xml
>
> ${hostname}-cluster
>
> ${clusteraddress}
>
> ${clusterport}
> ${hostname}
> ${localport}
> all
>
> true
> dev
>
> foundry-cluster-config.xml
> 0
> 120
> 1000
> true
> 5
> 10
> 1
>
> ${foundry.integration-test.storagenodes}
>
>
> true
> true
> true
>
> false
> 23
> 23
> true
>
> false
>
> true
> ${project.basedir}/target/caf/bin
> test
>
>
>
> ${project.basedir}/../foundry-config/target/classes/env/integrationtest
>
>
> ${project.basedir}/../foundry-config/target/classes/env/all
>
> ${project.basedir}/target/test-classes/server0
>
>
>
>
>
> --
> Whenever i do mvn clean install test i get below error
> [DEBUG] Setting system property
> [caf.lib.path]=[E:\Project\0707\steel\mdx-integration-tests/target/caf/bin]
> [DEBUG] Setting system property
> [localRepository]=[C:\Users\katikpt\.m2\repository]
> [DEBUG] Setting system property [com.sun.management.jmxremote.port]=[3699]
> [DEBUG] Setting system property [foundry-rest.sso.inactive]=[true]
> [DEBUG] Setting system property [com.sun.management.jmxremote.ssl]=[false]
> [DEBUG] Setting environment variable
> [LD_LIBRARY_PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin:E:\Project\0707\steel\mdx-integration-tests\t
> arget/${caf-dependencies.lib-path}:/apps/IRDtools/pkgs/pd/xerces-c/3.1.1/lib:/apps/IRDtools/pkgs/pd/boost/1.52.0/lib:/apps/IRDtools/pkgs/pd/libxml/2.6.24/lib:/a
> pps/IRDtools/pkgs/pd/gcc/4.4.3/lib]
> [DEBUG] Setting environment variable
> [PATH]=[E:\Project\0707\steel\mdx-integration-tests\target/caf/bin]
> [INFO] Surefire report directory:
> E:\Project\0707\steel\mdx-integration-tests\..\target\surefire-reports
> Forking command line: cmd.exe /X /C ""C:\Program
> Files\Java\jdk1.8.0_251\bin\java"
> -javaagent:C:\\Users\\katikpt\\.m2\\repository\\org\\jacoco\\org.jacoco.agent
> \\0.7.9\\org.jacoco.agent-0.7.9-runtime.jar=destfile=E:\\Project\\0707\\steel\\mdx-integration-tests\\..\\target\\jacoco-it.exec,append=true
> -server -Xmx6g -XX:
> +UseConcMarkSweepGC -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
> -XX:+CMSPermGenSweepingEnabled -XX:+HeapDumpOnOutOfMemoryError
> -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=28002
> -Dcom.sun.management.jmxremote.authenticate=false
> -Dfoundry.partitioncount=23 -jar
> C:\Users\katikpt\AppData\Local\Temp\surefirebooter5432316427063681014.jar C:
> \Users\katikpt\AppData\Local\Temp\surefire8919841153855074616tmp
> C:\Users\katikpt\AppData\Local\Temp\surefire7540265933895363746tmp"
> Usage: java [-options] class [args...]
> (to execute a class)
> or java [-options] -jar jarfile [args...]
> (to execute a jar file)
> where options include:
> -d32 use a 32-bit data model if available
> -d64 use a 64-bit data model if available
> -server to select the "server" VM
> The default VM is server.
> -cp
> -classpath
> A ; separated list of directories, JAR archives,
> and ZIP
[jira] [Created] (MNG-6962) jvm.config via command line flags
John Patrick created MNG-6962:
-
Summary: jvm.config via command line flags
Key: MNG-6962
URL: https://issues.apache.org/jira/browse/MNG-6962
Project: Maven
Issue Type: Improvement
Components: core
Reporter: John Patrick
Command line flag to provide location of .mvn/jvm.config
On Jenkins I use https://plugins.jenkins.io/config-file-provider/ to provide a
jvm.config file as jenkins is running on a private openshift. So that maven
wrapper can download etc it needs to know the http proxy to use. That proxy is
different to the developers so we can't check in the file that works for both
environments.
At the moment we something likes this;
```
configFileProvider([
configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
]) {
sh 'mkdir .mvn'
sh 'cp ${MAVEN_JVM_OPTIONS} .mvn/jvm.config'
sh './mvnw -s ${MAVEN_SETTINGS} clean package'
}
```
Which feels 2 lines more than it needs to be, ideally it can be collapsed to
something like;
```
configFileProvider([
configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
]) {
sh './mvnw -s ${MAVEN_SETTINGS} --jvm-options ${MAVEN_JVM_OPTIONS}
clean verify'
}
```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-doxia] dependabot[bot] commented on pull request #36: Bump commons-lang3 from 3.8.1 to 3.11
dependabot[bot] commented on pull request #36: URL: https://github.com/apache/maven-doxia/pull/36#issuecomment-660268678 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-6961) extensions profile option
John Patrick created MNG-6961: - Summary: extensions profile option Key: MNG-6961 URL: https://issues.apache.org/jira/browse/MNG-6961 Project: Maven Issue Type: Improvement Components: core, Profiles Reporter: John Patrick I use the https://github.com/khmarbaise/maven-buildtime-profiler via .mvn/extensions.xml But at the moment we checkin .mvn/extensions.xml.disabled. Then when someone wants to execute the profiler they rename it locally. Can .mvn/extensions.xml had a profiles option added. So extensions can be enabled via settings.xml activeProfiles and also command line switches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] ian-lavallee commented on a change in pull request #80: [MDEP-708] dependency:analyze should recommend test scope where possible
ian-lavallee commented on a change in pull request #80: URL: https://github.com/apache/maven-dependency-plugin/pull/80#discussion_r456600762 ## File path: pom.xml ## @@ -222,7 +222,8 @@ under the License. org.apache.maven.shared maven-dependency-analyzer - 1.11.1 + + 1.11.2-SNAPSHOT Review comment: Yes but I'm hoping to get @bimargulies to review it first so he has more of my work to base his feedback off This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] elharo commented on a change in pull request #80: [MDEP-708] dependency:analyze should recommend test scope where possible
elharo commented on a change in pull request #80: URL: https://github.com/apache/maven-dependency-plugin/pull/80#discussion_r456592396 ## File path: pom.xml ## @@ -222,7 +222,8 @@ under the License. org.apache.maven.shared maven-dependency-analyzer - 1.11.1 + + 1.11.2-SNAPSHOT Review comment: given that we can depend on snapshot versions, are you comfortable with this PR being merged now? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #83: Bump mockito-core from 2.28.2 to 3.4.2
dependabot[bot] commented on pull request #83: URL: https://github.com/apache/maven-dependency-plugin/pull/83#issuecomment-660256479 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] elharo closed pull request #83: Bump mockito-core from 2.28.2 to 3.4.2
elharo closed pull request #83: URL: https://github.com/apache/maven-dependency-plugin/pull/83 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] elharo closed pull request #82: Bump commons-lang3 from 3.8.1 to 3.11
elharo closed pull request #82: URL: https://github.com/apache/maven-dependency-plugin/pull/82 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] elharo merged pull request #84: docs: don't assume people are using Eclipse
elharo merged pull request #84: URL: https://github.com/apache/maven-dependency-plugin/pull/84 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] dependabot[bot] commented on pull request #82: Bump commons-lang3 from 3.8.1 to 3.11
dependabot[bot] commented on pull request #82: URL: https://github.com/apache/maven-dependency-plugin/pull/82#issuecomment-660256331 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-520) Maven 2 / Maven 3 differences on analyze with cycle
[
https://issues.apache.org/jira/browse/MDEP-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160071#comment-17160071
]
Jean-Pierre Froud commented on MDEP-520:
When there is a cycle, the dependency analyze goal tells an artifact must
depend on itself. If the cycle looks like
A depends on B depends on A
Then when running dependency analyze on A, the analysis report will tell to add
A as a dependency of A
> Maven 2 / Maven 3 differences on analyze with cycle
> ---
>
> Key: MDEP-520
> URL: https://issues.apache.org/jira/browse/MDEP-520
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Jean-Pierre Froud
>Priority: Minor
> Labels: S2
>
> Here's the dependency tree I'm using:
> {code}
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ PA ---
> [INFO] myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO] \- PC:PC:jar:0.0.1-SNAPSHOT:compile
> [INFO]\- myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> As you can see, there's a cycle : {{PA > PC > PA}}
> Using maven 2.2.1:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building Unnamed - myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO]task-segment: [dependency:analyze]
> [INFO]
>
> ...
> [INFO] No dependency problems found
> {code}
> Using maven 3.3.3:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ PA ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> The analyze in maven 3 wants me to add {{PA}} as a dependency to {{PA}}, to
> itself. Is it possible to have the same behavior as maven 2 using maven 3?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160053#comment-17160053 ] Matt Nelson commented on MDEP-431: -- This doesn't appear to be fixed in the latest release[1] or in master[2]. [1] https://maven.apache.org/plugins/maven-dependency-plugin/analyze-only-mojo.html [2] https://github.com/apache/maven-dependency-plugin/blob/master/src/main/java/org/apache/maven/plugins/dependency/analyze/AbstractAnalyzeMojo.java > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Minor > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-314) MDEP: GraphMLNodeVisitor Suitable for yED and Fancy Graphics (m-d-p 2.2)
[ https://issues.apache.org/jira/browse/MDEP-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-314: --- Labels: S2 close-pending (was: close-pending) > MDEP: GraphMLNodeVisitor Suitable for yED and Fancy Graphics (m-d-p 2.2) > > > Key: MDEP-314 > URL: https://issues.apache.org/jira/browse/MDEP-314 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Aldrin Leal >Priority: Minor > Labels: S2, close-pending > Attachments: GraphmlDependencyNodeVisitor-mdep.txt > > > This attachment is a patch between 2.2 in order to add latest yED > compatibility, as well as colors to output. > If needed, I could write a given doc page on how to use that. Once you > generate them, open yEd, load the resulting .gml file, and then Under Layout > | Tree, select Layout Style as "Compact". > A workable result is here: > http://imageshack.us/photo/my-images/804/pessoa.png/ > Note it doesn't covers some situations, so perhaps it would be interesting to > add it as a new graph serializer. However, note this is inconsistent - As it > needs AWT (for Font and Boundary Metrics, it might run into issues on a > headless instance). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-522) Support different output types for list, or resolve
[ https://issues.apache.org/jira/browse/MDEP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-522: --- Labels: S2 (was: ) > Support different output types for list, or resolve > --- > > Key: MDEP-522 > URL: https://issues.apache.org/jira/browse/MDEP-522 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.10 >Reporter: Jochen Wiedmann >Priority: Minor > Labels: S2 > Attachments: MDEP-522.patch, MDEP-522.patch > > > Right now, the goals list, and resolve, generate a human readably output > file. This is unsuitable for machine based processing, although a dependency > list is very likely to be of use for downstream applications. > Suggestion: Introduce a new parameter outputFormat with values like "text" > (current format, default), or "properties". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-314) MDEP: GraphMLNodeVisitor Suitable for yED and Fancy Graphics (m-d-p 2.2)
[ https://issues.apache.org/jira/browse/MDEP-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-314: --- Priority: Minor (was: Trivial) > MDEP: GraphMLNodeVisitor Suitable for yED and Fancy Graphics (m-d-p 2.2) > > > Key: MDEP-314 > URL: https://issues.apache.org/jira/browse/MDEP-314 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Aldrin Leal >Priority: Minor > Labels: close-pending > Attachments: GraphmlDependencyNodeVisitor-mdep.txt > > > This attachment is a patch between 2.2 in order to add latest yED > compatibility, as well as colors to output. > If needed, I could write a given doc page on how to use that. Once you > generate them, open yEd, load the resulting .gml file, and then Under Layout > | Tree, select Layout Style as "Compact". > A workable result is here: > http://imageshack.us/photo/my-images/804/pessoa.png/ > Note it doesn't covers some situations, so perhaps it would be interesting to > add it as a new graph serializer. However, note this is inconsistent - As it > needs AWT (for Font and Boundary Metrics, it might run into issues on a > headless instance). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-520) Maven 2 / Maven 3 differences on analyze with cycle
[
https://issues.apache.org/jira/browse/MDEP-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-520:
---
Labels: S2 (was: )
> Maven 2 / Maven 3 differences on analyze with cycle
> ---
>
> Key: MDEP-520
> URL: https://issues.apache.org/jira/browse/MDEP-520
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Jean-Pierre Froud
>Priority: Minor
> Labels: S2
>
> Here's the dependency tree I'm using:
> {code}
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ PA ---
> [INFO] myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO] \- PC:PC:jar:0.0.1-SNAPSHOT:compile
> [INFO]\- myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> As you can see, there's a cycle : {{PA > PC > PA}}
> Using maven 2.2.1:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building Unnamed - myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO]task-segment: [dependency:analyze]
> [INFO]
>
> ...
> [INFO] No dependency problems found
> {code}
> Using maven 3.3.3:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ PA ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> The analyze in maven 3 wants me to add {{PA}} as a dependency to {{PA}}, to
> itself. Is it possible to have the same behavior as maven 2 using maven 3?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-520) Maven 2 / Maven 3 differences on analyze with cycle
[
https://issues.apache.org/jira/browse/MDEP-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160004#comment-17160004
]
Elliotte Rusty Harold commented on MDEP-520:
can you rephrase this as a bug in behavior without reference to maven 2?
> Maven 2 / Maven 3 differences on analyze with cycle
> ---
>
> Key: MDEP-520
> URL: https://issues.apache.org/jira/browse/MDEP-520
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Jean-Pierre Froud
>Priority: Minor
>
> Here's the dependency tree I'm using:
> {code}
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ PA ---
> [INFO] myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO] \- PC:PC:jar:0.0.1-SNAPSHOT:compile
> [INFO]\- myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> As you can see, there's a cycle : {{PA > PC > PA}}
> Using maven 2.2.1:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building Unnamed - myTest:PA:jar:0.0.2-SNAPSHOT
> [INFO]task-segment: [dependency:analyze]
> [INFO]
>
> ...
> [INFO] No dependency problems found
> {code}
> Using maven 3.3.3:
> {code}
> mvn dependency:analyze
> [INFO]
>
> [INFO] Building PA 0.0.2-SNAPSHOT
> [INFO]
>
> ...
> [INFO] --- maven-dependency-plugin:2.8:analyze (default-cli) @ PA ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]myTest:PA:jar:0.0.1-SNAPSHOT:compile
> {code}
> The analyze in maven 3 wants me to add {{PA}} as a dependency to {{PA}}, to
> itself. Is it possible to have the same behavior as maven 2 using maven 3?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-498) Lack of user property for addParentPoms in version 2.8 is not documented in main doc page
[ https://issues.apache.org/jira/browse/MDEP-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-498. -- > Lack of user property for addParentPoms in version 2.8 is not documented in > main doc page > - > > Key: MDEP-498 > URL: https://issues.apache.org/jira/browse/MDEP-498 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.8 >Reporter: Alex Szebenyi >Priority: Minor > Labels: close-pending, documentation > > The user property for addParentPoms in the copy-dependencies goal was added > in 2.9. If possible, making a note of this in the expanded description for > the property may be useful. > This change is mentioned in the announcement: > [http://mail-archives.apache.org/mod_mbox/maven-dev/201409.mbox/%3c20140921213545.9194611...@minotaur.apache.org%3E] > but never mentioned in the doc (only that addParentPoms is supported since > 2.8): > [https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#addParentPoms] > Thank you -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-498) Lack of user property for addParentPoms in version 2.8 is not documented in main doc page
[ https://issues.apache.org/jira/browse/MDEP-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-498. Resolution: Fixed > Lack of user property for addParentPoms in version 2.8 is not documented in > main doc page > - > > Key: MDEP-498 > URL: https://issues.apache.org/jira/browse/MDEP-498 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.8 >Reporter: Alex Szebenyi >Priority: Minor > Labels: close-pending, documentation > > The user property for addParentPoms in the copy-dependencies goal was added > in 2.9. If possible, making a note of this in the expanded description for > the property may be useful. > This change is mentioned in the announcement: > [http://mail-archives.apache.org/mod_mbox/maven-dev/201409.mbox/%3c20140921213545.9194611...@minotaur.apache.org%3E] > but never mentioned in the doc (only that addParentPoms is supported since > 2.8): > [https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#addParentPoms] > Thank you -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-601) dependency:list from a configured artifact
[ https://issues.apache.org/jira/browse/MDEP-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-601. Resolution: Fixed in another bug > dependency:list from a configured artifact > -- > > Key: MDEP-601 > URL: https://issues.apache.org/jira/browse/MDEP-601 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Minor > > It would be neat to be able to create a dependencies.txt file (mvn > dependency:list) from a set of artifacts defined in the configuration instead > of the project. > My use case is to create foo-dependencies.txt, bar-dependencies.txt from > dependencies foo and bar (with transitive deps) and put these file in > artifact dummy.jar but dummy doesn't depend on foo and bar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-601) dependency:list from a configured artifact
[ https://issues.apache.org/jira/browse/MDEP-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-601. -- > dependency:list from a configured artifact > -- > > Key: MDEP-601 > URL: https://issues.apache.org/jira/browse/MDEP-601 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Minor > > It would be neat to be able to create a dependencies.txt file (mvn > dependency:list) from a set of artifacts defined in the configuration instead > of the project. > My use case is to create foo-dependencies.txt, bar-dependencies.txt from > dependencies foo and bar (with transitive deps) and put these file in > artifact dummy.jar but dummy doesn't depend on foo and bar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-532) Undeclared test resources fail build despite 'ignoreNonCompile'
[
https://issues.apache.org/jira/browse/MDEP-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-532:
---
Labels: S2 (was: )
> Undeclared test resources fail build despite 'ignoreNonCompile'
> ---
>
> Key: MDEP-532
> URL: https://issues.apache.org/jira/browse/MDEP-532
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.10
> Environment: Windows 7 Pro 64-bit, Java OpenSDK 8, Maven 3.3.9
>Reporter: Alexander Kriegisch
>Priority: Minor
> Labels: S2
>
> I have this plugin in my project's root POM:
> {code}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.10
>
>
> analyze
>
> analyze-only
>
>
> true
> true
>
> *
>
>
>
>
> {code}
> Even though I want to ignore used undeclared test dependencies via
> {{true}}, my build fails like this in
> several modules:
> {code}
> [INFO] --- maven-dependency-plugin:2.10:analyze-only (analyze) @ xxx.yyy ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]
> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar:2.2.0:test
> [WARNING]org.jboss.shrinkwrap:shrinkwrap-api:jar:1.2.3:test
> [WARNING]
> org.jboss.arquillian.container:arquillian-container-test-api:jar:1.1.11.Final:test
> [WARNING]
> org.jboss.arquillian.spock:arquillian-spock-core:jar:1.0.0.RC4_XXX:test
> [WARNING]
> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven-archive:jar:2.2.0:test
> (...)
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.10:analyze-only (analyze)
> on project xxx.yyy: Dependency problems found -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.10:analyze-only (analyze)
> on project yyy.zzz: Dependency problems found -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.10:analyze-only (analyze)
> on project zzz.aaa: Dependency problems found -> [Help 1]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:2.10:analyze-only (analyze)
> on project aaa.bbb: Dependency problems found -> [Help 1]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-523) Unused dependency not detected when present in test classes
[ https://issues.apache.org/jira/browse/MDEP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-523. -- > Unused dependency not detected when present in test classes > --- > > Key: MDEP-523 > URL: https://issues.apache.org/jira/browse/MDEP-523 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.10 >Reporter: Victor >Priority: Minor > > Hi, > I realised that analyze-only was returning unexpected resuls. > Basically, I have one simple maven project as defined here: > https://gist.github.com/victornoel/713a3b17999f353030bed949b79970d8 > The java test file is in the src/test/java/test/test/Test.java > If I run mvn verify on that, the dependency plugin does not complain about > the fact that the commons-lang3 dependency is not used in compile scope as I > would expect it to. > If I comment the use of the dependency in the Test.java file, then > maven-dependency-plugin complains about the non-use of the dependency. > Am I mistaken on the expected behaviour of analyze? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-523) Unused dependency not detected when present in test classes
[ https://issues.apache.org/jira/browse/MDEP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-523. Resolution: Cannot Reproduce expect this is covered in other bugs, if it's still present > Unused dependency not detected when present in test classes > --- > > Key: MDEP-523 > URL: https://issues.apache.org/jira/browse/MDEP-523 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.10 >Reporter: Victor >Priority: Minor > > Hi, > I realised that analyze-only was returning unexpected resuls. > Basically, I have one simple maven project as defined here: > https://gist.github.com/victornoel/713a3b17999f353030bed949b79970d8 > The java test file is in the src/test/java/test/test/Test.java > If I run mvn verify on that, the dependency plugin does not complain about > the fact that the commons-lang3 dependency is not used in compile scope as I > would expect it to. > If I comment the use of the dependency in the Test.java file, then > maven-dependency-plugin complains about the non-use of the dependency. > Am I mistaken on the expected behaviour of analyze? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-431. Resolution: Fixed Looks like we forgot to close this when it was fixed > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Minor > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-431) new options to control output from dependency:analyze(-only)
[ https://issues.apache.org/jira/browse/MDEP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-431. -- > new options to control output from dependency:analyze(-only) > > > Key: MDEP-431 > URL: https://issues.apache.org/jira/browse/MDEP-431 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.8 >Reporter: Robert Platt >Priority: Minor > Attachments: mdep.patch > > > Including dependency:analyze-only with failOnWarning into a build can be very > effective at catching dependency issues. However, it is pretty much > all-or-nothing at the moment. In the case of complex or legacy projects it > can be difficult to incorporate the plugin into the build. > This is a patch (see attached mdep.path) to version 2.8 to provide more > control over dependency analysis output, introducing three new configuration > options. In all cases, the default options provide the current plugin > behavior: > 1. warnUnusedDeclared (default true). Unused declared dependencies generate > a warning if this is true, otherwise it is just info. > 2. ignoreManagedUndeclared (default false). If true, then used undeclared > dependencies which are dependency managed are not reported in the warnings. > The reasoning behind this option is that used undeclared dependencies are > less likely to break a build in subtle ways if they are dependency managed, > since the version will not change without developer intervention. Turning > this option on focuses the analysis on compiling against unmanaged transitive > dependencies. > 3. preferManagedVersionOutput (default false). If true, when outputting XML, > versions are left unspecified for managed dependencies. This can be handy > when you aren't using ignoreManagedUndeclared but want to use managed > versions when fixing undeclared dependencies. > Finally, the wording for the output of unused declared dependencies has been > changed to 'Potentially unused declared dependencies found' because, as > documented, their are limitations to this detection process with the default > analyzer. This wording makes it clearer to developers without that working > knowledge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-686) Upgrade maven-artifact-transfer from 0.11.0 to 0.13.0
[ https://issues.apache.org/jira/browse/MDEP-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-686: --- Labels: S2 (was: ) > Upgrade maven-artifact-transfer from 0.11.0 to 0.13.0 > - > > Key: MDEP-686 > URL: https://issues.apache.org/jira/browse/MDEP-686 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Karl Heinz Marbaise >Priority: Major > Labels: S2 > Fix For: 3.1.3 > > > We have to make a release of artifact-transfer 0.13.0 first -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-549) list deps with scope runtime should show provided scope as well
[
https://issues.apache.org/jira/browse/MDEP-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-549:
---
Labels: S2 (was: )
> list deps with scope runtime should show provided scope as well
> ---
>
> Key: MDEP-549
> URL: https://issues.apache.org/jira/browse/MDEP-549
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Sébastien Gandon
>Priority: Minor
> Labels: S2
>
> I am trying to get all the dependencies but the test ones.
> I am using
> {code}
> mvn dependency:list -DincludeScope=runtime
> {code}
> in the doc the runtime scope includes *runtime* and *compile* scopes.
> and it says the *compile* scope gives compile, provided, and
>system dependencies
> So I would expect the *runtime* scope would also return *provided*
> dependencies
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-695) Improve mvn dependency:tree - add option to generate mermaidjs flowchart diagram format
[
https://issues.apache.org/jira/browse/MDEP-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-695:
---
Labels: S2 features (was: features)
> Improve mvn dependency:tree - add option to generate mermaidjs flowchart
> diagram format
> ---
>
> Key: MDEP-695
> URL: https://issues.apache.org/jira/browse/MDEP-695
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: waiting-for-feedback
> Environment: all
>Reporter: Emanuel Ciuca
>Priority: Minor
> Labels: S2, features
> Attachments: demo.svg
>
>
> While trying to generate some diagrams for maven module dependencies I found
> mermaidjs flowchart diagrams to be most suitable for large graphs. (see
> [https://mermaid-js.github.io/mermaid/#/flowchart|https://mermaid-js.github.io/mermaid/#/flowchart)])
> Here is an example of a graph I generated for one of the projects I work on:
>
> {code:java}
> graph LR
> module-1 --> |compile| module-2
> module-3 --> |compile| module-4
> module-3 --> |test| module-5
> module-3 --> |compile,test| module-2
> module-3 --> |test| module-1{code}
>
> I would be helpful to be able to generate this diagram for a multi-module
> maven project
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-679) mvn dependency:analyze detected wrong transitive dependency
[
https://issues.apache.org/jira/browse/MDEP-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-679:
---
Labels: S2 (was: )
> mvn dependency:analyze detected wrong transitive dependency
> ---
>
> Key: MDEP-679
> URL: https://issues.apache.org/jira/browse/MDEP-679
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.1
>Reporter: John Lin
>Priority: Minor
> Labels: S2
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To illustrate this issue, I created a sample project here:
> [https://github.com/johnlinp/misc-demo/tree/master/maven-dependency-analyze-dnsjava]
> The dependency tree is like this:
> {code:java}
> My app ---> ApacheJMeter_http ---> dnsjava
> {code}
> I didn't use any code directly from the artifact {{dnsjava}} in my app. I
> only used {{ApacheJMeter_http}}. However, the command {{mvn
> dependency:analyze}} will report a used undeclared dependency: {{dnsjava}}.
> {code:java}
> [INFO] --- maven-dependency-plugin:3.1.1:analyze (default-cli) @
> maven-dependency-analyze-dnsjava ---
> [WARNING] Used undeclared dependencies found:
> [WARNING]dnsjava:dnsjava:jar:2.1.9:runtime {code}
> It seems that the problem came from the line:
> {code:java}
> map.put("update", null);
> {code}
> If I change it into {{map.put("create", null);}} or even {{map.put("UPDATE",
> null);}}, the problem will disappear. Therefore, I think there might be
> something to do with the string "update".
> Note that this issue is not reproducible in maven-dependency-plugin:2.8.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-686) Upgrade maven-artifact-transfer from 0.11.0 to 0.13.0
[ https://issues.apache.org/jira/browse/MDEP-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-686: --- Priority: Major (was: Minor) > Upgrade maven-artifact-transfer from 0.11.0 to 0.13.0 > - > > Key: MDEP-686 > URL: https://issues.apache.org/jira/browse/MDEP-686 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.1.3 > > > We have to make a release of artifact-transfer 0.13.0 first -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-602) Turn warnings into errors instead of failOnWarning
[ https://issues.apache.org/jira/browse/MDEP-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-602: --- Labels: S2 (was: ) > Turn warnings into errors instead of failOnWarning > -- > > Key: MDEP-602 > URL: https://issues.apache.org/jira/browse/MDEP-602 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 3.0.2 >Reporter: Richard Eckart de Castilho >Priority: Minor > Labels: S2 > > Currently, the dependency:analyze goal supports a parameter called > failOnWarning which - when enabled - causes warnings to fail the build. > This is confusing, especially for new developers on a team who are often > unable to locate the dependency problems causing the build to fail in the > logs because they only look for "error" level messages. > To avoid such problems, I would suggest deprecating the failOnWarning > parameter, and instead introduce a new parameter such as > treatDependencyProblemsAs which could take as a default level "warning" and > which users could alternatively set to "error". > I am setting this as a "major improvement" because in my experience, it > causes significant confusion over and over again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-557) In dependency analysis, support Spring Boot style intentional transitive compile-time dependencies
[
https://issues.apache.org/jira/browse/MDEP-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-557:
---
Labels: S2 (was: )
> In dependency analysis, support Spring Boot style intentional transitive
> compile-time dependencies
> --
>
> Key: MDEP-557
> URL: https://issues.apache.org/jira/browse/MDEP-557
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: M. Justin
>Priority: Minor
> Labels: S2
>
> h1. Request
> It would be useful if using Spring Boot "starter" dependencies as intended
> didn't cause warnings with dependency:analyze (and related goals).
> h1. Background
> Spring Boot has a notion of "starter" dependencies. One of the primary
> purposes of starter dependencies is to transitively bring in numerous other
> dependencies to be used at both runtime and compile time. Per [Spring Boot's
> documentation|http://docs.spring.io/spring-boot/docs/1.5.1.RELEASE/reference/htmlsingle/#using-boot-starter]:
> {quote}
> Starters are a set of convenient dependency descriptors that you can include
> in your application. You get a one-stop-shop for all the Spring and related
> technology that you need, without having to hunt through sample code and copy
> paste loads of dependency descriptors. For example, if you want to get
> started using Spring and JPA for database access, just include the
> spring-boot-starter-data-jpa dependency in your project, and you are good to
> go.
> The starters contain a lot of the dependencies that you need to get a project
> up and running quickly and with a consistent, supported set of managed
> transitive dependencies.
> {quote}
> However, this is at odds with the analysis done by
> [dependency:analyze|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html]
> (and similar goals in the dependency plugin). The analyze goals will warn
> that the starter projects are "unused declared dependencies" and any
> compile-time dependencies that are transitively brought in this way will
> produce "used undeclared dependencies" warnings. Note that this warning
> behavior is consistent with the [Maven dependency
> documentation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> where it states that it is intended that all compile dependencies be
> explicitly listed, rather than transitively used at compile time:
> {quote}it is intended that \[transitive compile dependencies\] should be
> runtime scope instead, so that all compile dependencies must be explicitly
> listed - however, there is the case where the library you depend on extends a
> class from another library, forcing you to have available at compile time.
> For this reason, compile time dependencies remain as compile scope even when
> they are transitive.{quote}
> As a concrete example, here are the warnings generated by {{mvn
> dependency:analyze}} on Spring Boot's own "[Getting
> Started|https://spring.io/guides/gs/spring-boot/]; example:
> {code}Used undeclared dependencies found:
>org.springframework:spring-web:jar:4.3.6.RELEASE:compile
>org.springframework.boot:spring-boot-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-test-autoconfigure:jar:1.5.1.RELEASE:test
>org.springframework:spring-test:jar:4.3.6.RELEASE:test
>org.springframework.boot:spring-boot:jar:1.5.1.RELEASE:compile
>org.hamcrest:hamcrest-library:jar:1.3:test
>org.springframework:spring-context:jar:4.3.6.RELEASE:compile
>junit:junit:jar:4.12:test
>
> org.springframework.boot:spring-boot-autoconfigure:jar:1.5.1.RELEASE:compile
>org.springframework:spring-beans:jar:4.3.6.RELEASE:compile
> Unused declared dependencies found:
>org.springframework.boot:spring-boot-starter-web:jar:1.5.1.RELEASE:compile
>org.springframework.boot:spring-boot-starter-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-starter-actuator:jar:1.5.1.RELEASE:compile{code}
> My initial thought was that perhaps Spring Boot was misuing the Maven
> dependency mechanism through their approach, however that is not their
> interpretation (see the discussion at
> [spring-boot#8341|https://github.com/spring-projects/spring-boot/issues/8341]).
> So, assuming I'm interpreting things correctly, it seems like the thought is
> that Spring Boot's usage of dependencies is A-OK. Given this, and the impact
> of Spring Boot in the Java ecosystem, it seems like it would be good for
> there to be support for this pattern within Maven's dependency analysis. I'm
> not sure what the most appropriate mechanism for this would be, however (and
> whether the dependency plugin is the
[jira] [Updated] (MDEP-712) Merge two JIRA components for dependency-analyzer
[ https://issues.apache.org/jira/browse/MDEP-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-712: --- Labels: S2 (was: ) > Merge two JIRA components for dependency-analyzer > - > > Key: MDEP-712 > URL: https://issues.apache.org/jira/browse/MDEP-712 > Project: Maven Dependency Plugin > Issue Type: Task > Components: analyze >Reporter: Elliotte Rusty Harold >Priority: Minor > Labels: S2 > > Issues for the analyzer have been filed both in MDEP with component analyze > and in MSHARED with component maven-dependency-analyzer. Figure out which we > want to use, update pom.xml, and move everything there. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-417) Dependency incorrectly reported as "Unused declared" when using annotations with RetentionPolicy=Runtime
[
https://issues.apache.org/jira/browse/MDEP-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-417:
---
Labels: S2 close-pending (was: close-pending)
> Dependency incorrectly reported as "Unused declared" when using annotations
> with RetentionPolicy=Runtime
>
>
> Key: MDEP-417
> URL: https://issues.apache.org/jira/browse/MDEP-417
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.8
>Reporter: Florian Brunner
>Priority: Major
> Labels: S2, close-pending
>
> In one project we're using only JPA annotations (e.g.
> javax.persistence.Table; RetentionPolicy=RUNTIME) from one dependency.
> We're declaring the dependency as PROVIDED (but scope=COMPILE fails too):
> {code:xml}
> com.ibm.ws
> jpa-thinclient
> 7.0.0.17.OM01
> provided
> {code}
> The dependency gets incorrectly reported as "Unused declared":
> {noformat}[INFO] --- maven-dependency-plugin:2.8:analyze-only (analyze) @
> my-project ---
> [WARNING] Unused declared dependencies found:
> [WARNING]com.ibm.ws:jpa-thinclient:jar:7.0.0.17.OM01:provided{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-541.
Resolution: Won't Fix
> Allow for a space character as a pathSeparator in dependency:build-classpath
>
>
> Key: MDEP-541
> URL: https://issues.apache.org/jira/browse/MDEP-541
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: build-classpath
>Reporter: Giedrius Noreikis
>Priority: Major
>
> Currently, the {{dependency:build-classpath}} goal does not allow a space
> character to be specified as a {{pathSeparator}}, which is necessary to
> generate {{Class-Path}} values for manifests.
> Because of a check {{isPathSepSet = StringUtils.isNotEmpty( pathSeparator )}}
> in {{BuildClasspathMojo.java}}, the parameter gets ignored in this case, and
> the classpath is built with a default separator.
> The possible workaround is to fix the path with
> {{build-helper:regex-property}}:
> {code:xml}
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> fix-classpath-for-manifest
> prepare-package
> regex-property
>
> appClasspath
> ${appClasspath}
> ;
>
> false
>
>
>
>
> {code}
> but a fix would allow for a more straightforward solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-562) Make extended tokens default for displaying trees
[ https://issues.apache.org/jira/browse/MDEP-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-562: --- Labels: S2 (was: ) > Make extended tokens default for displaying trees > - > > Key: MDEP-562 > URL: https://issues.apache.org/jira/browse/MDEP-562 > Project: Maven Dependency Plugin > Issue Type: Wish > Components: tree >Affects Versions: 3.0.0 >Reporter: Keir >Priority: Major > Labels: S2 > > Now that MSHARED-615 has been merged I would like to propose that this be > made the default behavior. By this point most developers have > unicode-compatible terminals and given the extended characters make the tree > more readable it would be nice to have this as the default option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-541.
--
> Allow for a space character as a pathSeparator in dependency:build-classpath
>
>
> Key: MDEP-541
> URL: https://issues.apache.org/jira/browse/MDEP-541
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: build-classpath
>Reporter: Giedrius Noreikis
>Priority: Major
>
> Currently, the {{dependency:build-classpath}} goal does not allow a space
> character to be specified as a {{pathSeparator}}, which is necessary to
> generate {{Class-Path}} values for manifests.
> Because of a check {{isPathSepSet = StringUtils.isNotEmpty( pathSeparator )}}
> in {{BuildClasspathMojo.java}}, the parameter gets ignored in this case, and
> the classpath is built with a default separator.
> The possible workaround is to fix the path with
> {{build-helper:regex-property}}:
> {code:xml}
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> fix-classpath-for-manifest
> prepare-package
> regex-property
>
> appClasspath
> ${appClasspath}
> ;
>
> false
>
>
>
>
> {code}
> but a fix would allow for a more straightforward solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-609) Dependency analyzer gets confused if the same package is defined in 2 different artifacts
[
https://issues.apache.org/jira/browse/MDEP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-609.
--
> Dependency analyzer gets confused if the same package is defined in 2
> different artifacts
> -
>
> Key: MDEP-609
> URL: https://issues.apache.org/jira/browse/MDEP-609
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Ahmed Hammad
>Priority: Major
>
> The issue might be related to MNG-6415
> If a certain package is defined in 2 different artifacts, and a a maven
> module declares a dependency on these 2 artifacts (once through a transitive
> dependency and once using a declared dependency), dependency analyzer reports
> the dependency as "Used Undeclared", while declared dependencies should
> always take precedence (even if they appear later in the POM)
> For example:
> Project 1 pom:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>test
> project1
> 1.0.0-SNAPSHOT
>
>
> test
> project2
> 1.0.0-SNAPSHOT
>
>
> org.hamcrest
> hamcrest-all
> 1.1
>
>
>
> {code}
> Project 2 pom:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
> test
> project2
> 1.0.0-SNAPSHOT
>
>
> org.hamcrest
> hamcrest-core
> 1.3
>
>
>
> {code}
> And Project 1 uses a package which can be found in both hamcrest-core and
> hamcrest-all:
> {code:java}
> import org.hamcrest.core.IsEqual;
> class Test {
> IsEqual isEqual;
> }
> {code}
> When doing a dependency analysis for Project 1, no "Used undeclared" are
> expected to be seen, because Project 1 declares a dependency on hamcrest-all.
> However, I get:
> [INFO] — maven-dependency-plugin:2.8:analyze (default-cli) @ project1 —
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:1.3:compile
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-596) Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt mojo
[ https://issues.apache.org/jira/browse/MDEP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-596: --- Labels: S2 (was: ) > Need ability to ignore test artifacts or named artifacts in analyze-dep-mgt > mojo > > > Key: MDEP-596 > URL: https://issues.apache.org/jira/browse/MDEP-596 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: analyze, analyze-dep-mgt >Reporter: Keshava Bhat >Priority: Major > Labels: S2 > > Today there is not way to configure to ignore non compile scoped artefacts > (*[ignoreNonCompile|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoreNonCompile])* > / certain ignored artifacts > (*[ignoredDependencies|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html#ignoredDependencies] > )* out of analyze-dep-mgt mojo. > > it would be very sueful to ignore test scoped artifacts or certain enlisted > artifacts to be ignored out of analyze-dep-mgt mojo. > other mojos like analyze / analyze-olnly provide this support. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MDEP-609) Dependency analyzer gets confused if the same package is defined in 2 different artifacts
[
https://issues.apache.org/jira/browse/MDEP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-609.
Resolution: Fixed
> Dependency analyzer gets confused if the same package is defined in 2
> different artifacts
> -
>
> Key: MDEP-609
> URL: https://issues.apache.org/jira/browse/MDEP-609
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.0
>Reporter: Ahmed Hammad
>Priority: Major
>
> The issue might be related to MNG-6415
> If a certain package is defined in 2 different artifacts, and a a maven
> module declares a dependency on these 2 artifacts (once through a transitive
> dependency and once using a declared dependency), dependency analyzer reports
> the dependency as "Used Undeclared", while declared dependencies should
> always take precedence (even if they appear later in the POM)
> For example:
> Project 1 pom:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>test
> project1
> 1.0.0-SNAPSHOT
>
>
> test
> project2
> 1.0.0-SNAPSHOT
>
>
> org.hamcrest
> hamcrest-all
> 1.1
>
>
>
> {code}
> Project 2 pom:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
> test
> project2
> 1.0.0-SNAPSHOT
>
>
> org.hamcrest
> hamcrest-core
> 1.3
>
>
>
> {code}
> And Project 1 uses a package which can be found in both hamcrest-core and
> hamcrest-all:
> {code:java}
> import org.hamcrest.core.IsEqual;
> class Test {
> IsEqual isEqual;
> }
> {code}
> When doing a dependency analysis for Project 1, no "Used undeclared" are
> expected to be seen, because Project 1 declares a dependency on hamcrest-all.
> However, I get:
> [INFO] — maven-dependency-plugin:2.8:analyze (default-cli) @ project1 —
> [WARNING] Used undeclared dependencies found:
> [WARNING] org.hamcrest:hamcrest-core:jar:1.3:compile
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-621) New goal to "fix-warnings"
[ https://issues.apache.org/jira/browse/MDEP-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159990#comment-17159990 ] Elliotte Rusty Harold commented on MDEP-621: My concern about automated fixes is that dependency mediation is order dependent. Where you add a new dependency element matters. > New goal to "fix-warnings" > -- > > Key: MDEP-621 > URL: https://issues.apache.org/jira/browse/MDEP-621 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 3.1.1 >Reporter: Alex Collins >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The analyze goal works well in some scenarios, but time and time again I come > across a large project (100s modules and 1000s dependenencies) where I want > fix the warnings that the "analyze" goal produces. > Fixing these dependency issues will make builds faster, and with large > projects, Maybe 2-5x faster. As they reduce IO and CPU usage, allow the > reactor more flexibily in build order, so parallel builds can make better > usage of the CPU cores. > This is hard to automate, and I've tried a few scripts people have written, > but they're generally not up to the job, typically they are basic: > * Only work on one pom, not multi-module projects. > * Do multi-module, but don't follow reactor order. > * Try to remove the wrong dependencies. > * Don't check the removal worked OK, e.g. > ** Removing annotation processors. > ** Removing "magic" jars, those that appear unused, but actually are some > how (e.g. some Spring class-path scanning magic). > My thought is to introduce a new goal that peforms the following steps for > each pom in reactor order: > # Verify the module isn't broken to start with (clean install). > # Check-point (save a backup of the pom.xml). > # Perform dependency analysis. > # Add in all used undeclared dependencies. > # Verify - check that didn't break anything (clean install) and give up if > it did. > # Check-point. > # Remove all unused declared dependencies (i.e. see if any of them are > needed at all, this assumes that there is a good probabily that is the case > and is quicker than testing each in order). > # Check-point > # Verify. > # For each unused declared dependency. > # Check-point. > # Remove. > # Validate. > I'm making a key assumption here that if a module's tests pass, then it's > just fine. That's a big assumption, but I see no feasible way to make this > work otherwise. > Many projects have "terminal" modules, i.e. modules that have no downstream > dependencies. It would be risky to remove "magic" dependencies, so it maybe > the case we want to bookend this process by > # Determine "terminal" modules. > # For each terminal module, create a list of their dependencies. > # Do the fix as discussed above. > # For each terminal module, create a list of their dependencies. > # Re-instate any that were removed. > Whadaythink? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-646) mvn dependency:analyze mistakenly treat backward compatible classes as used undeclared
[
https://issues.apache.org/jira/browse/MDEP-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-646:
---
Labels: intern (was: )
> mvn dependency:analyze mistakenly treat backward compatible classes as used
> undeclared
> --
>
> Key: MDEP-646
> URL: https://issues.apache.org/jira/browse/MDEP-646
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.1.1
>Reporter: John Lin
>Priority: Major
> Labels: intern
>
> I have the following dependency in my {{pom.xml}}:
> {code}
>
> org.apache.cassandra
> cassandra-all
> 2.1.8
>
> {code}
> Then a piece of code in my app:
> {code}
> import java.util.concurrent.ConcurrentHashMap;
> public class App {
> public void foo () {
> ConcurrentHashMap m = new ConcurrentHashMap<>();
> ...
> }
> }
> {code}
> Then {{mvn dependency:analyze}} will find a used undeclared dependency:
> {code}
> [WARNING] Used undeclared dependencies found:
> [WARNING]com.boundary:high-scale-lib:jar:1.0.6:compile
> {code}
> It turns out that {{cassandra-all}} has a dependency on {{high-scale-lib}},
> and {{high-scale-lib}} implemented a
> {{java.util.concurrent.ConcurrentHashMap}} for backward compatibility.
> In fact, my app use the built-in {{ConcurrentHashMap}} in JDK, not the
> {{ConcurrentHashMap}} from {{high-scale-lib}}. So I believe that it is
> incorrect for the dependency analysis to report it as used.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MDEP-435) improve mvn dependency:tree - add optional xml output of the results
[ https://issues.apache.org/jira/browse/MDEP-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MDEP-435: -- Assignee: Elliotte Rusty Harold > improve mvn dependency:tree - add optional xml output of the results > > > Key: MDEP-435 > URL: https://issues.apache.org/jira/browse/MDEP-435 > Project: Maven Dependency Plugin > Issue Type: Improvement > Components: tree > Environment: all >Reporter: Kow Unk >Assignee: Elliotte Rusty Harold >Priority: Major > Labels: close-pending > Time Spent: 10m > Remaining Estimate: 0h > > The output of mvn dependency:tree would be more useful to me if it was in a > format that is machine readable. I would like to create some tooling to be > able to easily determine what is causing a particular jar to be included. > for example: > >mymvntool -why org.springframework:org.springframework.beans:3.0.5 > org.springframework.beans-3.0.5 is being *dragged* in by: > my.otherproject.core:1.1 > %end of search > another use: > >mymvntool -makeexclusionfor > >org.springframework:org.springframework.beans:3.0.5 > > >org.springframework >org.springframework.beans > > > or even: > >mymvntool -makeexclusionfor org.springframework:*:3.0.5 > this would pickup all the included jars in the project and build exclusions > for them. > It may have been dumb to pick spring as the exclusion resource, but this is > just an example. having xml output would be valuable to me and probably > others too. > -K -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] elharo opened a new pull request #84: docs: don't assume people are using Eclipse
elharo opened a new pull request #84: URL: https://github.com/apache/maven-dependency-plugin/pull/84 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (MDEP-575) Inconsistent behaviour in dependency:sources between maven-dependency-plugin:2.10 and maven-dependency-plugin:3.0.z
[
https://issues.apache.org/jira/browse/MDEP-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-575.
Resolution: Cannot Reproduce
> Inconsistent behaviour in dependency:sources between
> maven-dependency-plugin:2.10 and maven-dependency-plugin:3.0.z
> ---
>
> Key: MDEP-575
> URL: https://issues.apache.org/jira/browse/MDEP-575
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Michal Jurc
>Priority: Major
>
> The {{dependency:sources}} goal behaves inconsistently between 2.10 and later
> versions of the dependency plugin with dependencies provided by BOMs:
> {code:title=mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:sources}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building WildFly Quickstart: helloworld 11.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.10:sources (default-cli) @ helloworld ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:sources:1.0.0.Final:provided
> [INFO]javax.enterprise:cdi-api:jar:sources:1.2:provided
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:sources:1.0.0.Final:provided
> [INFO]javax.inject:javax.inject:jar:sources:1:provided
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.870 s
> [INFO] Finished at: 2017-07-10T14:32:55+02:00
> [INFO] Final Memory: 14M/298M
> [INFO]
>
> {code}
> {code:title=mvn
> org.apache.maven.plugins:maven-dependency-plugin:3.0.z:sources}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building WildFly Quickstart: helloworld 11.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:sources (default-cli) @ helloworld
> ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]javax.enterprise:cdi-api:jar:sources:1.2
> [INFO]javax.inject:javax.inject:jar:sources:1
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:sources:1.0.0.Final
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:sources:1.0.0.Final
> [INFO]
> [INFO] The following files have NOT been resolved:
> [INFO]javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]javax.inject:javax.inject:jar:1:provided
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.815 s
> [INFO] Finished at: 2017-07-10T14:33:07+02:00
> [INFO] Final Memory: 13M/298M
> [INFO]
>
> {code}
> The project used can be found
> [here|https://github.com/wildfly/quickstart/tree/11.x/helloworld].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-575) Inconsistent behaviour in dependency:sources between maven-dependency-plugin:2.10 and maven-dependency-plugin:3.0.z
[
https://issues.apache.org/jira/browse/MDEP-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-575.
--
> Inconsistent behaviour in dependency:sources between
> maven-dependency-plugin:2.10 and maven-dependency-plugin:3.0.z
> ---
>
> Key: MDEP-575
> URL: https://issues.apache.org/jira/browse/MDEP-575
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Michal Jurc
>Priority: Major
>
> The {{dependency:sources}} goal behaves inconsistently between 2.10 and later
> versions of the dependency plugin with dependencies provided by BOMs:
> {code:title=mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:sources}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building WildFly Quickstart: helloworld 11.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.10:sources (default-cli) @ helloworld ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:sources:1.0.0.Final:provided
> [INFO]javax.enterprise:cdi-api:jar:sources:1.2:provided
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:sources:1.0.0.Final:provided
> [INFO]javax.inject:javax.inject:jar:sources:1:provided
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.870 s
> [INFO] Finished at: 2017-07-10T14:32:55+02:00
> [INFO] Final Memory: 14M/298M
> [INFO]
>
> {code}
> {code:title=mvn
> org.apache.maven.plugins:maven-dependency-plugin:3.0.z:sources}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building WildFly Quickstart: helloworld 11.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:3.0.1:sources (default-cli) @ helloworld
> ---
> [INFO]
> [INFO] The following files have been resolved:
> [INFO]javax.enterprise:cdi-api:jar:sources:1.2
> [INFO]javax.inject:javax.inject:jar:sources:1
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:sources:1.0.0.Final
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:sources:1.0.0.Final
> [INFO]
> [INFO] The following files have NOT been resolved:
> [INFO]javax.enterprise:cdi-api:jar:1.2:provided
> [INFO]javax.inject:javax.inject:jar:1:provided
> [INFO]
> org.jboss.spec.javax.annotation:jboss-annotations-api_1.2_spec:jar:1.0.0.Final:provided
> [INFO]
> org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.815 s
> [INFO] Finished at: 2017-07-10T14:33:07+02:00
> [INFO] Final Memory: 13M/298M
> [INFO]
>
> {code}
> The project used can be found
> [here|https://github.com/wildfly/quickstart/tree/11.x/helloworld].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MDEP-687) includeScope=runtime for copy-dependencies does not include transitive compile-time dependencies
[
https://issues.apache.org/jira/browse/MDEP-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MDEP-687.
Resolution: Not A Bug
> includeScope=runtime for copy-dependencies does not include transitive
> compile-time dependencies
>
>
> Key: MDEP-687
> URL: https://issues.apache.org/jira/browse/MDEP-687
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Dmitry Andrianov
>Priority: Major
>
> We using {{copy-dependencies}} from dependency plugin to collect all the
> libraries needed by the application at runtime into a {{lib/}} directory. We
> obviously do not want to include any test dependencies so we are setting
> {code:xml}
> runtime{code}
> It normally works as expected except for one case. Imagine::
> {code:java}
> application
> |
> + libOne (test)
> |
> + libTwo (compile)
> |
> + libOne (compile)
> {code}
> With this layout our application only needs {{libOne}} during tests but at
> the same time we depend on {{libTwo}} which in turn depends on {{libOne}}. In
> the end {{libOne}} is required for the application to function. Unfortunately
> it gets excluded by {{copy-dependencies}} with {{scope=runtime}}. This is a
> nasty surprise given the documentation
> [https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#includeScope]
> says
> {quote}The scopes being interpreted are the scopes as Maven sees them, not as
> specified in the pom.
> {quote}
> Surely, Maven should see {{libOne}} as a runtime thing when resolving
> dependencies...
> Below is a full POM that reproduces the case (with arbitrary libraries
> though).
> We have {{logback-access}} as compile dependency and it should bring
> {{logback-core}} with it but because we also declare {{logback-core}} as a
> test dependency for the application - it gets demoted to test only and not
> included into {{lib/}} directory.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> test
> pom-test
> 0.1
> jar
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.2
>
>
> copy-dependencies
> package
>
> copy-dependencies
>
>
>
> ${project.build.directory}/lib
>
> runtime
>
>
>
>
>
>
>
>
> ch.qos.logback
> logback-access
> 1.2.2
>
>
> ch.qos.logback
> logback-core
> 1.2.2
>
>
>
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.25
>
> test
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-687) includeScope=runtime for copy-dependencies does not include transitive compile-time dependencies
[
https://issues.apache.org/jira/browse/MDEP-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MDEP-687.
--
> includeScope=runtime for copy-dependencies does not include transitive
> compile-time dependencies
>
>
> Key: MDEP-687
> URL: https://issues.apache.org/jira/browse/MDEP-687
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Reporter: Dmitry Andrianov
>Priority: Major
>
> We using {{copy-dependencies}} from dependency plugin to collect all the
> libraries needed by the application at runtime into a {{lib/}} directory. We
> obviously do not want to include any test dependencies so we are setting
> {code:xml}
> runtime{code}
> It normally works as expected except for one case. Imagine::
> {code:java}
> application
> |
> + libOne (test)
> |
> + libTwo (compile)
> |
> + libOne (compile)
> {code}
> With this layout our application only needs {{libOne}} during tests but at
> the same time we depend on {{libTwo}} which in turn depends on {{libOne}}. In
> the end {{libOne}} is required for the application to function. Unfortunately
> it gets excluded by {{copy-dependencies}} with {{scope=runtime}}. This is a
> nasty surprise given the documentation
> [https://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html#includeScope]
> says
> {quote}The scopes being interpreted are the scopes as Maven sees them, not as
> specified in the pom.
> {quote}
> Surely, Maven should see {{libOne}} as a runtime thing when resolving
> dependencies...
> Below is a full POM that reproduces the case (with arbitrary libraries
> though).
> We have {{logback-access}} as compile dependency and it should bring
> {{logback-core}} with it but because we also declare {{logback-core}} as a
> test dependency for the application - it gets demoted to test only and not
> included into {{lib/}} directory.
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
> test
> pom-test
> 0.1
> jar
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.2
>
>
> copy-dependencies
> package
>
> copy-dependencies
>
>
>
> ${project.build.directory}/lib
>
> runtime
>
>
>
>
>
>
>
>
> ch.qos.logback
> logback-access
> 1.2.2
>
>
> ch.qos.logback
> logback-core
> 1.2.2
>
>
>
> test
>
>
> org.slf4j
> slf4j-api
> 1.7.25
>
> test
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MDEP-694) Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...)
[ https://issues.apache.org/jira/browse/MDEP-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MDEP-694. Resolution: Won't Fix > Include import-scoped dependency in the output of the dependency plugin goals > (e.g. `analyze`, `resolve`, `tree`, `list`, ...) > -- > > Key: MDEP-694 > URL: https://issues.apache.org/jira/browse/MDEP-694 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: John Wu >Priority: Major > Attachments: hello-bom.pom.xml, hello-model.pom.xml > > > * Currently, there is no way to include/show an import-scoped dependency in > the output of `dependency:list` (and other similar goals). It is understood > that an import-scoped dependency won't result in any binary form artifact > (such as jar, war, zip, etc). But it is, by definition, a project dependency. > Not listing it in the output prevents tools/scripts from detecting such > dependency relationship (without parsing the POM file), thus further messing > up the build/manipulation process; > * See the attached POM file of `hello-bom` and `hello-model` for examples; > * It's acceptable to add an option to control if import-scoped dependency > should be included in the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-694) Include import-scoped dependency in the output of the dependency plugin goals (e.g. `analyze`, `resolve`, `tree`, `list`, ...)
[ https://issues.apache.org/jira/browse/MDEP-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159979#comment-17159979 ] Elliotte Rusty Harold commented on MDEP-694: If I understand what you're asking for, this is problematic. Imports do not become part of the classpath and do not form part of the dependency tree or graph, unless there's a separate dependency element elsewhere in the tree. An import is essentially a macro that might or might not be used. If that's not what you're thinking please elaborate on the use case. > Include import-scoped dependency in the output of the dependency plugin goals > (e.g. `analyze`, `resolve`, `tree`, `list`, ...) > -- > > Key: MDEP-694 > URL: https://issues.apache.org/jira/browse/MDEP-694 > Project: Maven Dependency Plugin > Issue Type: Improvement >Reporter: John Wu >Priority: Major > Attachments: hello-bom.pom.xml, hello-model.pom.xml > > > * Currently, there is no way to include/show an import-scoped dependency in > the output of `dependency:list` (and other similar goals). It is understood > that an import-scoped dependency won't result in any binary form artifact > (such as jar, war, zip, etc). But it is, by definition, a project dependency. > Not listing it in the output prevents tools/scripts from detecting such > dependency relationship (without parsing the POM file), thus further messing > up the build/manipulation process; > * See the attached POM file of `hello-bom` and `hello-model` for examples; > * It's acceptable to add an option to control if import-scoped dependency > should be included in the output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-691) useBaseVersion ignored when resolving artifacts from local repository (works from remote)
[
https://issues.apache.org/jira/browse/MDEP-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-691:
---
Summary: useBaseVersion ignored when resolving artifacts from local
repository (works from remote) (was: useBaseVersion ignored when resolving
artifacts from lolcal repostory (works from remote))
> useBaseVersion ignored when resolving artifacts from local repository (works
> from remote)
> -
>
> Key: MDEP-691
> URL: https://issues.apache.org/jira/browse/MDEP-691
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy
>Reporter: Jakub Bochenski
>Priority: Major
>
> Please compare the results. {{-Psonatype}} enables remote sonatype snapshots
> repository.
> {code}$ mvn dependency:copy
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype
> -U -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-20190311.143402-1.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn dependency:copy
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -Psonatype
> -U -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn dependency:copy
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o
> -Dmdep.useBaseVersion=true | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ rm -rf '/home/bochja/${project.basedir}/target/dependency'
> $ mvn dependency:copy
> -Dartifact=com.trello.identifier:package-identifier:0.0.2-SNAPSHOT -o
> -Dmdep.useBaseVersion=false | grep Copying
> [INFO] Copying package-identifier-0.0.2-SNAPSHOT.jar to
> /home/bochja/${project.basedir}/target/dependency/package-identifier-0.0.2-SNAPSHOT.jar
> $ ls ~/.m2/repository/com/trello/identifier/package-identifier/0.0.2-SNAPSHOT/
> maven-metadata-sonatype.xml maven-metadata-sonatype.xml.sha1
> package-identifier-0.0.2-20190311.143402-1.jar
> package-identifier-0.0.2-20190311.143402-1.jar.sha1
> package-identifier-0.0.2-SNAPSHOT.jar _remote.repositories
> resolver-status.properties
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-437) Create symbolic links instead of physical copies
[ https://issues.apache.org/jira/browse/MDEP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159976#comment-17159976 ] Elliotte Rusty Harold commented on MDEP-437: Can you elaborate on what you envision here? > Create symbolic links instead of physical copies > > > Key: MDEP-437 > URL: https://issues.apache.org/jira/browse/MDEP-437 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: copy >Affects Versions: 3.1.2 > Environment: JDK 7u51, Win 7 Pro SP1 (64 Bit) >Reporter: Markus Karg >Priority: Major > > When copying lots of resources, especially huge ones (e. g. we are dealing > with two gigabytes (!) split up into several 100 MB large binaries) it is > tedious to wait until the copy task has performed real physical copies... > Since JRE 7 Java (which is public for years meanwhile) can deal with symbolic > links, it would be really cool if one could add a true > configuration option, so the plugin could simply go the fast lane and use > symbolic links instead of physical copies. > For backwards compatibility unfortunately the default has to be "false". :-( -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-699) Create a goal to add a new dependency to an existing pom
[ https://issues.apache.org/jira/browse/MDEP-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159973#comment-17159973 ] Elliotte Rusty Harold commented on MDEP-699: Why would you want to do this instead of simply editing pom.xml? Especially given Maven's order dependent dependency mediation, I'm not sure this is feasible since adding one dependency can change the versions of other artifacts. > Create a goal to add a new dependency to an existing pom > > > Key: MDEP-699 > URL: https://issues.apache.org/jira/browse/MDEP-699 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: QualiteSys QualiteSys >Priority: Major > > I work with third party or open source maven projesct, and existing pom > files. I would like to insert additional dependencies to the pom, in command > line, not via manual editing or shells. Is it possible to create a specific > goal for that ? > Thanks for your help -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEP-699) Create a goal to add a new dependency to an existing pom
[ https://issues.apache.org/jira/browse/MDEP-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MDEP-699: --- Priority: Minor (was: Major) > Create a goal to add a new dependency to an existing pom > > > Key: MDEP-699 > URL: https://issues.apache.org/jira/browse/MDEP-699 > Project: Maven Dependency Plugin > Issue Type: New Feature >Reporter: QualiteSys QualiteSys >Priority: Minor > > I work with third party or open source maven projesct, and existing pom > files. I would like to insert additional dependencies to the pom, in command > line, not via manual editing or shells. Is it possible to create a specific > goal for that ? > Thanks for your help -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-701) Update maven artifact transfer to 0.12.0
[ https://issues.apache.org/jira/browse/MDEP-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159971#comment-17159971 ] Elliotte Rusty Harold commented on MDEP-701: MSHARED-913 > Update maven artifact transfer to 0.12.0 > > > Key: MDEP-701 > URL: https://issues.apache.org/jira/browse/MDEP-701 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold reassigned MRESOURCES-232:
Assignee: Dennis Lundberg
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Assignee: Dennis Lundberg
>Priority: Major
> Labels: maven
> Fix For: 3.2.0
>
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MRESOURCES-232:
-
Fix Version/s: 3.2.0
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
> Labels: maven
> Fix For: 3.2.0
>
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MSHARED-937) Demote log statement to debug
Elliotte Rusty Harold created MSHARED-937:
-
Summary: Demote log statement to debug
Key: MSHARED-937
URL: https://issues.apache.org/jira/browse/MSHARED-937
Project: Maven Shared Components
Issue Type: Improvement
Reporter: Elliotte Rusty Harold
In line 144 of DefaultMavenResourcesFiltering we have:
{{else
{
getLogger().info( "Using '" + mavenResourcesExecution.getEncoding()
+ "' encoding to copy filtered resources." );
}}}
This produces a lot of log junk and is inconsistent with most other locations
in the file such as line 237 where similar messages are logged at DEBUG level.
This message should be debug too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-904) update Maven core 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159940#comment-17159940 ] Hudson commented on MSHARED-904: Build succeeded in Jenkins: Maven TLP » maven-shared-utils » master #90 See https://builds.apache.org/job/maven-box/job/maven-shared-utils/job/master/90/ > update Maven core 3.1.0 > --- > > Key: MSHARED-904 > URL: https://issues.apache.org/jira/browse/MSHARED-904 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Affects Versions: maven-shared-utils-3.3.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resources-plugin] elharo merged pull request #5: try with resources
elharo merged pull request #5: URL: https://github.com/apache/maven-resources-plugin/pull/5 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-904) update Maven core 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-904: -- Affects Version/s: maven-shared-utils-3.3.0 > update Maven core 3.1.0 > --- > > Key: MSHARED-904 > URL: https://issues.apache.org/jira/browse/MSHARED-904 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Affects Versions: maven-shared-utils-3.3.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHARED-904) update Maven core 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-904. - > update Maven core 3.1.0 > --- > > Key: MSHARED-904 > URL: https://issues.apache.org/jira/browse/MSHARED-904 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Affects Versions: maven-shared-utils-3.3.0 >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resources-plugin] pzygielo commented on a change in pull request #5: try with resources
pzygielo commented on a change in pull request #5:
URL:
https://github.com/apache/maven-resources-plugin/pull/5#discussion_r456444223
##
File path:
src/test/java/org/apache/maven/plugins/resources/stub/MavenProjectBuildStub.java
##
@@ -300,8 +293,6 @@ private void populateFile( File file ) throws IOException
try ( FileOutputStream outputStream = new FileOutputStream( file )
)
{
outputStream.write( data.getBytes() );
-outputStream.flush();
Review comment:
~I think @roxspring is right about FOS not wrapped in BOS not being
problem for flushing or not. But I'm not sure that close also flushes. There is
`flush` called in `FOS.finalize` but `close` inherited from `OutputStream` is
no-op (immaterial), as `FOS.close` doesn't seem to call flush neither.~
~On the other hand~ `close` of `BufferedOutputStream` flushes
indeed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #57: [MSHARED-904] update test dependencies for Maven 3.1
elharo merged pull request #57: URL: https://github.com/apache/maven-shared-utils/pull/57 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (MSHARED-904) update Maven core 3.1.0
[ https://issues.apache.org/jira/browse/MSHARED-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-904. --- Resolution: Fixed > update Maven core 3.1.0 > --- > > Key: MSHARED-904 > URL: https://issues.apache.org/jira/browse/MSHARED-904 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159937#comment-17159937
]
Hudson commented on MRESOURCES-232:
---
Build succeeded in Jenkins: Maven TLP » maven-resources-plugin » master #64
See
https://builds.apache.org/job/maven-box/job/maven-resources-plugin/job/master/64/
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
> Labels: maven
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-232) Resource copy filtering should use different encoding for source and output
[
https://issues.apache.org/jira/browse/MRESOURCES-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159935#comment-17159935
]
Dennis Lundberg commented on MRESOURCES-232:
I have updated the documentation for the "encoding" parameter to clarify that
it is used for both reading and writing resources. That will come with version
3.2.0 of the plugin.
The need for different input and output encoding parameters have not yet been
solved.
> Resource copy filtering should use different encoding for source and output
> ---
>
> Key: MRESOURCES-232
> URL: https://issues.apache.org/jira/browse/MRESOURCES-232
> Project: Maven Resources Plugin
> Issue Type: New Feature
> Components: copy, filtering
>Affects Versions: 3.0.1
> Environment: Ubuntu 16.04 JDK 1.8 maven 3.3.4
>Reporter: Peng Cheng
>Priority: Major
> Labels: maven
>
> In copy-resources goal. The configuration option 'encoding' is documented to
> be capable of changing the encoding of source files and copy to output
> directory, e.g.:
> {code}
>
>
> ${project.basedir}/sbin-ebcdic
>
>
> ${project.basedir}/sbin
>
>
> IBM037
>
> {code}
> However, it is pointed out in the answer section of this post:
> http://stackoverflow.com/questions/40095716/why-maven-resources-plugin-ignores-my-charset-encoding-setting
> that this option affects both reading of source file and writing of output
> file, resulting in most of the file encodings not converted. This should be
> corrected by dividing this option into 2:
> sourceEncoding & outputEncoding, which controls reading and writing
> separately. This is the most simple way to make encoding conversion practical.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resources-plugin] pzygielo commented on a change in pull request #5: try with resources
pzygielo commented on a change in pull request #5:
URL:
https://github.com/apache/maven-resources-plugin/pull/5#discussion_r456444223
##
File path:
src/test/java/org/apache/maven/plugins/resources/stub/MavenProjectBuildStub.java
##
@@ -300,8 +293,6 @@ private void populateFile( File file ) throws IOException
try ( FileOutputStream outputStream = new FileOutputStream( file )
)
{
outputStream.write( data.getBytes() );
-outputStream.flush();
Review comment:
I think @roxspring is right about FOS not wrapped in BOS not being
problem for flushing or not. But I'm not sure that
> close also flushes
is true. There is `flush` called in `FOS.finalize` ~but `close` inherited
from `OutputStream` is no-op~ (immaterial), as `FOS.close` doesn't seem to call
flush neither.
On the other hand - `close` of `BufferedOutputStream` flushes indeed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resources-plugin] rmannibucau commented on a change in pull request #5: try with resources
rmannibucau commented on a change in pull request #5:
URL:
https://github.com/apache/maven-resources-plugin/pull/5#discussion_r456447966
##
File path:
src/test/java/org/apache/maven/plugins/resources/stub/MavenProjectBuildStub.java
##
@@ -300,8 +293,6 @@ private void populateFile( File file ) throws IOException
try ( FileOutputStream outputStream = new FileOutputStream( file )
)
{
outputStream.write( data.getBytes() );
-outputStream.flush();
Review comment:
Calling flush just before close is generally useless cause close ensures
all data have been written.
That said we are speaking of a FileOutputStream where flush() is a noop so
it is even safer to drop.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resources-plugin] pzygielo commented on a change in pull request #5: try with resources
pzygielo commented on a change in pull request #5:
URL:
https://github.com/apache/maven-resources-plugin/pull/5#discussion_r456444223
##
File path:
src/test/java/org/apache/maven/plugins/resources/stub/MavenProjectBuildStub.java
##
@@ -300,8 +293,6 @@ private void populateFile( File file ) throws IOException
try ( FileOutputStream outputStream = new FileOutputStream( file )
)
{
outputStream.write( data.getBytes() );
-outputStream.flush();
Review comment:
I think @roxspring is right about FOS not wrapped in BOS not being
problem for flushing or not. But I'm not sure that
> close also flushes
is true. There is `flush` called in `FOS.finalize` ~but `close` inherited
from `OutputStream` is no-op~ (immaterial), as `FOS.close` doesn't seem to call
flush neither.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resources-plugin] pzygielo commented on a change in pull request #5: try with resources
pzygielo commented on a change in pull request #5:
URL:
https://github.com/apache/maven-resources-plugin/pull/5#discussion_r456444223
##
File path:
src/test/java/org/apache/maven/plugins/resources/stub/MavenProjectBuildStub.java
##
@@ -300,8 +293,6 @@ private void populateFile( File file ) throws IOException
try ( FileOutputStream outputStream = new FileOutputStream( file )
)
{
outputStream.write( data.getBytes() );
-outputStream.flush();
Review comment:
I think @roxspring is right about FOS not wrapped in BOS not being
problem for flushing or not. But I'm not sure that
> close also flushes
is true. There is `flush` called in `FOS.finalize` but `close` inherited
from `OutputStream` is no-op.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
