[GitHub] [maven] basil commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
basil commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1073174598 I do not really know or care what a workspace reader is. I just want my builds to work again. -- 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] laeubi commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1073173726 > This fixes the problem for me but will instantly fail once another workspace reader is registered again ;-) -- 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] (MNG-7433) Multiple maven instances working on same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated MNG-7433: -- Summary: Multiple maven instances working on same source tree can lock each other (was: multiple maven instances working same source tree can lock each other) > Multiple maven instances working on same source tree can lock each other > > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) multiple maven instances working same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508424#comment-17508424 ] Dan Tran edited comment on MNG-7433 at 3/20/22, 3:35 AM: - I also tried: * switch apache maven-invoker to run sonar:sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * invoke a different goal ( compile instead of sonar:sonar) * latest 3.9.0 from source Possible that the lock is on stdout/stderr stream? A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock was (Author: dantran): I also tried: * switch apache maven-invoker to run sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * latest 3.9.0 from source A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock > multiple maven instances working same source tree can lock each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) multiple maven instances working same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508424#comment-17508424 ] Dan Tran edited comment on MNG-7433 at 3/20/22, 2:27 AM: - I also tried: * switch apache maven-invoker to run sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * latest 3.9.0 from source A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock was (Author: dantran): I also tried: * switch apache maven-invoker to invoke sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * latest 3.9.0 from source A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock > multiple maven instances working same source tree can lock each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MNG-7433) multiple maven instances working same source tree can lock each other
[ https://issues.apache.org/jira/browse/MNG-7433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508424#comment-17508424 ] Dan Tran edited comment on MNG-7433 at 3/20/22, 2:26 AM: - I also tried: * switch apache maven-invoker to invoke sonar ( instead of internal custom invoker) * replicate a copy of local repo so that maven-invoker has its own maven local repo * latest 3.9.0 from source A workaround is to disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock was (Author: dantran): I also tried: * replicate local repo to run with sonar:sonar maven instance * latest 3.9.0 from source The same locking found disable this line https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L226 will remove the lock > multiple maven instances working same source tree can lock each other > - > > Key: MNG-7433 > URL: https://issues.apache.org/jira/browse/MNG-7433 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Dan Tran >Priority: Major > > I have a large multi modules java maven build where: > * phase 1 - basic build + unit tests + jacoco - 40 min > * phase 2 - sonar:sonar 20 min > * phase 3 - final packaging and basic smoke-test - 20 min > To take advantage of Maven multi-threaded build, during the reactor build, > one of our maven module spins another instance of Maven to run sonar:sonar > goal right after the basic build is done. > This means our phase 2 and phase 3 run in parallel sharing the same source > tree, same local maven repo (where sonar:sonar should have all needed > dependencies at the share local maven repo to run its task) > With maven-3.8.5, parallelization is no longer possible, phase 3 is blocked > until phase 2 is done. > I am able to trace it to https://github.com/apache/maven/pull/628 where the > locking started the happen > How does the lock mechanic work? there must be a local file where both Maven > instances are watching each other. Is there an option to disable this lock? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MCHECKSTYLE-410) Require Maven 3.2.5+
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MCHECKSTYLE-410: Assignee: (was: Sylwester Lachiewicz) > Require Maven 3.2.5+ > > > Key: MCHECKSTYLE-410 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-410 > Project: Maven Checkstyle Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MSHARED-1003) Require Maven 3.2.5+
[ https://issues.apache.org/jira/browse/MSHARED-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-1003: - Assignee: (was: Sylwester Lachiewicz) > Require Maven 3.2.5+ > > > Key: MSHARED-1003 > URL: https://issues.apache.org/jira/browse/MSHARED-1003 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-filtering, maven-shared-incremental >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: maven-shared-incremental-2.0.0, maven-filtering-3.3.0 > > > Grouping all shared components -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MJARSIGNER-48) Make Jar Signer plugin :sign goal threadsafe
[
https://issues.apache.org/jira/browse/MJARSIGNER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MJARSIGNER-48:
--
Assignee: (was: Sylwester Lachiewicz)
> Make Jar Signer plugin :sign goal threadsafe
>
>
> Key: MJARSIGNER-48
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-48
> Project: Maven Jar Signer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Kaloyan Raev
>Priority: Major
> Labels: build
> Fix For: 3.0.1
>
>
> Right now when you execute mvn *-T 4* maven-jarsigner-plugin:1.4:sign you get
> a warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in uDecideSM:
> [WARNING] org.apache.maven.plugins:maven-jarsigner-plugin:1.4
> [WARNING] *
> {code}
--
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=17509354#comment-17509354
]
Robert James Oxspring commented on SUREFIRE-2033:
-
The documentation is also very clear about the precedence algorithm used to
choose the engine/runner to use:
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html]
If nothing is configured, Surefire detects which JUnit version to use by the
following algorithm:
# if the JUnit 5 Platform Engine is present in the project
# use junit-platform
# if the JUnit version in the project >= 4.7 and the <<>>
configuration parameter has ANY value
# use junit47 provider
# if JUnit >= 4.0 is present
# use junit4 provider
# else
# use junit3.8.1
Prior to M5, surefire worked as documented and actively preferred to use JUnit
5 if the engine is present. Since M5, switches away from this documented
behaviour and conditionally prefers to run the older junit-platform-runner, if
present, effectively preferring JUnit 4.
As discussed previously, we have a business requirement for our product to use
junit-platform-runner, but tests of our product are using JUnit 5 and have been
run via the junit-Jupiter-engine for as long as I can remember. You may find
this a silly requirement, and I’d love to change it, but that is what the
business requires.
Your main concern seems to be that use of junit-platform-runner is unusual and
not a recommended configuration. Given this, doesn’t it seem odd that M5
changes behaviour to actively prefer this unusual unrecommended runner over the
Junit Jupiter Engine that is also present?
> 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 |
[jira] [Assigned] (MDEP-765) Some goals result in download of Struts 1.3.8 POMs
[
https://issues.apache.org/jira/browse/MDEP-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MDEP-765:
-
Assignee: (was: Sylwester Lachiewicz)
> Some goals result in download of Struts 1.3.8 POMs
> --
>
> Key: MDEP-765
> URL: https://issues.apache.org/jira/browse/MDEP-765
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies, unpack-dependencies
>Affects Versions: 3.2.0
>Reporter: Andrew Swan
>Priority: Minor
> Labels: security, struts
>
> h1. Problem
> Executing certain goals of the {{dependency}} plugin (for example
> {{copy-dependencies}} and {{unpack-dependencies}}) causes various Struts
> 1.3.8 POMs to be downloaded to the user's local Maven repository. This
> version of Struts has known security vulnerabilities.
> h1. Reproduction
> Here's a minimal POM that demonstrates the problem:
> {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
> org.example
> dependency-plugin-demo
> 1.0-SNAPSHOT
>
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.2.0
>
>
>
>
> {code}
> Running {{mvn dependency:copy-dependencies}} results in the following output:
> {code:java}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:dependency-plugin-demo
> >-
> [INFO] Building dependency-plugin-demo 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-dependency-plugin:3.2.0:copy-dependencies (default-cli) @
> dependency-plugin-demo ---
> Downloading from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-core/1.3.8/struts-core-1.3.8.pom
> Downloaded from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-core/1.3.8/struts-core-1.3.8.pom
> (4.3 kB at 2.8 kB/s)
> Downloading from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-parent/1.3.8/struts-parent-1.3.8.pom
> Downloaded from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-parent/1.3.8/struts-parent-1.3.8.pom
> (9.8 kB at 21 kB/s)
> Downloading from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-master/4/struts-master-4.pom
> Downloaded from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-master/4/struts-master-4.pom
> (11 kB at 25 kB/s)
> Downloading from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-taglib/1.3.8/struts-taglib-1.3.8.pom
> Downloaded from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-taglib/1.3.8/struts-taglib-1.3.8.pom
> (3.1 kB at 6.4 kB/s)
> Downloading from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-tiles/1.3.8/struts-tiles-1.3.8.pom
> Downloaded from maven-atlassian-com:
> https://packages.atlassian.com/maven/repository/internal/org/apache/struts/struts-tiles/1.3.8/struts-tiles-1.3.8.pom
> (2.9 kB at 5.2 kB/s)
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 4.297 s
> [INFO] Finished at: 2021-09-09T14:18:10+10:00
> [INFO]
> {code}
> h1. Workaround
> One workaround is to downgrade to version 2.8 of the plugin, however this may
> also require the user to modify their plugin configuration, because the
> semantics of configuration options like {{includeScope}} have changed even
> between minor versions 3.1.2 and 3.2.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MCHANGELOG-151) Migrate plugin to Maven 3.2.5
[ https://issues.apache.org/jira/browse/MCHANGELOG-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MCHANGELOG-151: Summary: Migrate plugin to Maven 3.2.5 (was: Migrate plugin to Maven 3.0.5) > Migrate plugin to Maven 3.2.5 > - > > Key: MCHANGELOG-151 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-151 > Project: Maven Changelog Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Major > > * Replacing usage of deprecated APIs > * Renaming the packages to org.apache.maven.plugins > * Removing Maven 2 specific code > * Fixing Javadoc comments > * Removing the use of raw types where possible -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MCOMPILER-415) NullPointerException from javac when compiling AntlrWorks-Jank
[
https://issues.apache.org/jira/browse/MCOMPILER-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509353#comment-17509353
]
Basil Crow commented on MCOMPILER-415:
--
The fix for the underlying OpenJDK issue has been backported to {{jdk11u-dev}}
in [openjdk/jdk11u-dev#919|https://github.com/openjdk/jdk11u-dev/pull/919]
toward OpenJDK 11.0.16, currently scheduled for a July 2022 GA.
> NullPointerException from javac when compiling AntlrWorks-Jank
> --
>
> Key: MCOMPILER-415
> URL: https://issues.apache.org/jira/browse/MCOMPILER-415
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: macOS 10.14.6, iMac Pro, AdoptOpenJDK 9, OpenJDK 11.0.2,
> AdoptOpenJDK 13.0.2
>Reporter: Andrew Janke
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: antlrworks-jank-mvn-compile-NPE-02-debug.log,
> antlrworks-jank-mvn-compile-NPE-02.log,
> antlrworks-jank-mvn-compile-NPE-debug.log, antlrworks-jank-mvn-compile-NPE.log
>
>
> I'm working on a project called AntlrWorks-Jank, an attempt to revive the
> defunct ANTLRWorks application. https://github.com/apjanke/antlrworks2-jank
> When compiling the latest work-in-progress version of my code, I'm getting a
> NullPointerException apparently raised inside the javac code when it's called
> by the Maven Compiler Plugin.
> {code:java}
> [antlrworks-jank] $ mvn -e compile
> [INFO] Error stacktraces are turned on.
> [...]
> [INFO] works-editor-antlr4 FAILURE [ 1.026
> s]
> [INFO] antlr-works-editor . SKIPPED
> [INFO] tvl-editor-whitespace .. SKIPPED
> [INFO] works-editor-antlr3 SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.028 s
> [INFO] Finished at: 2020-05-08T03:01:54-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project works-editor-antlr4: Fatal error compiling: CompilerException:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project works-editor-antlr4: Fatal error compiling
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> [...]
> Caused by: java.lang.NullPointerException
> at com.sun.tools.javac.main.JavaCompiler.readSourceFile
> (JavaCompiler.java:825)
> at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete
> (JavacProcessingEnvironment.java:1510)
> at com.sun.tools.javac.code.Symbol.complete (Symbol.java:633)
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete (Symbol.java:1314)
> at com.sun.tools.javac.code.Type$ClassType.complete (Type.java:1139)
> at com.sun.tools.javac.code.Type$ClassType.getTypeArguments
> (Type.java:1065)
> at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:237)
> at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:52)
> at com.sun.tools.javac.code.Type$ClassType.accept (Type.java:992)
> at com.sun.tools.javac.code.Printer.visit (Printer.java:136)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument
> (AbstractDiagnosticFormatter.java:197)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments
> (AbstractDiagnosticFormatter.java:165)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:111)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:67)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument
> (AbstractDiagnosticFormatter.java:183)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments
> (AbstractDiagnosticFormatter.java:165)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:111)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:67)
> at com.sun.tools.javac.util.JCDiagnostic.getMessage
> (JCDiagnostic.java:771)
> at
> com.sun.tools.javac.api.ClientCodeWrapper$DiagnosticSourceUnwrapper.getMessage
> (ClientCodeWrapper.java:799)
> at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess
> (JavaxToolsCompiler.java:149)
> at
[jira] [Commented] (MCOMPILER-346) workaround to jdk bug: 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=17509352#comment-17509352
]
Basil Crow commented on MCOMPILER-346:
--
The fix for the underlying OpenJDK issue has been backported to {{jdk11u-dev}}
in [openjdk/jdk11u-dev#919|https://github.com/openjdk/jdk11u-dev/pull/919]
toward OpenJDK 11.0.16, currently scheduled for a July 2022 GA.
> workaround to jdk bug: 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
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.10.1
>
> 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
>
[GitHub] [maven] basil commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
basil commented on pull request #695:
URL: https://github.com/apache/maven/pull/695#issuecomment-1073123778
A more minimal (and therefore likely less controversial) alternative to the
fix proposed in this PR is:
```java
diff --git a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
index 56a42b724..965345394 100644
--- a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
+++ b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
@@ -377,8 +377,15 @@ private void setupWorkspaceReader( MavenSession
session, DefaultRepositorySystem
}
workspaceReaders.add( workspaceReader );
}
-WorkspaceReader[] readers = workspaceReaders.toArray( new
WorkspaceReader[0] );
-repoSession.setWorkspaceReader( new ChainedWorkspaceReader( readers
) );
+if ( workspaceReaders.size() == 1 )
+{
+repoSession.setWorkspaceReader( workspaceReaders.get( 0 ) );
+}
+else
+{
+WorkspaceReader[] readers = workspaceReaders.toArray( new
WorkspaceReader[0] );
+repoSession.setWorkspaceReader( new ChainedWorkspaceReader(
readers ) );
+}
}
```
This fixes the problem for me by restoring the old behavior from Maven 3.8.4.
--
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] (MNG-7432) REGRESSION in 3.8.5: Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509351#comment-17509351
]
Basil Crow commented on MNG-7432:
-
A more minimal (and therefore likely less controversial) alternative to the fix
proposed in [apache/maven#695|https://github.com/apache/maven/pull/695] is:
{noformat}
diff --git a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
index 56a42b724..965345394 100644
--- a/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
+++ b/maven-core/src/main/java/org/apache/maven/DefaultMaven.java
@@ -377,8 +377,15 @@ private void setupWorkspaceReader( MavenSession session,
DefaultRepositorySystem
}
workspaceReaders.add( workspaceReader );
}
-WorkspaceReader[] readers = workspaceReaders.toArray( new
WorkspaceReader[0] );
-repoSession.setWorkspaceReader( new ChainedWorkspaceReader( readers )
);
+if ( workspaceReaders.size() == 1 )
+{
+repoSession.setWorkspaceReader( workspaceReaders.get( 0 ) );
+}
+else
+{
+WorkspaceReader[] readers = workspaceReaders.toArray( new
WorkspaceReader[0] );
+repoSession.setWorkspaceReader( new ChainedWorkspaceReader(
readers ) );
+}
}
{noformat}
This fixes the problem for me by restoring the old behavior from Maven 3.8.4.
> REGRESSION in 3.8.5: Dependencies from profile not picked up via
> -P
>
>
> Key: MNG-7432
> URL: https://issues.apache.org/jira/browse/MNG-7432
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.5
>Reporter: Falko Modler
>Priority: Critical
>
> The README of the following reproducer says it all:
> https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
> Initially discussed here:
> https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] basil commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
basil commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1073122748 @olamy The regression introduced in Maven 3.8.5 in apache/maven@6f141968464b4ad24e5d90f1389065141cda5e3b, which is resolved in this unmerged and unreleased pull request, is causing [all Jenkins core PR builds](https://ci.jenkins.io/job/Core/job/jenkins/job/PR-6385/) to fail. -- 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] (MNG-7432) REGRESSION in 3.8.5: Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509347#comment-17509347
]
Basil Crow commented on MNG-7432:
-
h3. Steps to reproduce
Clone https://github.com/jenkinsci/jenkins.git and then run {{mvn clean verify
-Dset.changelist}} with Maven 3.8.5.
h3. Expected results
**Note:** These are the _actual_ results with Maven 3.8.4.
The build passes.
h3. Actual results
The build fails with
{noformat}
[DEBUG] Resolving artifact org.jenkins-ci.main:jenkins-bom:pom:2.340-SNAPSHOT
from [incrementals (https://repo.jenkins-ci.org/incrementals/, default,
releases), central (https://repo.maven.apache.org/maven2, default, releases),
repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/, default,
releases+snapshots)]
[DEBUG] Adding ERROR message due to exception
org.apache.maven.enforcer.rule.api.EnforcerRuleException: Could not build
dependency tree Could not collect dependencies: null
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.getNode
(RequireUpperBoundDeps.java:152)
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.execute
(RequireUpperBoundDeps.java:164)
at org.apache.maven.plugins.enforcer.EnforceMojo.execute
(EnforceMojo.java:200)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:301)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:211)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:165)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:157)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:121)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:127)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by:
org.apache.maven.shared.dependency.graph.DependencyCollectorBuilderException:
Could not collect dependencies: null
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:156)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.getNode
(RequireUpperBoundDeps.java:140)
at org.apache.maven.plugins.enforcer.RequireUpperBoundDeps.execute
(RequireUpperBoundDeps.java:164)
at org.apache.maven.plugins.enforcer.EnforceMojo.execute
(EnforceMojo.java:200)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:301)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:211)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:165)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:157)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:121)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:127)
at
[jira] [Created] (MWRAPPER-62) Upgrade Parent to 35
Slawomir Jaranowski created MWRAPPER-62: --- Summary: Upgrade Parent to 35 Key: MWRAPPER-62 URL: https://issues.apache.org/jira/browse/MWRAPPER-62 Project: Maven Wrapper Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-33) Use java 8 in maven-wrapper
[
https://issues.apache.org/jira/browse/MWRAPPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509344#comment-17509344
]
Slawomir Jaranowski commented on MWRAPPER-33:
-
We are starting to freeze old dependencies due to using jdk 7
like: https://github.com/apache/maven-wrapper/pull/24 - plexus-archiver from
4.2.1 to 4.2.7
> Use java 8 in maven-wrapper
> ---
>
> Key: MWRAPPER-33
> URL: https://issues.apache.org/jira/browse/MWRAPPER-33
> Project: Maven Wrapper
> Issue Type: Improvement
> Components: Maven Wrapper Jar
>Affects Versions: 3.1.0
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Currently {{maven-wrapper}} use java {*}5{*}.
> It blocks build project on java > 8.
> {{maven-wrapper-plugin}} require java 8, so we can use {{maven-wrapper}} with
> java 5 but we can't install it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-wrapper] slawekjaranowski closed pull request #26: Bump maven-parent from 34 to 35
slawekjaranowski closed pull request #26: URL: https://github.com/apache/maven-wrapper/pull/26 -- 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-wrapper] dependabot[bot] commented on pull request #26: Bump maven-parent from 34 to 35
dependabot[bot] commented on pull request #26: URL: https://github.com/apache/maven-wrapper/pull/26#issuecomment-1073117475 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
[jira] [Comment Edited] (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=17509342#comment-17509342
]
Tibor Digana edited comment on SUREFIRE-2033 at 3/19/22, 9:33 PM:
--
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to you can directly use {{surefire-junit-platform}} provider instead of JUnit4
executor and you can avoid using {{junit-platform-runner}} in your
dependencies. It is silly to use {{junit-platform-runner}} unless you have a
strong resources/financial reason to not spending the time when rewriting
JUnit4 Suites to JUnit5 Suites. The JUnit5 would not support
{{junit-platform-runner}}.
was (Author: tibor17):
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to not spending the time when rewriting JUnit4 Suites to JUnit5 Suites. The
JUnit5 would not support {{junit-platform-runner}}.
> 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
[jira] [Comment Edited] (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=17509342#comment-17509342
]
Tibor Digana edited comment on SUREFIRE-2033 at 3/19/22, 9:30 PM:
--
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to not spending the time when rewriting JUnit4 Suites to JUnit5 Suites. The
JUnit5 would not support {{junit-platform-runner}}.
was (Author: tibor17):
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to spending the time when rewriting JUnit4 Suites to JUnit5 Suites. The JUnit5
would not support {{junit-platform-runner}}.
> 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:
[jira] [Comment Edited] (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=17509342#comment-17509342
]
Tibor Digana edited comment on SUREFIRE-2033 at 3/19/22, 9:29 PM:
--
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to spending the time when rewriting JUnit4 Suites to JUnit5 Suites. The JUnit5
would not support {{junit-platform-runner}}.
was (Author: tibor17):
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to spending the time when rewriting JUnit4 Suites to JUnit5 Suites.
> 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]
>
[jira] [Updated] (MWRAPPER-61) let mvnw call mvn directly
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MWRAPPER-61: Priority: Major (was: Normal) > let mvnw call mvn directly > -- > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- 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=17509342#comment-17509342
]
Tibor Digana commented on SUREFIRE-2033:
[~sjaranowski]
[~roxspring]
The documentation exists very long time.
https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html
The Surefire is very intelligent because it downloads and uses Vintage and
Jupiter engines even if you do not specify them in the project dependencies.
It's enough to use API, e.g. org.junit.jupiter:junit-jupiter-api or
junit:junit:4.13.2.
Let's go back to the problem with {{junit-platform-runner}}. In reality
{{junit-platform-runner}} is an adapter from JUnit4 to JUnit5. It is not reach
JUnit5 runner. In the Maven perspective it can be used only if you hard code
{{surefire-junit4}} provider under the plugin in its dependencies but your
project contains dependencies for JUnit5 tests.
So the key point of {{junit-platform-runner}} is to have JUnit4 executor
(junit4 surefire provider in our case) and JUnit5 tests. This is very silly due
to use can use {{surefire-junit-platform}} provider instead of JUnit4 executor
and you can avoid using {{junit-platform-runner}}. It is silly to use
{{junit-platform-runner}} unless you have a strong resources/financial reason
to spending the time when rewriting JUnit4 Suites to JUnit5 Suites.
> 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]
>
[jira] [Commented] (MWRAPPER-45) Migrate/Sync startup scripts with Maven 4
[ https://issues.apache.org/jira/browse/MWRAPPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509341#comment-17509341 ] Slawomir Jaranowski commented on MWRAPPER-45: - Maybe better is call mvn script from distribution. There is a proposition for it - MWRAPPER-61 > Migrate/Sync startup scripts with Maven 4 > - > > Key: MWRAPPER-45 > URL: https://issues.apache.org/jira/browse/MWRAPPER-45 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Michael Osipov >Priority: Major > > The scripts are Maven 3 based. Maven 4 has simplified the scripts and > introduced consistency improvements. We should port those over for version 4?! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] dependabot[bot] commented on pull request #31: Bump mavenVersion from 3.1.0 to 3.8.5
dependabot[bot] commented on pull request #31: URL: https://github.com/apache/maven-wrapper/pull/31#issuecomment-1073112566 OK, I won't notify you again about this release, but will get in touch when a new version is available. 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-wrapper] slawekjaranowski closed pull request #31: Bump mavenVersion from 3.1.0 to 3.8.5
slawekjaranowski closed pull request #31: URL: https://github.com/apache/maven-wrapper/pull/31 -- 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] belingueres commented on a change in pull request #285: [MNG-5222] - Maven 3 no longer logs warnings about deprecated parameter in plugin
belingueres commented on a change in pull request #285:
URL: https://github.com/apache/maven/pull/285#discussion_r830517208
##
File path:
maven-core/src/main/java/org/apache/maven/plugin/internal/ValidatingConfigurationListener.java
##
@@ -94,4 +111,53 @@ private void notify( String fieldName, Object value )
}
}
+private void warnDeprecated( String fieldName, Object value )
+{
+Parameter parameter = mojoDescriptor.getParameterMap().get( fieldName
);
+String deprecated = parameter.getDeprecated();
+if ( deprecated != null && !deprecated.isEmpty() )
+{
+if ( !toString( value ).equals( toString(
parameter.getDefaultValue() ) ) )
+{
+StringBuilder sb = new StringBuilder( " Parameter '" );
+sb.append( fieldName ).append( '\'' );
+if ( parameter.getExpression() != null )
+{
+String userProperty = parameter.getExpression().replace(
"${", "'" ).replace( '}', '\'' );
+sb.append( " (User Property " ).append( userProperty
).append( ")" );
+}
+sb.append( " is deprecated. " ).append( deprecated );
+
+logger.warn( MessageUtils.buffer().warning( sb.toString()
).toString() );
+}
+}
+}
+
+/**
+ * Creates a human-friendly string representation of the specified object.
+ *
+ * @param obj The object to create a string representation for, may be
null.
+ * @return The string representation, never null.
+ */
+private String toString( Object obj )
Review comment:
I have no problem delegating to `DebugConfigurationListener` instead of
duplicating code in `ValidatingConfigurationListener`, but in that case I
suggest also to "un-deprecate" `DebugConfigurationListener` because it is just
confusing if that class should continue to be used or not.
--
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-wrapper] slawekjaranowski commented on pull request #26: Bump maven-parent from 34 to 35
slawekjaranowski commented on pull request #26: URL: https://github.com/apache/maven-wrapper/pull/26#issuecomment-1073058690 I will look at 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-wrapper] slawekjaranowski merged pull request #27: Bump mockito-core from 4.2.0 to 4.4.0
slawekjaranowski merged pull request #27: URL: https://github.com/apache/maven-wrapper/pull/27 -- 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] (MWRAPPER-58) curl cannot follow 302 code when downloading wrapper jar
[ https://issues.apache.org/jira/browse/MWRAPPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509301#comment-17509301 ] ASF GitHub Bot commented on MWRAPPER-58: gzm55 edited a comment on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073039260 > but what do you think about: > > ``` > ... > fi > > [ $? -eq 0 ] || rm ... > ``` > > simply not look good for me > > ``` > fi || rm .. > ``` new commit fix this. -- 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 > curl cannot follow 302 code when downloading wrapper jar > > > Key: MWRAPPER-58 > URL: https://issues.apache.org/jira/browse/MWRAPPER-58 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > example config: > wrapperUrl=https://maven.aliyun.com/repository/central/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-58) curl cannot follow 302 code when downloading wrapper jar
[ https://issues.apache.org/jira/browse/MWRAPPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509300#comment-17509300 ] ASF GitHub Bot commented on MWRAPPER-58: gzm55 commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073039260 > but what do you think about: > > ``` > ... > fi > > [ $? -eq 0 ] || rm ... > ``` > > simply not look good for me > > ``` > fi || rm .. > ``` new commit fix is. -- 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 > curl cannot follow 302 code when downloading wrapper jar > > > Key: MWRAPPER-58 > URL: https://issues.apache.org/jira/browse/MWRAPPER-58 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > example config: > wrapperUrl=https://maven.aliyun.com/repository/central/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] gzm55 commented on pull request #29: [MWRAPPER-58] add -L to curl command
gzm55 commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073039260 > but what do you think about: > > ``` > ... > fi > > [ $? -eq 0 ] || rm ... > ``` > > simply not look good for me > > ``` > fi || rm .. > ``` new commit fix is. -- 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-wrapper] gzm55 edited a comment on pull request #29: [MWRAPPER-58] add -L to curl command
gzm55 edited a comment on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073039260 > but what do you think about: > > ``` > ... > fi > > [ $? -eq 0 ] || rm ... > ``` > > simply not look good for me > > ``` > fi || rm .. > ``` new commit fix this. -- 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] (MWRAPPER-59) Inline MavenWrapperDownloader.java into mvnw
[ https://issues.apache.org/jira/browse/MWRAPPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509299#comment-17509299 ] ASF GitHub Bot commented on MWRAPPER-59: gzm55 commented on pull request #30: URL: https://github.com/apache/maven-wrapper/pull/30#issuecomment-1073038686 > You removed test `maven-wrapper-plugin/src/it/projects/type_source/` How inline downloader are covered by tests? the IT for type_source verify that the _plugin_ can download/extract the correct files, then run `./mvnw -v` can: - produce some logs - download the maven-wrapper.jar The verify process do not mock the environment without neither `curl` nor `wget`, so the java source branch is not covered. The inlined Downloader is very simple than the previous one, and should less likely go wrong. And to test the function of the inlined java source in IT stage, we need hide curl and wget commands before run mvnw; or test in the UT stage, by greping out the java source from the script and run a download task. -- 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 > Inline MavenWrapperDownloader.java into mvnw > > > Key: MWRAPPER-59 > URL: https://issues.apache.org/jira/browse/MWRAPPER-59 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > by inlining a lean version of MavenWrapperDownloader.java into `mnvw` script, > we can remove the `source` installing type, and avoid reuse an outdated > MavenWrapperDownloader.class -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] gzm55 commented on pull request #30: [MWRAPPER-59] Inline MavenWrapperDownloader.java into mvnw
gzm55 commented on pull request #30: URL: https://github.com/apache/maven-wrapper/pull/30#issuecomment-1073038686 > You removed test `maven-wrapper-plugin/src/it/projects/type_source/` How inline downloader are covered by tests? the IT for type_source verify that the _plugin_ can download/extract the correct files, then run `./mvnw -v` can: - produce some logs - download the maven-wrapper.jar The verify process do not mock the environment without neither `curl` nor `wget`, so the java source branch is not covered. The inlined Downloader is very simple than the previous one, and should less likely go wrong. And to test the function of the inlined java source in IT stage, we need hide curl and wget commands before run mvnw; or test in the UT stage, by greping out the java source from the script and run a download task. -- 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] (MWRAPPER-58) curl cannot follow 302 code when downloading wrapper jar
[ https://issues.apache.org/jira/browse/MWRAPPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509298#comment-17509298 ] ASF GitHub Bot commented on MWRAPPER-58: slawekjaranowski commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073036652 but what do you think about: ``` ... fi [ $? -eq 0 ] || rm ... ``` simply not look good for me ``` fi || rm .. ``` -- 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 > curl cannot follow 302 code when downloading wrapper jar > > > Key: MWRAPPER-58 > URL: https://issues.apache.org/jira/browse/MWRAPPER-58 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > example config: > wrapperUrl=https://maven.aliyun.com/repository/central/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #29: [MWRAPPER-58] add -L to curl command
slawekjaranowski commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073036652 but what do you think about: ``` ... fi [ $? -eq 0 ] || rm ... ``` simply not look good for me ``` fi || rm .. ``` -- 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] (MWRAPPER-61) let mvnw call mvn directly
[
https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509294#comment-17509294
]
ASF GitHub Bot commented on MWRAPPER-61:
slawekjaranowski commented on a change in pull request #33:
URL: https://github.com/apache/maven-wrapper/pull/33#discussion_r830499464
##
File path: maven-wrapper-distribution/src/resources/mvnw
##
@@ -19,305 +19,160 @@
#
#
-# Maven Start Up Batch script
-#
-# Required ENV vars:
-# --
-# JAVA_HOME - location of a JDK home dir
+# Maven Wrapper Shell script @project.artifactId@:@project.version@
#
# Optional ENV vars
# -
-# M2_HOME - location of maven2's installed home dir
-# MAVEN_OPTS - parameters passed to the Java VM when running Maven
-# e.g. to debug Maven itself, use
-# set MAVEN_OPTS=-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
-# MAVEN_SKIP_RC - flag to disable loading of mavenrc files
+# JAVA_HOME - location of a JDK home dir, required when download maven via
java source
+# MVNW_REPOURL - repo url base for downloading maven distribution
+# MVNW_USERNAME/MVNW_PASSWORD - user and password for downloading maven
+# MVNW_VERBOSE - true: enable verbose log; debug: trace the mvnw script;
others: silence the output
#
-if [ -z "$MAVEN_SKIP_RC" ] ; then
-
- if [ -f /usr/local/etc/mavenrc ] ; then
-. /usr/local/etc/mavenrc
- fi
-
- if [ -f /etc/mavenrc ] ; then
-. /etc/mavenrc
- fi
-
- if [ -f "$HOME/.mavenrc" ] ; then
-. "$HOME/.mavenrc"
- fi
-
-fi
+set -euf
+[ "${MVNW_VERBOSE-}" != debug ] || set -x
-# OS specific support. $var _must_ be set to either true or false.
-cygwin=false;
-darwin=false;
-mingw=false
-case "`uname`" in
- CYGWIN*) cygwin=true ;;
- MINGW*) mingw=true;;
- Darwin*) darwin=true
-# Use /usr/libexec/java_home if available, otherwise fall back to
/Library/Java/Home
-# See https://developer.apple.com/library/mac/qa/qa1170/_index.html
-if [ -z "$JAVA_HOME" ]; then
- if [ -x "/usr/libexec/java_home" ]; then
-JAVA_HOME="`/usr/libexec/java_home`"; export JAVA_HOME
- else
-JAVA_HOME="/Library/Java/Home"; export JAVA_HOME
- fi
-fi
-;;
+# OS specific support.
+native_path() { printf %s\\n "$1"; }
+case "$(uname)" in
+(CYGWIN*|MINGW*) [ -z "${JAVA_HOME-}" ] || JAVA_HOME="$(cygpath --unix
"$JAVA_HOME")"
+ native_path() { cygpath --path --windows "$1"; } ;;
esac
-if [ -z "$JAVA_HOME" ] ; then
- if [ -r /etc/gentoo-release ] ; then
-JAVA_HOME=`java-config --jre-home`
- fi
-fi
-
-if [ -z "$M2_HOME" ] ; then
- ## resolve links - $0 may be a link to maven's home
- PRG="$0"
-
- # need this for relative symlinks
- while [ -h "$PRG" ] ; do
-ls=`ls -ld "$PRG"`
-link=`expr "$ls" : '.*-> \(.*\)$'`
-if expr "$link" : '/.*' > /dev/null; then
- PRG="$link"
-else
- PRG="`dirname "$PRG"`/$link"
-fi
- done
-
- saveddir=`pwd`
-
- M2_HOME=`dirname "$PRG"`/..
-
- # make it fully qualified
- M2_HOME=`cd "$M2_HOME" && pwd`
-
- cd "$saveddir"
- # echo Using m2 at $M2_HOME
-fi
-
-# For Cygwin, ensure paths are in UNIX format before anything is touched
-if $cygwin ; then
- [ -n "$M2_HOME" ] &&
-M2_HOME=`cygpath --unix "$M2_HOME"`
- [ -n "$JAVA_HOME" ] &&
-JAVA_HOME=`cygpath --unix "$JAVA_HOME"`
- [ -n "$CLASSPATH" ] &&
-CLASSPATH=`cygpath --path --unix "$CLASSPATH"`
-fi
-
-# For Mingw, ensure paths are in UNIX format before anything is touched
-if $mingw ; then
- [ -n "$M2_HOME" ] &&
-M2_HOME="`(cd "$M2_HOME"; pwd)`"
- [ -n "$JAVA_HOME" ] &&
-JAVA_HOME="`(cd "$JAVA_HOME"; pwd)`"
-fi
-
-if [ -z "$JAVA_HOME" ]; then
- javaExecutable="`which javac`"
- if [ -n "$javaExecutable" ] && ! [ "`expr \"$javaExecutable\" : '\([^
]*\)'`" = "no" ]; then
-# readlink(1) is not available as standard on Solaris 10.
-readLink=`which readlink`
-if [ ! `expr "$readLink" : '\([^ ]*\)'` = "no" ]; then
- if $darwin ; then
-javaHome="`dirname \"$javaExecutable\"`"
-javaExecutable="`cd \"$javaHome\" && pwd -P`/javac"
- else
-javaExecutable="`readlink -f \"$javaExecutable\"`"
- fi
- javaHome="`dirname \"$javaExecutable\"`"
- javaHome=`expr "$javaHome" : '\(.*\)/bin'`
- JAVA_HOME="$javaHome"
- export JAVA_HOME
-fi
- fi
-fi
-
-if [ -z "$JAVACMD" ] ; then
- if [ -n "$JAVA_HOME" ] ; then
+# set JAVACMD and JAVACCMD
+set_java_home() {
+ # For Cygwin and MinGW, ensure paths are in Unix format before anything is
touched
+ if [ -n "${JAVA_HOME-}" ] ; then
if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
# IBM's JDK on AIX uses
[GitHub] [maven-wrapper] slawekjaranowski commented on a change in pull request #33: [MWRAPPER-61] Try to skip maven-wrapper.jar, call mvn directly from mvnw.
slawekjaranowski commented on a change in pull request #33:
URL: https://github.com/apache/maven-wrapper/pull/33#discussion_r830499464
##
File path: maven-wrapper-distribution/src/resources/mvnw
##
@@ -19,305 +19,160 @@
#
#
-# Maven Start Up Batch script
-#
-# Required ENV vars:
-# --
-# JAVA_HOME - location of a JDK home dir
+# Maven Wrapper Shell script @project.artifactId@:@project.version@
#
# Optional ENV vars
# -
-# M2_HOME - location of maven2's installed home dir
-# MAVEN_OPTS - parameters passed to the Java VM when running Maven
-# e.g. to debug Maven itself, use
-# set MAVEN_OPTS=-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
-# MAVEN_SKIP_RC - flag to disable loading of mavenrc files
+# JAVA_HOME - location of a JDK home dir, required when download maven via
java source
+# MVNW_REPOURL - repo url base for downloading maven distribution
+# MVNW_USERNAME/MVNW_PASSWORD - user and password for downloading maven
+# MVNW_VERBOSE - true: enable verbose log; debug: trace the mvnw script;
others: silence the output
#
-if [ -z "$MAVEN_SKIP_RC" ] ; then
-
- if [ -f /usr/local/etc/mavenrc ] ; then
-. /usr/local/etc/mavenrc
- fi
-
- if [ -f /etc/mavenrc ] ; then
-. /etc/mavenrc
- fi
-
- if [ -f "$HOME/.mavenrc" ] ; then
-. "$HOME/.mavenrc"
- fi
-
-fi
+set -euf
+[ "${MVNW_VERBOSE-}" != debug ] || set -x
-# OS specific support. $var _must_ be set to either true or false.
-cygwin=false;
-darwin=false;
-mingw=false
-case "`uname`" in
- CYGWIN*) cygwin=true ;;
- MINGW*) mingw=true;;
- Darwin*) darwin=true
-# Use /usr/libexec/java_home if available, otherwise fall back to
/Library/Java/Home
-# See https://developer.apple.com/library/mac/qa/qa1170/_index.html
-if [ -z "$JAVA_HOME" ]; then
- if [ -x "/usr/libexec/java_home" ]; then
-JAVA_HOME="`/usr/libexec/java_home`"; export JAVA_HOME
- else
-JAVA_HOME="/Library/Java/Home"; export JAVA_HOME
- fi
-fi
-;;
+# OS specific support.
+native_path() { printf %s\\n "$1"; }
+case "$(uname)" in
+(CYGWIN*|MINGW*) [ -z "${JAVA_HOME-}" ] || JAVA_HOME="$(cygpath --unix
"$JAVA_HOME")"
+ native_path() { cygpath --path --windows "$1"; } ;;
esac
-if [ -z "$JAVA_HOME" ] ; then
- if [ -r /etc/gentoo-release ] ; then
-JAVA_HOME=`java-config --jre-home`
- fi
-fi
-
-if [ -z "$M2_HOME" ] ; then
- ## resolve links - $0 may be a link to maven's home
- PRG="$0"
-
- # need this for relative symlinks
- while [ -h "$PRG" ] ; do
-ls=`ls -ld "$PRG"`
-link=`expr "$ls" : '.*-> \(.*\)$'`
-if expr "$link" : '/.*' > /dev/null; then
- PRG="$link"
-else
- PRG="`dirname "$PRG"`/$link"
-fi
- done
-
- saveddir=`pwd`
-
- M2_HOME=`dirname "$PRG"`/..
-
- # make it fully qualified
- M2_HOME=`cd "$M2_HOME" && pwd`
-
- cd "$saveddir"
- # echo Using m2 at $M2_HOME
-fi
-
-# For Cygwin, ensure paths are in UNIX format before anything is touched
-if $cygwin ; then
- [ -n "$M2_HOME" ] &&
-M2_HOME=`cygpath --unix "$M2_HOME"`
- [ -n "$JAVA_HOME" ] &&
-JAVA_HOME=`cygpath --unix "$JAVA_HOME"`
- [ -n "$CLASSPATH" ] &&
-CLASSPATH=`cygpath --path --unix "$CLASSPATH"`
-fi
-
-# For Mingw, ensure paths are in UNIX format before anything is touched
-if $mingw ; then
- [ -n "$M2_HOME" ] &&
-M2_HOME="`(cd "$M2_HOME"; pwd)`"
- [ -n "$JAVA_HOME" ] &&
-JAVA_HOME="`(cd "$JAVA_HOME"; pwd)`"
-fi
-
-if [ -z "$JAVA_HOME" ]; then
- javaExecutable="`which javac`"
- if [ -n "$javaExecutable" ] && ! [ "`expr \"$javaExecutable\" : '\([^
]*\)'`" = "no" ]; then
-# readlink(1) is not available as standard on Solaris 10.
-readLink=`which readlink`
-if [ ! `expr "$readLink" : '\([^ ]*\)'` = "no" ]; then
- if $darwin ; then
-javaHome="`dirname \"$javaExecutable\"`"
-javaExecutable="`cd \"$javaHome\" && pwd -P`/javac"
- else
-javaExecutable="`readlink -f \"$javaExecutable\"`"
- fi
- javaHome="`dirname \"$javaExecutable\"`"
- javaHome=`expr "$javaHome" : '\(.*\)/bin'`
- JAVA_HOME="$javaHome"
- export JAVA_HOME
-fi
- fi
-fi
-
-if [ -z "$JAVACMD" ] ; then
- if [ -n "$JAVA_HOME" ] ; then
+# set JAVACMD and JAVACCMD
+set_java_home() {
+ # For Cygwin and MinGW, ensure paths are in Unix format before anything is
touched
+ if [ -n "${JAVA_HOME-}" ] ; then
if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
# IBM's JDK on AIX uses strange locations for the executables
JAVACMD="$JAVA_HOME/jre/sh/java"
+ JAVACCMD="$JAVA_HOME/jre/sh/javac"
else
JAVACMD="$JAVA_HOME/bin/java"
+ JAVACCMD="$JAVA_HOME/bin/javac"
+
+ if [ ! -x "$JAVACMD" ] || [
[jira] [Commented] (MWRAPPER-58) curl cannot follow 302 code when downloading wrapper jar
[ https://issues.apache.org/jira/browse/MWRAPPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509293#comment-17509293 ] ASF GitHub Bot commented on MWRAPPER-58: gzm55 commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073034956 @slawekjaranowski title is fixed the password may contain some special characters for shell, so `AUTH=...` options may require some eval tricks in posix shell to correctly invoke the `curl` or `wget` -- 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 > curl cannot follow 302 code when downloading wrapper jar > > > Key: MWRAPPER-58 > URL: https://issues.apache.org/jira/browse/MWRAPPER-58 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > example config: > wrapperUrl=https://maven.aliyun.com/repository/central/org/apache/maven/wrapper/maven-wrapper/3.1.0/maven-wrapper-3.1.0.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] gzm55 commented on pull request #29: [MWRAPPER-58] add -L to curl command
gzm55 commented on pull request #29: URL: https://github.com/apache/maven-wrapper/pull/29#issuecomment-1073034956 @slawekjaranowski title is fixed the password may contain some special characters for shell, so `AUTH=...` options may require some eval tricks in posix shell to correctly invoke the `curl` or `wget` -- 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] (MWRAPPER-59) Inline MavenWrapperDownloader.java into mvnw
[ https://issues.apache.org/jira/browse/MWRAPPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509292#comment-17509292 ] ASF GitHub Bot commented on MWRAPPER-59: slawekjaranowski commented on pull request #30: URL: https://github.com/apache/maven-wrapper/pull/30#issuecomment-1073034101 You removed test `maven-wrapper-plugin/src/it/projects/type_source/` How inline downloader are covered by tests? -- 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 > Inline MavenWrapperDownloader.java into mvnw > > > Key: MWRAPPER-59 > URL: https://issues.apache.org/jira/browse/MWRAPPER-59 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Major > > by inlining a lean version of MavenWrapperDownloader.java into `mnvw` script, > we can remove the `source` installing type, and avoid reuse an outdated > MavenWrapperDownloader.class -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] slawekjaranowski commented on pull request #30: [MWRAPPER-59] Inline MavenWrapperDownloader.java into mvnw
slawekjaranowski commented on pull request #30: URL: https://github.com/apache/maven-wrapper/pull/30#issuecomment-1073034101 You removed test `maven-wrapper-plugin/src/it/projects/type_source/` How inline downloader are covered by tests? -- 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] (MWRAPPER-61) let mvnw call mvn directly
[ https://issues.apache.org/jira/browse/MWRAPPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509291#comment-17509291 ] ASF GitHub Bot commented on MWRAPPER-61: gzm55 opened a new pull request #35: URL: https://github.com/apache/maven-wrapper/pull/35 This is the cmd batch part of #33 . 1. most behavior is the same as maven-wrapper. 2. dists path pattern is shorten to ~/.m2/wrapper/dists/apache-maven-/, using powershell default file hash 3. the main functions of start, download and install parts are implemented via powershell, which is preinstalled since Win7 SP1 -- 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 > let mvnw call mvn directly > -- > > Key: MWRAPPER-61 > URL: https://issues.apache.org/jira/browse/MWRAPPER-61 > Project: Maven Wrapper > Issue Type: Improvement > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: James Z.M. Gao >Priority: Normal > > try to skip maven-wrapper.jar, call mvn directly from mvnw. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] gzm55 opened a new pull request #35: MWRAPPER-61 Try to skip maven-wrapper.jar, call mvn.cmd directly from mvnw.cmd
gzm55 opened a new pull request #35: URL: https://github.com/apache/maven-wrapper/pull/35 This is the cmd batch part of #33 . 1. most behavior is the same as maven-wrapper. 2. dists path pattern is shorten to ~/.m2/wrapper/dists/apache-maven-/, using powershell default file hash 3. the main functions of start, download and install parts are implemented via powershell, which is preinstalled since Win7 SP1 -- 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-pmd-plugin] slawekjaranowski commented on pull request #60: [MPMD-330] [MPMD-331] Upgrade Maven Parent to 35 and Require Maven 3.2.5+
slawekjaranowski commented on pull request #60: URL: https://github.com/apache/maven-pmd-plugin/pull/60#issuecomment-1072992857 @adangel please look at build log of site .. I see: ``` [INFO] Generating "CPD" report --- maven-pmd-plugin:3.17.0-SNAPSHOT:cpd [INFO] Generating "PMD" report --- maven-pmd-plugin:3.17.0-SNAPSHOT:pmd ``` So I suppose that you use current version of plugin in site build ... I only look at logs... There is a hen and egg problems -- 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] (MPMD-329) Upgrade to PMD 6.44.0
[ https://issues.apache.org/jira/browse/MPMD-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-329: Summary: Upgrade to PMD 6.44.0 (was: Upgrade to PMD 6.43.0) > Upgrade to PMD 6.44.0 > - > > Key: MPMD-329 > URL: https://issues.apache.org/jira/browse/MPMD-329 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel commented on pull request #60: [MPMD-330] [MPMD-331] Upgrade Maven Parent to 35 and Require Maven 3.2.5+
adangel commented on pull request #60: URL: https://github.com/apache/maven-pmd-plugin/pull/60#issuecomment-1072990397 @slawekjaranowski Thanks for the review! > if not use your version I've not tried this - the build would probably fail if the snapshot is not already available in the local repo or snapshots. And for releases I guess, it definitively will miss the version and fail the build -- 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] (MPOM-308) Upgrade Maven PMD Plugin from 3.15.0 to 3.16.0
[
https://issues.apache.org/jira/browse/MPOM-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509252#comment-17509252
]
Andreas Dangel commented on MPOM-308:
-
The old behavior (prior 3.15.0) was to generate only the following reports:
{code:java}
pmd
cpd
{code}
> Upgrade Maven PMD Plugin from 3.15.0 to 3.16.0
> --
>
> Key: MPOM-308
> URL: https://issues.apache.org/jira/browse/MPOM-308
> Project: Maven POMs
> Issue Type: Dependency upgrade
> Components: maven
>Reporter: Slawomir Jaranowski
>Priority: Major
> Fix For: MAVEN-36
>
>
> Release notes https://github.com/apache/maven-parent/pull/57
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-pmd-plugin] slawekjaranowski commented on pull request #60: [MPMD-330] [MPMD-331] Upgrade Maven Parent to 35 and Require Maven 3.2.5+
slawekjaranowski commented on pull request #60: URL: https://github.com/apache/maven-pmd-plugin/pull/60#issuecomment-1072986674 You can download site result from GH https://github.com/apache/maven-pmd-plugin/actions/runs/2008351825 -- 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] (MPMD-332) Support Java 18
Andreas Dangel created MPMD-332: --- Summary: Support Java 18 Key: MPMD-332 URL: https://issues.apache.org/jira/browse/MPMD-332 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Fix For: 3.17.0 With the next PMD version 6.44.0, Java 18 will be supported. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel opened a new pull request #60: [MPMD-330] [MPMD-331] Upgrade Maven Parent to 35 and Require Maven 3.2.5+
adangel opened a new pull request #60: URL: https://github.com/apache/maven-pmd-plugin/pull/60 Fixes * https://issues.apache.org/jira/browse/MPMD-330 * https://issues.apache.org/jira/browse/MPMD-331 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/browse/MPMD) 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 `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-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. - [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 integration tests successfully (`mvn -Prun-its clean verify`). 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) - [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] [Created] (MPMD-331) Require Maven 3.2.5+
Andreas Dangel created MPMD-331: --- Summary: Require Maven 3.2.5+ Key: MPMD-331 URL: https://issues.apache.org/jira/browse/MPMD-331 Project: Maven PMD Plugin Issue Type: Dependency upgrade Components: CPD, PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Fix For: 3.17.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (MPMD-329) Upgrade to PMD 6.43.0
[ https://issues.apache.org/jira/browse/MPMD-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel reopened MPMD-329: - > Upgrade to PMD 6.43.0 > - > > Key: MPMD-329 > URL: https://issues.apache.org/jira/browse/MPMD-329 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MPMD-330) Upgrade Maven Parent to 35
Andreas Dangel created MPMD-330: --- Summary: Upgrade Maven Parent to 35 Key: MPMD-330 URL: https://issues.apache.org/jira/browse/MPMD-330 Project: Maven PMD Plugin Issue Type: Dependency upgrade Components: CPD, PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Fix For: 3.17.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel opened a new pull request #59: [MPMD-309] Add configuration option to show suppressed violations
adangel opened a new pull request #59: URL: https://github.com/apache/maven-pmd-plugin/pull/59 This adds the new configuration option `renderSuppressedViolations` which is enabled by default. When rendering the PMD report into the maven site, the suppressed violations are rendered as well as an additional table. JIRA: https://issues.apache.org/jira/browse/MPMD-309 - 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/browse/MPMD) 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 `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-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. - [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 integration tests successfully (`mvn -Prun-its clean verify`). 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) - [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
[GitHub] [maven-pmd-plugin] adangel merged pull request #58: Bump release-drafter/release-drafter from 5.18.1 to 5.19.0
adangel merged pull request #58: URL: https://github.com/apache/maven-pmd-plugin/pull/58 -- 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] (MPMD-309) Add configuration option to show suppressed violations
[ https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-309: Summary: Add configuration option to show suppressed violations (was: Add configuration options for -showsuppressed) > Add configuration option to show suppressed violations > -- > > Key: MPMD-309 > URL: https://issues.apache.org/jira/browse/MPMD-309 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Stefan Klöss-Schuster >Assignee: Andreas Dangel >Priority: Minor > Fix For: 3.17.0 > > > PMD has the configuration options -showsupressed -shortnames > ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)] > The Maven plugin doesn't support these options at the moment. > Is it possible to add these options? It seems like an easy task and I'll > gladly do this myself. > Best regards, > Stefan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPMD-309) Add configuration options for -showsuppressed
[ https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-309: Summary: Add configuration options for -showsuppressed (was: Add configuration options for -showsuppressed -shortnames) > Add configuration options for -showsuppressed > - > > Key: MPMD-309 > URL: https://issues.apache.org/jira/browse/MPMD-309 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Stefan Klöss-Schuster >Assignee: Andreas Dangel >Priority: Minor > > PMD has the configuration options -showsupressed -shortnames > ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)] > The Maven plugin doesn't support these options at the moment. > Is it possible to add these options? It seems like an easy task and I'll > gladly do this myself. > Best regards, > Stefan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPMD-309) Add configuration options for -showsuppressed
[ https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-309: Fix Version/s: 3.17.0 > Add configuration options for -showsuppressed > - > > Key: MPMD-309 > URL: https://issues.apache.org/jira/browse/MPMD-309 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Stefan Klöss-Schuster >Assignee: Andreas Dangel >Priority: Minor > Fix For: 3.17.0 > > > PMD has the configuration options -showsupressed -shortnames > ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)] > The Maven plugin doesn't support these options at the moment. > Is it possible to add these options? It seems like an easy task and I'll > gladly do this myself. > Best regards, > Stefan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-309) Add configuration options for -showsuppressed -shortnames
[
https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509232#comment-17509232
]
Andreas Dangel commented on MPMD-309:
-
[~kloessst]: {{--short-names}} is already the default behavior when the PMD
report for the maven site is created by maven-pmd-plugin. I'll remove this from
this JIRA task. If you still need this somehow, please create a new issue which
describes your use case.
With 3.17.0 I'm going to add rendering suppressed violations by default and add
an option to disable it.
> Add configuration options for -showsuppressed -shortnames
> -
>
> Key: MPMD-309
> URL: https://issues.apache.org/jira/browse/MPMD-309
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Reporter: Stefan Klöss-Schuster
>Assignee: Andreas Dangel
>Priority: Minor
>
> PMD has the configuration options -showsupressed -shortnames
> ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)]
> The Maven plugin doesn't support these options at the moment.
> Is it possible to add these options? It seems like an easy task and I'll
> gladly do this myself.
> Best regards,
> Stefan
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPMD-309) Add configuration options for -showsuppressed -shortnames
[ https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-309: Component/s: PMD > Add configuration options for -showsuppressed -shortnames > - > > Key: MPMD-309 > URL: https://issues.apache.org/jira/browse/MPMD-309 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Stefan Klöss-Schuster >Assignee: Andreas Dangel >Priority: Minor > > PMD has the configuration options -showsupressed -shortnames > ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)] > The Maven plugin doesn't support these options at the moment. > Is it possible to add these options? It seems like an easy task and I'll > gladly do this myself. > Best regards, > Stefan -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MPMD-309) Add configuration options for -showsuppressed -shortnames
[ https://issues.apache.org/jira/browse/MPMD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel reassigned MPMD-309: --- Assignee: Andreas Dangel > Add configuration options for -showsuppressed -shortnames > - > > Key: MPMD-309 > URL: https://issues.apache.org/jira/browse/MPMD-309 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Stefan Klöss-Schuster >Assignee: Andreas Dangel >Priority: Minor > > PMD has the configuration options -showsupressed -shortnames > ([https://pmd.github.io/latest/pmd_userdocs_cli_reference.html)] > The Maven plugin doesn't support these options at the moment. > Is it possible to add these options? It seems like an easy task and I'll > gladly do this myself. > Best regards, > Stefan -- This message was sent by Atlassian Jira (v8.20.1#820001)
