[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501680#comment-17501680
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 3/5/22, 7:43 AM:
Sorry, the M6 snapshots never work for me (have not for months now), because I
always get:
{code:none}
Downloading from central:
https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-shared-utils/$%7Bsurefire-shared-utils.version%7D/surefire-shared-utils-$%7Bsurefire-shared-utils.version%7D.pom
[WARNING] The POM for
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
is missing, no dependency information available
(...)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test
(default-test) on project perform-tests: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test failed:
Plugin org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
{code}
Can you see in the download URL how it is trying to use the unexpanded
{{${surefire-shared-utils.version}}} variable as a version number? Something is
awry there.
was (Author: kriegaex):
Sorry, the M6 snapshots never work for me (have not for months now), because I
always get:
{code:none}
[WARNING] The POM for
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
is missing, no dependency information available
(...)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test
(default-test) on project perform-tests: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test failed:
Plugin org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
{code}
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501680#comment-17501680
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 3/5/22, 7:34 AM:
Sorry, the M6 snapshots never work for me (have not for months now), because I
always get:
{code:none}
[WARNING] The POM for
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
is missing, no dependency information available
(...)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test
(default-test) on project perform-tests: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test failed:
Plugin org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
{code}
was (Author: kriegaex):
Sorry, the M6 snapshots never work for me because I always get:
{code:none}
[WARNING] The POM for
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
is missing, no dependency information available
(...)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test
(default-test) on project perform-tests: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test failed:
Plugin org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
{code}
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501680#comment-17501680
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
Sorry, the M6 snapshots never work for me because I always get:
{code:none}
[WARNING] The POM for
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
is missing, no dependency information available
(...)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test
(default-test) on project perform-tests: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT:test failed:
Plugin org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6-SNAPSHOT or one
of its dependencies could not be resolved: Could not find artifact
org.apache.maven.surefire:surefire-shared-utils:jar:${surefire-shared-utils.version}
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
{code}
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MCOMPILER-346) JDK10: Compiler plugin trips AssertionError inside javac when using javax.tools API
[
https://issues.apache.org/jira/browse/MCOMPILER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501666#comment-17501666
]
Basil Crow commented on MCOMPILER-346:
--
bq. Can you please add some license on it (such Apache) otherwise I cannot
import it here thanks
Sure, I added an Apache license file.
> JDK10: Compiler plugin trips AssertionError inside javac when using
> javax.tools API
> ---
>
> Key: MCOMPILER-346
> URL: https://issues.apache.org/jira/browse/MCOMPILER-346
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: log.txt, sample_project.tgz
>
>
> Maven 3.5.3, 64-bit linux, Oracle JDK 10.0.1
> Compilation fails with a crash inside javac *unless* the
> maven-compiler-plugin is configured with
> {code:java}
> true{code}
> I had a brief look at the sources of Modules.java in the current OpenJDK10
> and it looks like this is the assertion that gets tripped (line numbers do
> not match exactly but it's close enough):
> {code:java}
> public boolean enter(List trees, ClassSymbol c) {
> Assert.check(rootModules != null || inInitModules || !allowModules);
> return enter(trees, modules -> {}, c);
> }
> {code}
> Since the crash does not happen when invoking the compiler using commandline
> arguments I suspect the plugin does something unexpected with the javax.tools
> JavaCompiler API that later trips the exception.
> Unfortunately this is a commercial project so I cannot provide a test case :(
> The project itself is a JDK8 project we're currently migrating to JDK10 and
> while the project itself has no module-info files some of our dependencies do
> (at least Automatic-Module-Name gets set in their manifests).
> I'll attach the output of a compile run with the '-verbose' option to this
> ticket.
> Plugin configuration:
> {code:java}
>
>
>
> maven-compiler-plugin
> 3.7.0
>
> 10
> 10
> 10
>
>
> -Werror
> -verbose
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
> at
> jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:244)
> at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:829)
> at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1506)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1308)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
> at
>
[jira] [Commented] (MCOMPILER-346) JDK10: Compiler plugin trips AssertionError inside javac when using javax.tools API
[
https://issues.apache.org/jira/browse/MCOMPILER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501651#comment-17501651
]
Olivier Lamy commented on MCOMPILER-346:
Ok there might be some error message report when looking at diagnostic here
[https://github.com/codehaus-plexus/plexus-compiler/blob/88562f744be32359d8cb3c4ce584439061ada74b/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java#L137]
[~basil] thanks to provide an example project. Can you please add some license
on it (such Apache) otherwise I cannot import it here thanks
> JDK10: Compiler plugin trips AssertionError inside javac when using
> javax.tools API
> ---
>
> Key: MCOMPILER-346
> URL: https://issues.apache.org/jira/browse/MCOMPILER-346
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: log.txt, sample_project.tgz
>
>
> Maven 3.5.3, 64-bit linux, Oracle JDK 10.0.1
> Compilation fails with a crash inside javac *unless* the
> maven-compiler-plugin is configured with
> {code:java}
> true{code}
> I had a brief look at the sources of Modules.java in the current OpenJDK10
> and it looks like this is the assertion that gets tripped (line numbers do
> not match exactly but it's close enough):
> {code:java}
> public boolean enter(List trees, ClassSymbol c) {
> Assert.check(rootModules != null || inInitModules || !allowModules);
> return enter(trees, modules -> {}, c);
> }
> {code}
> Since the crash does not happen when invoking the compiler using commandline
> arguments I suspect the plugin does something unexpected with the javax.tools
> JavaCompiler API that later trips the exception.
> Unfortunately this is a commercial project so I cannot provide a test case :(
> The project itself is a JDK8 project we're currently migrating to JDK10 and
> while the project itself has no module-info files some of our dependencies do
> (at least Automatic-Module-Name gets set in their manifests).
> I'll attach the output of a compile run with the '-verbose' option to this
> ticket.
> Plugin configuration:
> {code:java}
>
>
>
> maven-compiler-plugin
> 3.7.0
>
> 10
> 10
> 10
>
>
> -Werror
> -verbose
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
> at
> jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:244)
> at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:829)
> at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1506)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1308)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
>
[jira] [Commented] (MCOMPILER-346) JDK10: Compiler plugin trips AssertionError inside javac when using javax.tools API
[
https://issues.apache.org/jira/browse/MCOMPILER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501618#comment-17501618
]
Basil Crow commented on MCOMPILER-346:
--
I have run into this bug repeatedly while working on Jenkins. I created a
[Minimal Reproducible Example (MRE)|https://github.com/basil/MCOMPILER-346-mre].
> JDK10: Compiler plugin trips AssertionError inside javac when using
> javax.tools API
> ---
>
> Key: MCOMPILER-346
> URL: https://issues.apache.org/jira/browse/MCOMPILER-346
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Tobias Gierke
>Priority: Major
> Attachments: log.txt, sample_project.tgz
>
>
> Maven 3.5.3, 64-bit linux, Oracle JDK 10.0.1
> Compilation fails with a crash inside javac *unless* the
> maven-compiler-plugin is configured with
> {code:java}
> true{code}
> I had a brief look at the sources of Modules.java in the current OpenJDK10
> and it looks like this is the assertion that gets tripped (line numbers do
> not match exactly but it's close enough):
> {code:java}
> public boolean enter(List trees, ClassSymbol c) {
> Assert.check(rootModules != null || inInitModules || !allowModules);
> return enter(trees, modules -> {}, c);
> }
> {code}
> Since the crash does not happen when invoking the compiler using commandline
> arguments I suspect the plugin does something unexpected with the javax.tools
> JavaCompiler API that later trips the exception.
> Unfortunately this is a commercial project so I cannot provide a test case :(
> The project itself is a JDK8 project we're currently migrating to JDK10 and
> while the project itself has no module-info files some of our dependencies do
> (at least Automatic-Module-Name gets set in their manifests).
> I'll attach the output of a compile run with the '-verbose' option to this
> ticket.
> Plugin configuration:
> {code:java}
>
>
>
> maven-compiler-plugin
> 3.7.0
>
> 10
> 10
> 10
>
>
> -Werror
> -verbose
>
>
>
>
>
> {code}
> Exception:
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
> at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
> at
> jdk.compiler/com.sun.tools.javac.comp.Modules.enter(Modules.java:244)
> at
> jdk.compiler/com.sun.tools.javac.main.JavaCompiler.readSourceFile(JavaCompiler.java:829)
> at
> jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete(JavacProcessingEnvironment.java:1506)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol.complete(Symbol.java:633)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1308)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.complete(Type.java:1139)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.getTypeArguments(Type.java:1065)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:237)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visitClassType(Printer.java:52)
> at
> jdk.compiler/com.sun.tools.javac.code.Type$ClassType.accept(Type.java:992)
> at
> jdk.compiler/com.sun.tools.javac.code.Printer.visit(Printer.java:136)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:197)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument(AbstractDiagnosticFormatter.java:183)
> at
> jdk.compiler/com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments(AbstractDiagnosticFormatter.java:165)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:111)
> at
> jdk.compiler/com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage(BasicDiagnosticFormatter.java:67)
> at
> jdk.compiler/com.sun.tools.javac.util.JCDiagnostic.getMessage(JCDiagnostic.java:771)
> at
>
[GitHub] [maven-surefire] olamy commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
olamy commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1059594016 > @olamy I don't have time to fight with someone about words. I told the guys that it should be shifted to the right module but you won't understand it and you are basically a speaker of your colleague @imonteroperez . You both were informed. Everybody is happy if I take the commit and simplify his time, so pls appreciate it! please try to understand, there are potentially 2 problems here: - as you completely remove the original author from the git history, it's social/community issue. We should respect our contributors and give them credit. - if you used commits from someone else. The author should be part of the history somewhere. This is breaking IP history. it's a legal problem! -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] olamy removed a comment on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
olamy removed a comment on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1059591752 > @olamy I don't have time to fight with someone about words. I told the guys that it should be shifted to the right module but you won't understand it and you are basically a speaker of your colleague @imonteroperez . You both were informed. Everybody is happy if I take the commit and simplify his time, so pls appreciate 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 opened a new pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 opened a new pull request #440: URL: https://github.com/apache/maven-surefire/pull/440 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] olamy closed pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
olamy closed pull request #440: URL: https://github.com/apache/maven-surefire/pull/440 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] olamy commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
olamy commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1059591752 > @olamy I don't have time to fight with someone about words. I told the guys that it should be shifted to the right module but you won't understand it and you are basically a speaker of your colleague @imonteroperez . You both were informed. Everybody is happy if I take the commit and simplify his time, so pls appreciate 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MBUILDCACHE-16) config file name
[
https://issues.apache.org/jira/browse/MBUILDCACHE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MBUILDCACHE-16:
-
Description:
reported to me by someone trying to test:
I've noticed that all the docs state a file named maven-cache-config.xml but
the source suggests it should be called maven-build-cache-config.xml:
https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java
Also maybe worth stating that the XXMM (memory mapped files) hash algorithm
seems to require JDK9+ as it uses ByteBuffer.clear() somewhere - or at least,
when I tried to use it, I saw a stacktrace with that - maybe some other
extension/plugin interacting badly. It only seemed to happen with XXMM.
{noformat}
Exception in thread "main" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
at
org.apache.maven.buildcache.hash.ThreadLocalBuffer.clear(ThreadLocalBuffer.java:74)
at
org.apache.maven.buildcache.hash.ThreadLocalBuffer.get(ThreadLocalBuffer.java:47)
at org.apache.maven.buildcache.hash.XXMM.checksum(XXMM.java:51)
at
org.apache.maven.buildcache.hash.HashFactory.createChecksum(HashFactory.java:77)
at
org.apache.maven.buildcache.checksum.MavenProjectInput.calculateChecksum(MavenProjectInput.java:201)
at
org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInputInternal(DefaultProjectInputCalculator.java:116)
at
org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInput(DefaultProjectInputCalculator.java:88)
at
org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild(CacheControllerImpl.java:167)
at
org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute(BuildCacheMojosExecutionStrateg
{noformat}
was:
reported to me by someone trying to test:
I've noticed that all the docs state a file named maven-cache-config.xml but
the source suggests it should be called maven-build-cache-config.xml:
https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java
Also maybe worth stating that the XXMM (memory mapped files) hash algorithm
seems to require JDK9+ as it uses ByteBuffer.clear() somewhere - or at least,
when I tried to use it, I saw a stacktrace with that - maybe some other
extension/plugin interacting badly. It only seemed to happen with XXMM.
> config file name
>
>
> Key: MBUILDCACHE-16
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-16
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Herve Boutemy
>Priority: Major
>
> reported to me by someone trying to test:
> I've noticed that all the docs state a file named maven-cache-config.xml but
> the source suggests it should be called maven-build-cache-config.xml:
> https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java
> Also maybe worth stating that the XXMM (memory mapped files) hash algorithm
> seems to require JDK9+ as it uses ByteBuffer.clear() somewhere - or at least,
> when I tried to use it, I saw a stacktrace with that - maybe some other
> extension/plugin interacting badly. It only seemed to happen with XXMM.
> {noformat}
> Exception in thread "main" java.lang.NoSuchMethodError:
> java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
> at
> org.apache.maven.buildcache.hash.ThreadLocalBuffer.clear(ThreadLocalBuffer.java:74)
> at
> org.apache.maven.buildcache.hash.ThreadLocalBuffer.get(ThreadLocalBuffer.java:47)
> at org.apache.maven.buildcache.hash.XXMM.checksum(XXMM.java:51)
> at
> org.apache.maven.buildcache.hash.HashFactory.createChecksum(HashFactory.java:77)
> at
> org.apache.maven.buildcache.checksum.MavenProjectInput.calculateChecksum(MavenProjectInput.java:201)
> at
> org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInputInternal(DefaultProjectInputCalculator.java:116)
> at
> org.apache.maven.buildcache.DefaultProjectInputCalculator.calculateInput(DefaultProjectInputCalculator.java:88)
> at
> org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild(CacheControllerImpl.java:167)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute(BuildCacheMojosExecutionStrateg
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MBUILDCACHE-16) config file name
[ https://issues.apache.org/jira/browse/MBUILDCACHE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MBUILDCACHE-16: - Description: reported to me by someone trying to test: I've noticed that all the docs state a file named maven-cache-config.xml but the source suggests it should be called maven-build-cache-config.xml: https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java Also maybe worth stating that the XXMM (memory mapped files) hash algorithm seems to require JDK9+ as it uses ByteBuffer.clear() somewhere - or at least, when I tried to use it, I saw a stacktrace with that - maybe some other extension/plugin interacting badly. It only seemed to happen with XXMM. was: reported to me by someone trying to test: I've noticed that all the docs state a file named maven-cache-config.xml but the source suggests it should be called maven-build-cache-config.xml: https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java > config file name > > > Key: MBUILDCACHE-16 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-16 > Project: Maven Build Cache Extension > Issue Type: Bug >Reporter: Herve Boutemy >Priority: Major > > reported to me by someone trying to test: > I've noticed that all the docs state a file named maven-cache-config.xml but > the source suggests it should be called maven-build-cache-config.xml: > https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java > Also maybe worth stating that the XXMM (memory mapped files) hash algorithm > seems to require JDK9+ as it uses ByteBuffer.clear() somewhere - or at least, > when I tried to use it, I saw a stacktrace with that - maybe some other > extension/plugin interacting badly. It only seemed to happen with XXMM. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MBUILDCACHE-16) config file name
Herve Boutemy created MBUILDCACHE-16: Summary: config file name Key: MBUILDCACHE-16 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-16 Project: Maven Build Cache Extension Issue Type: Bug Reporter: Herve Boutemy reported to me by someone trying to test: I've noticed that all the docs state a file named maven-cache-config.xml but the source suggests it should be called maven-build-cache-config.xml: https://github.com/apache/maven-build-cache-extension/blob/c92e48ef924e0f67a0e1299[…]/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501534#comment-17501534
]
Robert James Oxspring commented on SUREFIRE-2033:
-
And yet the result is that in this configuration it fails to run the test at
all - not via JUnit4 or JUnit 5. This behaviour in M5 is entirely regressive.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-dependency-analyzer] chonton commented on pull request #53: MSHARED-1037: CONSTANT_METHOD_TYPE should not add to classes
chonton commented on pull request #53: URL: https://github.com/apache/maven-dependency-analyzer/pull/53#issuecomment-1059503320 unit tests added -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] chonton commented on pull request #54: MSHARED-1038: Inner classes are in same compilation unit as container class
chonton commented on pull request #54: URL: https://github.com/apache/maven-dependency-analyzer/pull/54#issuecomment-1059502899 unit tests added. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] chonton commented on a change in pull request #55: MSHARED-1039: Fix array parsing
chonton commented on a change in pull request #55:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/55#discussion_r819896171
##
File path:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/ResultCollector.java
##
@@ -57,15 +57,24 @@ public void addName( String name )
}
// decode arrays
-if ( name.startsWith( "[L" ) && name.endsWith( ";" ) )
+if ( name.charAt( 0 ) == '[' )
{
-name = name.substring( 2, name.length() - 1 );
+int i = 0;
+do
+{
+++i;
+}
+while ( name.charAt( i ) == '[' ); // could have array of array ...
Review comment:
@slawekjaranowski - any thoughts?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] chonton commented on a change in pull request #55: MSHARED-1039: Fix array parsing
chonton commented on a change in pull request #55:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/55#discussion_r819895664
##
File path:
src/test/java/org/apache/maven/shared/dependency/analyzer/asm/ResultCollectorTest.java
##
@@ -0,0 +1,61 @@
+package org.apache.maven.shared.dependency.analyzer.asm;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Set;
+
+import junit.framework.TestCase;
+import org.apache.maven.shared.dependency.analyzer.testcases.ArrayCases;
+import static org.assertj.core.api.Assertions.assertThat;
+import org.junit.Test;
+
+public class ResultCollectorTest
+extends TestCase
Review comment:
done
##
File path:
src/test/java/org/apache/maven/shared/dependency/analyzer/asm/ResultCollectorTest.java
##
@@ -0,0 +1,61 @@
+package org.apache.maven.shared.dependency.analyzer.asm;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Set;
+
+import junit.framework.TestCase;
+import org.apache.maven.shared.dependency.analyzer.testcases.ArrayCases;
+import static org.assertj.core.api.Assertions.assertThat;
+import org.junit.Test;
+
+public class ResultCollectorTest
+extends TestCase
+{
+Set getDependencies( Class inspectClass )
+throws IOException
+{
+String className = inspectClass.getName();
+String path = '/' + className.replace( '.', '/' ) + ".class";
+DependencyClassFileVisitor visitor = new DependencyClassFileVisitor();
+try ( InputStream is = inspectClass.getResourceAsStream( path ) )
+{
+visitor.visitClass( className, is );
+}
+return visitor.getDependencies();
+}
+
+@Test
+public void testArrayCases()
+throws IOException
+{
+Set dependencies = getDependencies( ArrayCases.class );
+assertThat( dependencies ).doesNotContain( "[I" );
+for ( String dependency : dependencies )
+{
+assertThat( dependency ).doesNotStartWith( "[" );
+}
Review comment:
done
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (WAGON-614) Deprecate Wagon FTP Provider
[ https://issues.apache.org/jira/browse/WAGON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501509#comment-17501509 ] Michael Osipov commented on WAGON-614: -- Correct, I do not even know whether it works properly. Moreover, I still haven't found a compelling reason to use FTP instead of SSH. Maybe you have one. > Deprecate Wagon FTP Provider > > > Key: WAGON-614 > URL: https://issues.apache.org/jira/browse/WAGON-614 > Project: Maven Wagon > Issue Type: Task > Components: wagon-ftp >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > This provider is untested by us for years now (even if commons-net underlying > implementation continues to be maintained > https://commons.apache.org/proper/commons-net/ ), because FTP has almost > everywhere superseded by SSH or HTTP. > We are deprecating this provider to be removed in 4.0.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (WAGON-614) Deprecate Wagon FTP Provider
[ https://issues.apache.org/jira/browse/WAGON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501497#comment-17501497 ] Kenneth Wayman commented on WAGON-614: -- Thanks for the response. Sorry you're stuck maintaining multiple Maven components by yourself, but we appreciate your work! We'll look into WebDAV and SFTP. We like to keep current, and it sounds like Wagon FTP hasn't been "current" in awhile. > Deprecate Wagon FTP Provider > > > Key: WAGON-614 > URL: https://issues.apache.org/jira/browse/WAGON-614 > Project: Maven Wagon > Issue Type: Task > Components: wagon-ftp >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > This provider is untested by us for years now (even if commons-net underlying > implementation continues to be maintained > https://commons.apache.org/proper/commons-net/ ), because FTP has almost > everywhere superseded by SSH or HTTP. > We are deprecating this provider to be removed in 4.0.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-invoker] slawekjaranowski opened a new pull request #47: [MSHARED-1042] Upgrade Parent to 35
slawekjaranowski opened a new pull request #47: URL: https://github.com/apache/maven-invoker/pull/47 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/projects/MSHARED) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-1042) Upgrade Parent to 35
[ https://issues.apache.org/jira/browse/MSHARED-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1042: - Summary: Upgrade Parent to 35 (was: Upgrade Maven Parent to 35) > Upgrade Parent to 35 > > > Key: MSHARED-1042 > URL: https://issues.apache.org/jira/browse/MSHARED-1042 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-invoker >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-invoker] dependabot[bot] commented on pull request #46: Bump maven-shared-components from 34 to 35
dependabot[bot] commented on pull request #46: URL: https://github.com/apache/maven-invoker/pull/46#issuecomment-1059350031 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker] slawekjaranowski closed pull request #46: Bump maven-shared-components from 34 to 35
slawekjaranowski closed pull request #46: URL: https://github.com/apache/maven-invoker/pull/46 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1042) Upgrade Maven Parent to 35
Slawomir Jaranowski created MSHARED-1042: Summary: Upgrade Maven Parent to 35 Key: MSHARED-1042 URL: https://issues.apache.org/jira/browse/MSHARED-1042 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-invoker Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MSHARED-1041) Refactor: remove duplicate code, use addArg internally
[
https://issues.apache.org/jira/browse/MSHARED-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MSHARED-1041:
Assignee: Slawomir Jaranowski
> Refactor: remove duplicate code, use addArg internally
> --
>
> Key: MSHARED-1041
> URL: https://issues.apache.org/jira/browse/MSHARED-1041
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-invoker
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> We can replace methods like:
> {code:java}
> public InvocationRequest setDebug( boolean debug )
> {
> this.debug = debug;
> return this;
> }
> {code}
> by
> {code:java}
> public InvocationRequest setDebug( boolean debug )
> {
> if ( debug )
> {
> addArg( "-X" );
> }
> return this;
> }
> {code}
> and simplify {{MavenCommandLineBuilder}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
Re: Maven Dependency Plugin - Log4j vulnerabilities
> https://github.com/jveverka/mvn-dependency-log4j/commit/ac87977c19bb2ee2564d15fa87f255d621a4706d https://github.com/pzygielo/mvn-dependency-log4j/runs/5425284512?check_suite_focus=true#step:5:1 No log4j:1.2.12:jar is downloaded in that reproducer. log4j/log4j is excluded by commons-logging from its dependencies. -- Piotrek
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501431#comment-17501431
]
Chris Warburton commented on MNG-6965:
--
This issue seems to have broken `mvn dependency:go-offline`, which seems like a
more common use-case than having the plexus-utils:1.1 package banned.
I hit this since we use Nix to sandbox all of our builds; in particular, they
can't access the root filesystem (including e.g. ~/.m2) or the network. Since
this plexus-utils:1.1 dependency doesn't appear in any explicit dependency
listing, it doesn't get included in these sandboxes; and the resulting build
fails.
I can also confirm that forcing a particular version of plexus-utils, like
[~manolan] shows above, works around the problem for now.
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.9.0-candidate
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {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/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (WAGON-614) Deprecate Wagon FTP Provider
[ https://issues.apache.org/jira/browse/WAGON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501423#comment-17501423 ] Michael Osipov edited comment on WAGON-614 at 3/4/22, 4:25 PM: --- Several: * Migrate to HTTP with WebDAV or SSH * Don't do anything because Wagon 4 GA won't land before next year and it only be part of Maven 4 not before it is done So you still have plenty of time to continue to use and consider an alternative approach. For your consideration also: I am maintaining many Maven components all alone, so I am slow in doing things which is your benefit. was (Author: michael-o): Several: * Migrate to HTTP with WebDAV or SSH * Don't do anything because Wagon 4 won't land before next year and it only be part of Maven 4 not before it is done So you still have plenty of time to continue to use and consider an alternative approach. > Deprecate Wagon FTP Provider > > > Key: WAGON-614 > URL: https://issues.apache.org/jira/browse/WAGON-614 > Project: Maven Wagon > Issue Type: Task > Components: wagon-ftp >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > This provider is untested by us for years now (even if commons-net underlying > implementation continues to be maintained > https://commons.apache.org/proper/commons-net/ ), because FTP has almost > everywhere superseded by SSH or HTTP. > We are deprecating this provider to be removed in 4.0.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (WAGON-614) Deprecate Wagon FTP Provider
[ https://issues.apache.org/jira/browse/WAGON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501423#comment-17501423 ] Michael Osipov commented on WAGON-614: -- Several: * Migrate to HTTP with WebDAV or SSH * Don't do anything because Wagon 4 won't land before next year and it only be part of Maven 4 not before it is done So you still have plenty of time to continue to use and consider an alternative approach. > Deprecate Wagon FTP Provider > > > Key: WAGON-614 > URL: https://issues.apache.org/jira/browse/WAGON-614 > Project: Maven Wagon > Issue Type: Task > Components: wagon-ftp >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > This provider is untested by us for years now (even if commons-net underlying > implementation continues to be maintained > https://commons.apache.org/proper/commons-net/ ), because FTP has almost > everywhere superseded by SSH or HTTP. > We are deprecating this provider to be removed in 4.0.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] MartinKanters opened a new pull request #688: NOJIRA: Made the intention of the reactor code more clear.
MartinKanters opened a new pull request #688: URL: https://github.com/apache/maven/pull/688 This PR used to be part of MNG-7390, but now just contains the refactoring part. Made the intention of the reactor code more clear and changed the order of steps to minimize sorting calls. Changes: - The main "reactor" method (`DefaultGraphBuilder#reactorDependencyGraph`) is more descriptive.. that one method should describe exactly every business logic rule, instead of having hidden business rules inside methods. In total I think it's easier to understand to full flow now. - It used to sort the intermediate project list too many times - It used to calculate and add the also-make/also-make-dependent projects into the intermediate project list too many times. - The methods used for getting and trimming the intermediate project list were made consistent. They now additionally: - fail fast when it's not applicable (i.e. skip over `getResumedProjects` when `-rf` is not given), - return Sets, as the project lists do not need to be sorted in between and unique elements are automatically guaranteed, - are converted a bit more to Streams for the sake of readability. Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501398#comment-17501398
]
Herve Boutemy commented on MRESOLVER-246:
-
and, yes, in MPOM-205 we did an exception publishing sha512 for Apache source
release, but it was just because of users confusion between Apache distribution
area requirements and Maven Central
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501397#comment-17501397
]
Herve Boutemy commented on MRESOLVER-246:
-
but adding so many fingerprints just add noise, no security, so it's a bad idea
to try to do that
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501396#comment-17501396
]
Herve Boutemy commented on MRESOLVER-246:
-
MRESOLVER-56 is the way to do it, but requires newer Maven versions
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 edited a comment on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1059269071 @olamy I don't have time to fight with someone about words. I told the guys that it should be shifted to the right module but you won't understand it and you are basically a speaker of your colleague @imonteroperez . You both were informed. Everybody is happy if I take the commit and simplify his time, so pls appreciate 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1059269071 @olamy I don't have time to fight with someone about words. I told the guys that it should be shifted to the right module but you won't understand it and you are basically a speaker of your colleague @imonteroperez . You both were informed. Everybody is happy if I take the comit and simplify his time, so pls appreciate 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Moved] (MRESOLVER-246) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MRESOLVER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved MDEPLOY-290 to MRESOLVER-246:
-
Component/s: (was: deploy:deploy)
Key: MRESOLVER-246 (was: MDEPLOY-290)
Affects Version/s: (was: 2.8.2)
(was: 3.0.0-M2)
Project: Maven Resolver (was: Maven Deploy Plugin)
> m-deploy-p will create hashes for hashes
>
>
> Key: MRESOLVER-246
> URL: https://issues.apache.org/jira/browse/MRESOLVER-246
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] Gakiii commented on pull request #687: actually the “return” can be writed in the last
Gakiii commented on pull request #687: URL: https://github.com/apache/maven/pull/687#issuecomment-1059248092 i think the “return” can be written in the last line -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] Gakiii opened a new pull request #687: actually the “return” can be writed in the last
Gakiii opened a new pull request #687: URL: https://github.com/apache/maven/pull/687 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (WAGON-614) Deprecate Wagon FTP Provider
[ https://issues.apache.org/jira/browse/WAGON-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501347#comment-17501347 ] Kenneth Wayman commented on WAGON-614: -- [~michael-o] We have been using the Wagon-FTP provider since we've been using Maven for sharing development artifacts internally. What is the recommended alternative setup? > Deprecate Wagon FTP Provider > > > Key: WAGON-614 > URL: https://issues.apache.org/jira/browse/WAGON-614 > Project: Maven Wagon > Issue Type: Task > Components: wagon-ftp >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > This provider is untested by us for years now (even if commons-net underlying > implementation continues to be maintained > https://commons.apache.org/proper/commons-net/ ), because FTP has almost > everywhere superseded by SSH or HTTP. > We are deprecating this provider to be removed in 4.0.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MDEPLOY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501331#comment-17501331
]
Benjamin Marwell commented on MDEPLOY-290:
--
>From the slack I learned this should be moved to the resolver plugin.
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[ https://issues.apache.org/jira/browse/MDEPLOY-290 ]
Benjamin Marwell deleted comment on MDEPLOY-290:
--
was (Author: mampf86):
Shiro set-up
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEPLOY-290) m-deploy-p will create hashes for hashes
[
https://issues.apache.org/jira/browse/MDEPLOY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501295#comment-17501295
]
Benjamin Marwell commented on MDEPLOY-290:
--
Shiro set-up
> m-deploy-p will create hashes for hashes
>
>
> Key: MDEPLOY-290
> URL: https://issues.apache.org/jira/browse/MDEPLOY-290
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2, 3.0.0-M2
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> recent ASF parent pom will create hashes for source-release-zip files using
> the checksum-maven-plugin.
> However, the SHIRO project decided to hash ALL artifacts:
> {code:xml}
>
> org.apache.maven.plugins
> maven-gpg-plugin
>
>
>
> **/*.md5
> **/*.sha1
> **/*.sha256
> **/*.sha512
> **/*.asc
>
> **/*.sha3512
>
>
>
>
> net.nicoulaj.maven.plugins
> checksum-maven-plugin
> 1.11
>
>
> source-release-checksum
> none
>
>
> main-artifact-checksum
> verify
>
> artifacts
>
>
>
>
>
> SHA-256
> SHA-512
> SHA3-512
>
> false
>
> true
>
>
> {code}
> Now as you can see, gpg plugin had to be extended, but we also create
> *.sha3512 files. Those and all other hashes are being hashed by the deploy
> plugin, though:
> {code}
> $ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
> ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
> {code}
> Notice the *.sha512.md1 and *.sha512.sha1 files.
> Currently there is no exclusion possible.
> Therefore:
> * Let's add an exclusion parameter for hashing, similar to gpg's one.
> * set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MDEPLOY-290) m-deploy-p will create hashes for hashes
Benjamin Marwell created MDEPLOY-290:
Summary: m-deploy-p will create hashes for hashes
Key: MDEPLOY-290
URL: https://issues.apache.org/jira/browse/MDEPLOY-290
Project: Maven Deploy Plugin
Issue Type: Bug
Components: deploy:deploy
Affects Versions: 3.0.0-M2, 2.8.2
Reporter: Benjamin Marwell
Hi everyone,
recent ASF parent pom will create hashes for source-release-zip files using the
checksum-maven-plugin.
However, the SHIRO project decided to hash ALL artifacts:
{code:xml}
org.apache.maven.plugins
maven-gpg-plugin
**/*.md5
**/*.sha1
**/*.sha256
**/*.sha512
**/*.asc
**/*.sha3512
net.nicoulaj.maven.plugins
checksum-maven-plugin
1.11
source-release-checksum
none
main-artifact-checksum
verify
artifacts
SHA-256
SHA-512
SHA3-512
false
true
{code}
Now as you can see, gpg plugin had to be extended, but we also create *.sha3512
files. Those and all other hashes are being hashed by the deploy plugin, though:
{code}
$ ls -1F ./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/*sources*
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.asc
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha256.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha3512.sha1
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.md5
./org/apache/shiro/shiro-lang/1.9.0-SNAPSHOT/shiro-lang-1.9.0-20220303.204242-1-sources.jar.sha512.sha1
{code}
Notice the *.sha512.md1 and *.sha512.sha1 files.
Currently there is no exclusion possible.
Therefore:
* Let's add an exclusion parameter for hashing, similar to gpg's one.
* set a sane default (to be discussed).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-shared-utils] pzygielo opened a new pull request #95: (doc) Throw more descriptive NPEx
pzygielo opened a new pull request #95: URL: https://github.com/apache/maven-shared-utils/pull/95 As suggested in [MJAR-286](https://issues.apache.org/jira/browse/MJAR-286): > If this is a misconfigured pom, it should at least give a proper error message. Thus replacing JVM-thrown NPEx with the one with message. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #480: Test only with 2 last Maven core 3.6.x and 3.8.x, avoid deep scanning to find jacoco files
Tibor17 commented on a change in pull request #480:
URL: https://github.com/apache/maven-surefire/pull/480#discussion_r819424925
##
File path: Jenkinsfile
##
@@ -174,7 +174,7 @@ def buildProcess(String stageKey, String jdkName, String
mvnName, goals, options
try {
if (makeReports) {
jacoco(changeBuildStatus: false,
-execPattern: '**/*.exec',
+execPattern: '**/target/jacoco*.exec',
Review comment:
@olamy
Performance? Open the online logs as me and you will see that the
performance is the last problem.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MJAR-286) NullPointerException when includes are empty
[ https://issues.apache.org/jira/browse/MJAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Dangl updated MJAR-286: -- Attachment: mvn-clean-package.log > NullPointerException when includes are empty > > > Key: MJAR-286 > URL: https://issues.apache.org/jira/browse/MJAR-286 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.1.2, 3.2.2 > Environment: Maven 3.8.4, Windows 10 >Reporter: Markus Dangl >Priority: Major > Attachments: mvn-clean-package.log > > > When includes are empty, but a `src/main/resources` directory exists, maven > fails with a NullPointerException. If this is a misconfigured pom, it should > at least give a proper error message. > > I produced a minimized case here: > [https://github.com/xicesky/bug-in-maven-jar-plugin] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MJAR-286) NullPointerException when includes are empty
[ https://issues.apache.org/jira/browse/MJAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501226#comment-17501226 ] Markus Dangl commented on MJAR-286: --- Version 3.1.1 of the maven-jar-plugin builds the same project without errors. > NullPointerException when includes are empty > > > Key: MJAR-286 > URL: https://issues.apache.org/jira/browse/MJAR-286 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.1.2, 3.2.2 > Environment: Maven 3.8.4, Windows 10 >Reporter: Markus Dangl >Priority: Major > > When includes are empty, but a `src/main/resources` directory exists, maven > fails with a NullPointerException. If this is a misconfigured pom, it should > at least give a proper error message. > > I produced a minimized case here: > [https://github.com/xicesky/bug-in-maven-jar-plugin] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MJAR-286) NullPointerException when includes are empty
Markus Dangl created MJAR-286: - Summary: NullPointerException when includes are empty Key: MJAR-286 URL: https://issues.apache.org/jira/browse/MJAR-286 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.2.2, 3.1.2 Environment: Maven 3.8.4, Windows 10 Reporter: Markus Dangl When includes are empty, but a `src/main/resources` directory exists, maven fails with a NullPointerException. If this is a misconfigured pom, it should at least give a proper error message. I produced a minimized case here: [https://github.com/xicesky/bug-in-maven-jar-plugin] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-release] K-J-Henken commented on a change in pull request #62: [MRELEASE-899] Feature/lineseparator
K-J-Henken commented on a change in pull request #62: URL: https://github.com/apache/maven-release/pull/62#discussion_r819348535 ## File path: maven-release-api/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptor.java ## @@ -567,6 +567,15 @@ */ String getAutoResolveSnapshots(); +/** + * Get the line separator to use in the pom.xml. + * + * (https://issues.apache.org/jira/browse/MRELEASE-899). Review comment: Fixed with https://github.com/apache/maven-release/pull/62/commits/349fe933a951cf1a879ac16d965c845784466397 ## File path: maven-release-manager/src/main/mdo/release-descriptor.mdo ## @@ -604,6 +604,16 @@ + + lineSeparator + 3.0.0+ + String + +Specifies the line separator to use in the pom.xml. +(https://issues.apache.org/jira/browse/MRELEASE-899) Review comment: Fixed with https://github.com/apache/maven-release/pull/62/commits/349fe933a951cf1a879ac16d965c845784466397 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
