[GitHub] [maven-artifact-plugin] bmarwell commented on pull request #7: prefer Apache Commons StringUtils
bmarwell commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-763384330 I'd say `-1` to this one. Either create a `maven-lang` lib for the same reason as guava, commons-lang, etc. exist, or just wait for Java 8. @elharo no offense intended, but I honestly think (while I fully agree with what you mentioned earlier!) pulling in another dependency replacing a not-removable dependency is not worth it. Even if more changes like this are to come. It is well-tested enough as this code existed for years and did not break. So, Maven 4 + Java 8 is not far away. Lets wait a few months and do a *real* java8 clean up then, wdyt? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7074) Environment Variable defaulting
[
https://issues.apache.org/jira/browse/MNG-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268369#comment-17268369
]
Loïc Hermann commented on MNG-7074:
---
Environnement variables can be accessed as properties:
https://github.com/apache/maven/blob/39641ac803e17360df40288aaeb40ea0c5ccd77d/maven-core/src/main/java/org/apache/maven/properties/internal/EnvironmentUtils.java
> Environment Variable defaulting
> ---
>
> Key: MNG-7074
> URL: https://issues.apache.org/jira/browse/MNG-7074
> Project: Maven
> Issue Type: New Feature
>Reporter: Loïc Hermann
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Hi all,
> maven build in CI environment often rely on environnement variables.
> If those environment variables are not defined on the developper environment
> the build will fail.
> {{For now defaulting those environment variable can only be done by defining
> one profile per variable which is really verbose.}}
> {{it would be easier if we can either}}
> {{add a default value where the variable is used:}}
> ```
> {{$\{env.VARIABLE_NAME:defaultValue}}}
> ```
> or have a section to define default values in the pom:
> ```
>
> <{{VARIABLE_NAME}}>defaultValue
>
> ```
> I would love to work on a PR to implements one of those solution if this make
> sense to you.
>
> Regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268338#comment-17268338
]
Arul Elvis J commented on WAGON-603:
[~michael-o] Managed to get some extra logs throwing 403 forbidden error before
failing.
{noformat}
2021-01-19T15:18:23.4816376Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger -
2021-01-19T15:18:23.5872831Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - <
au.com.bat:bata-s-sfdc-deferredpromo >
2021-01-19T15:18:23.5875769Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - Building
bata-s-sfdc-deferredpromo 1.0.2
2021-01-19T15:18:23.5878345Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - --[
mule-application ]--
2021-01-19T15:18:29.6441716Z [main] [WARNING]
org.codehaus.plexus.PlexusContainer - Could not transfer metadata
com.fasterxml.jackson.core:jackson-core/maven-metadata.xml from/to
microsoft-releases
(https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc/):
Forbidden (403)
2021-01-19T15:19:35.6448025Z [main] [WARNING]
org.codehaus.plexus.PlexusContainer - Could not transfer metadata
com.fasterxml.jackson.core:jackson-annotations/maven-metadata.xml from/to
microsoft-releases
(https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc/):
Forbidden (403)
2021-01-19T15:19:56.1497288Z [main] [WARNING]
org.codehaus.plexus.PlexusContainer - Could not transfer metadata
com.fasterxml.jackson.core:jackson-databind/maven-metadata.xml from/to
microsoft-releases
(https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc/):
Forbidden (403)
2021-01-19T15:26:17.0569935Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger -
2021-01-19T15:26:17.0571308Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - ---
maven-clean-plugin:2.5:clean (default-clean-1) @ bata-s-sfdc-deferredpromo ---
2021-01-19T15:26:42.4112274Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger -
2021-01-19T15:26:42.4112942Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - BUILD FAILURE
2021-01-19T15:26:42.4113552Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger -
2021-01-19T15:26:42.4114570Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - Total time: 08:53 min
2021-01-19T15:26:42.4115073Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger - Finished at:
2021-01-19T15:26:42Z
2021-01-19T15:26:42.4115665Z [main] [INFO]
org.apache.maven.cli.event.ExecutionEventLogger -
2021-01-19T15:26:42.4438501Z [main] [ERROR] org.apache.maven.cli.MavenCli -
Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:2.5:clean
(default-clean-1) on project bata-s-sfdc-deferredpromo: Execution
default-clean-1 of goal org.apache.maven.plugins:maven-clean-plugin:2.5:clean
failed: Plugin org.apache.maven.plugins:maven-clean-plugin:2.5 or one of its
dependencies could not be resolved: Failed to collect dependencies at
org.apache.maven.plugins:maven-clean-plugin:jar:2.5 ->
org.apache.maven:maven-plugin-api:jar:2.0.6: Failed to read artifact descriptor
for org.apache.maven:maven-plugin-api:jar:2.0.6: Could not transfer artifact
org.apache.maven:maven-plugin-api:pom:2.0.6 from/to central
(https://repo.maven.apache.org/maven2): Connection reset -> [Help 1]{noformat}
Check if this helps. Attaching the full logs as well :
[^Failed_build_debug_logJan20.txt]
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: Failed_build_debug_logJan20.txt, Maven Goal - Deploy -
> Debug Logs.txt, failed_logs-batch-wired.txt,
> failed_logs-batch-wired_jan15.txt, failed_logs-batch-wired_jan15.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
>
[jira] [Updated] (WAGON-603) Connection reset error from Azure pipelines
[
https://issues.apache.org/jira/browse/WAGON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arul Elvis J updated WAGON-603:
---
Attachment: Failed_build_debug_logJan20.txt
> Connection reset error from Azure pipelines
> ---
>
> Key: WAGON-603
> URL: https://issues.apache.org/jira/browse/WAGON-603
> Project: Maven Wagon
> Issue Type: Bug
> Environment: In both Ubuntu and Windows agent specification
>Reporter: Arul Elvis J
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: Failed_build_debug_logJan20.txt, Maven Goal - Deploy -
> Debug Logs.txt, failed_logs-batch-wired.txt,
> failed_logs-batch-wired_jan15.txt, failed_logs-batch-wired_jan15.txt,
> failed_logs-batch-wired_latest.txt, logs_143613.zip
>
> Original Estimate: 408h
> Remaining Estimate: 408h
>
> When the pipelines are executed in Azure pipelines, we are facing connection
> reset error. Azure pipelines team claims that connection is closed from Maven
> central repo end. Below is the error message. Have attached the complete log
> zip file for your reference. Can you please prioritize as soon as possible,
> as it is impacting all the pipelines including the production builds ?
>
> {{ }}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
> (default-resources) on project bata-s-sfdc-deferredpromo: Execution
> default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed:
> Plugin org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
> org.apache.maven:maven-plugin-api:jar:3.0 ->
> org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
> artifact descriptor for
> org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
> artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
> central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> [http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException]
> The process
> 'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
> with exit code 1
> Could not retrieve code analysis results - Maven run failed.
> {{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
[
https://issues.apache.org/jira/browse/SUREFIRE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated SUREFIRE-1879:
---
Description:
With 3.0.0-M5, an exception from a shutdown hook is not printed to the console.
This works as expected with 3.0.0-M4.
To reproduce, run the project from the attached zipfile:
{noformat}
mvn test
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.HookOutputTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 s
- in org.apache.maven.surefire.HookOutputTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{noformat}
{noformat}
mvn test -Dsurefire.version=3.0.0-M4
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.HookOutputTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 s
- in org.apache.maven.surefire.HookOutputTest
Exception in thread "Thread-3" java.lang.IllegalStateException: test
at
org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
at
org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
Source)
at java.base/java.lang.Thread.run(Thread.java:836)
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{noformat}
PS: I originally ran into this here:
https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
was:
With 3.0.0-M5, an exception from a shutdown hook is not printed to the console.
This works as expected with 3.0.0-M4.
To reproduce, run the project from the attached zipfile:
{noformat}
mvn test
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.HookOutputTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 s
- in org.apache.maven.surefire.HookOutputTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{noformat}
{noformat}
mvn test -Dsurefire.version=3.0.0-M4
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.AppTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 s
- in org.apache.maven.surefire.AppTest
Exception in thread "Thread-3" java.lang.IllegalStateException: test
at
org.apache.maven.surefire.AppTest.lambda$testHookOutput$0(AppTest.java:42)
at
org.apache.maven.surefire.AppTest$$Lambda$29/00.run(Unknown
Source)
at java.base/java.lang.Thread.run(Thread.java:836)
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
{noformat}
PS: I originally ran into this here:
https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
> M5 swallows exception output from shutdown hooks
>
>
> Key: SUREFIRE-1879
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /home/moldowan/.sdkman/candidates/maven/current
> Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
> /home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
> Default locale: c.u_US, platform encoding: UTF-8
> OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
> family: "unix"
>Reporter: Falko Modler
>Priority: Major
> Attachments: surefire-bug-hook-output.zip
>
>
> With 3.0.0-M5, an exception from a shutdown hook is not printed to the
> console.
> This works as expected with 3.0.0-M4.
> To reproduce, run the project from the attached zipfile:
> {noformat}
> mvn test
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029
> s - in org.apache.maven.surefire.HookOutputTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> {noformat}
> mvn test -Dsurefire.version=3.0.0-M4
> {noformat}
> {noformat}
> [INFO] Running org.apache.maven.surefire.HookOutputTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028
> s - in org.apache.maven.surefire.HookOutputTest
> Exception in thread "Thread-3" java.lang.IllegalStateException: test
> at
> org.apache.maven.surefire.HookOutputTest.lambda$testHookOutput$0(HookOutputTest.java:10)
> at
> org.apache.maven.surefire.HookOutputTest$$Lambda$314/00.run(Unknown
> Source)
> at java.base/java.lang.Thread.run(Thread.java:836)
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> PS: I originally ran into this here:
>
[jira] [Created] (SUREFIRE-1879) M5 swallows exception output from shutdown hooks
Falko Modler created SUREFIRE-1879:
--
Summary: M5 swallows exception output from shutdown hooks
Key: SUREFIRE-1879
URL: https://issues.apache.org/jira/browse/SUREFIRE-1879
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.0.0-M5
Environment: Apache Maven 3.6.3
(cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/moldowan/.sdkman/candidates/maven/current
Java version: 11.0.9, vendor: AdoptOpenJDK, runtime:
/home/moldowan/.sdkman/candidates/java/11.0.9.j9-adpt
Default locale: c.u_US, platform encoding: UTF-8
OS name: "linux", version: "4.19.128-microsoft-standard", arch: "amd64",
family: "unix"
Reporter: Falko Modler
Attachments: surefire-bug-hook-output.zip
With 3.0.0-M5, an exception from a shutdown hook is not printed to the console.
This works as expected with 3.0.0-M4.
To reproduce, run the project from the attached zipfile:
{noformat}
mvn test
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.HookOutputTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 s
- in org.apache.maven.surefire.HookOutputTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
{noformat}
{noformat}
mvn test -Dsurefire.version=3.0.0-M4
{noformat}
{noformat}
[INFO] Running org.apache.maven.surefire.AppTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 s
- in org.apache.maven.surefire.AppTest
Exception in thread "Thread-3" java.lang.IllegalStateException: test
at
org.apache.maven.surefire.AppTest.lambda$testHookOutput$0(AppTest.java:42)
at
org.apache.maven.surefire.AppTest$$Lambda$29/00.run(Unknown
Source)
at java.base/java.lang.Thread.run(Thread.java:836)
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
{noformat}
PS: I originally ran into this here:
https://github.com/quarkusio/quarkus/pull/14311#pullrequestreview-569179938
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1801) New TCP communication mode defers "Listening for transport" debug message
[
https://issues.apache.org/jira/browse/SUREFIRE-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268270#comment-17268270
]
Falko Modler commented on SUREFIRE-1801:
[~tibordigana] I had a look at the code back in December and I was totally lost.
Unfortunately, I cannot spend multiple evenings on this but I could help here
and there, just let me know.
> New TCP communication mode defers "Listening for transport" debug message
> -
>
> Key: SUREFIRE-1801
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1801
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 3.0.0-M5
> Environment: $ mvn -version
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Develop\some-project\middleware\_develop\maven\default
> Java version: 11.0.7, vendor: AdoptOpenJDK, runtime:
> C:\Develop\some-project\middleware\_develop\java\default
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Priority: Minor
> Fix For: 3.0.0-M6
>
>
> When using
> {code:xml}
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>
> {code}
> and {{-Dmaven.surefire.debug}} you see the message
> {noformat}
> Listening for transport dt_socket at address: 5005
> {noformat}
> _only after_ you have connected the debugger, which defeats the whole point
> of this message and leaves the user under the impression that test execution
> is stuck before opening the debug port.
> In "legacy" mode the message is displayed as expected (before connecting the
> debugger).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1053) scm element removed during release:prepare when leveraging custom inheritance rules
[
https://issues.apache.org/jira/browse/MRELEASE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268266#comment-17268266
]
Herve Boutemy commented on MRELEASE-1053:
-
why is it defined in every POM and not only in parent?
https://github.com/apache/jackrabbit-filevault/commit/f8387a5a1cb46e90350dfdf62da1b194c6ae9f0f#diff-1f25614fa9ce293f1e5a645b1ff32692b242000903dbd29d43ead3ef8e48093e
> scm element removed during release:prepare when leveraging custom inheritance
> rules
> ---
>
> Key: MRELEASE-1053
> URL: https://issues.apache.org/jira/browse/MRELEASE-1053
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> When leveraging the custom inheritance rules being introduced with MNG-6059
> the m-release-p removes the {{scm}} element from the pom.xml during
> {{release:prepare}}.
> You find an example for that behaviour at
> https://github.com/apache/jackrabbit-filevault/commit/3a175724d8d3608bc96e92ed7fd9154fd56d1e30#diff-04dc5d029560773ac79faaf3da0fbb22L68
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268188#comment-17268188 ] Stefan Oehme commented on SUREFIRE-1878: Or maybe even better `skipAfterFlakeCount` to match `skipAfterFailureCount`. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268165#comment-17268165
]
Martin Kanters commented on MNG-5760:
-
[~max.ander...@jboss.com] thanks for your interest in this issue and I agree
that the Hudson notifications are annoying, I'll see how/if we can avoid that.
Anyhow, it's a feature that will definitely be part of Maven 4. So keep your
eye on that release :)
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] gnodet commented on pull request #402: DefaultProjectBuilder enhancements
gnodet commented on pull request #402: URL: https://github.com/apache/maven/pull/402#issuecomment-763061798 @rfscholte I've rebased and fix the integration 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] elharo commented on a change in pull request #34: [MCOMPILER-428] improve incremental compilation documentation
elharo commented on a change in pull request #34: URL: https://github.com/apache/maven-compiler-plugin/pull/34#discussion_r560415436 ## File path: src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java ## @@ -483,7 +483,19 @@ private List fileExtensions; /** - * to enable/disable incrementation compilation feature + * to enable/disable incrementation compilation feature. Review comment: incrementation --> incremental This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRELEASE-1053) scm element removed during release:prepare when leveraging custom inheritance rules
[
https://issues.apache.org/jira/browse/MRELEASE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268138#comment-17268138
]
Konrad Windszus commented on MRELEASE-1053:
---
IMHO the prepare release commit looks good. The tag scm element is correctly
adjusted. Why do you think the tag element is wrong?
> scm element removed during release:prepare when leveraging custom inheritance
> rules
> ---
>
> Key: MRELEASE-1053
> URL: https://issues.apache.org/jira/browse/MRELEASE-1053
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> When leveraging the custom inheritance rules being introduced with MNG-6059
> the m-release-p removes the {{scm}} element from the pom.xml during
> {{release:prepare}}.
> You find an example for that behaviour at
> https://github.com/apache/jackrabbit-filevault/commit/3a175724d8d3608bc96e92ed7fd9154fd56d1e30#diff-04dc5d029560773ac79faaf3da0fbb22L68
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-artifact-plugin] hboutemy commented on pull request #7: prefer Apache Commons StringUtils
hboutemy commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-763046022 I don't have time to play on that: working on real plugin enhancements is more useful than personal taste changes if such changes is the only feedback I get, I don't need feedback, thank you This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRELEASE-1053) scm element removed during release:prepare when leveraging custom inheritance rules
[
https://issues.apache.org/jira/browse/MRELEASE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268130#comment-17268130
]
Herve Boutemy commented on MRELEASE-1053:
-
uh, strange
IMHO, it's interesting to look at previous "prepare release" commit, because it
adds unwanted scm/tag elements:
https://github.com/apache/jackrabbit-filevault/commit/f8387a5a1cb46e90350dfdf62da1b194c6ae9f0f
> scm element removed during release:prepare when leveraging custom inheritance
> rules
> ---
>
> Key: MRELEASE-1053
> URL: https://issues.apache.org/jira/browse/MRELEASE-1053
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> When leveraging the custom inheritance rules being introduced with MNG-6059
> the m-release-p removes the {{scm}} element from the pom.xml during
> {{release:prepare}}.
> You find an example for that behaviour at
> https://github.com/apache/jackrabbit-filevault/commit/3a175724d8d3608bc96e92ed7fd9154fd56d1e30#diff-04dc5d029560773ac79faaf3da0fbb22L68
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-compiler-plugin] rfscholte commented on pull request #34: [MCOMPILER-428] improve incremental compilation documentation
rfscholte commented on pull request #34: URL: https://github.com/apache/maven-compiler-plugin/pull/34#issuecomment-763004082 @elharo is the native english speaker here This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-428) Documentation regarding useIncrementalCompilation not very useful
[ https://issues.apache.org/jira/browse/MCOMPILER-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268035#comment-17268035 ] Thomas Bracher commented on MCOMPILER-428: -- I feel like this PR is under the radar. If anyone has time to check it again, that'll be much appreciated! > Documentation regarding useIncrementalCompilation not very useful > - > > Key: MCOMPILER-428 > URL: https://issues.apache.org/jira/browse/MCOMPILER-428 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Thomas Bracher >Priority: Minor > Labels: documentation > > As of today, maven-compiler-plugin documentation for > useIncrementalCompilation says: "to enable/disable incrementation compilation > feature". Since there is no documentation of said feature, users will have to > either: > 1) take a guess at how the feature behaves > 2) painfully read the plugin code to understand what it does > This is less than optimal and lead to misunderstanding, like this comment > https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=14428972=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14428972 > > So far the most explicit documentation I have found is in answer of a > stackoverflow issue: https://stackoverflow.com/a/49700942 > I think it would benefit a lot of users to understand the implication of both > options of this flag. I am trying to submit a PR providing an example of text. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-compiler-plugin] sadraskol commented on pull request #34: [MCOMPILER-428] improve incremental compilation documentation
sadraskol commented on pull request #34: URL: https://github.com/apache/maven-compiler-plugin/pull/34#issuecomment-762978139 I feel like this PR is under the radar. If anyone has time to check it again, that'll be much appreciated! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-plugin] rmannibucau commented on pull request #7: prefer Apache Commons StringUtils
rmannibucau commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-762973071 @michael-o most of these utilities are in java 8 or are trivial (like 1 or 2 calls) so the need to argument about a 3rd party disappear for all modules. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7078) The integration tests use the default maven settings
[
https://issues.apache.org/jira/browse/MNG-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7078:
---
Assignee: Michael Osipov
> The integration tests use the default maven settings
>
>
> Key: MNG-7078
> URL: https://issues.apache.org/jira/browse/MNG-7078
> Project: Maven
> Issue Type: Improvement
> Components: Integration Tests
>Reporter: Guillaume Nodet
>Assignee: Michael Osipov
>Priority: Major
>
> I have a profile that caused one integration test to fail, but it took me
> some time to realise the problem came from my {{~/.m2/settings.xml}} file.
> It would be better to have the tests use an empty settings file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7078) The integration tests use the default maven settings
[
https://issues.apache.org/jira/browse/MNG-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17268013#comment-17268013
]
Michael Osipov commented on MNG-7078:
-
MNG-6772? This will be rewritten, removed soon.
> The integration tests use the default maven settings
>
>
> Key: MNG-7078
> URL: https://issues.apache.org/jira/browse/MNG-7078
> Project: Maven
> Issue Type: Improvement
> Components: Integration Tests
>Reporter: Guillaume Nodet
>Priority: Major
>
> I have a profile that caused one integration test to fail, but it took me
> some time to realise the problem came from my {{~/.m2/settings.xml}} file.
> It would be better to have the tests use an empty settings file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7078) The integration tests use the default maven settings
Guillaume Nodet created MNG-7078:
Summary: The integration tests use the default maven settings
Key: MNG-7078
URL: https://issues.apache.org/jira/browse/MNG-7078
Project: Maven
Issue Type: Improvement
Components: Integration Tests
Reporter: Guillaume Nodet
I have a profile that caused one integration test to fail, but it took me some
time to realise the problem came from my {{~/.m2/settings.xml}} file. It would
be better to have the tests use an empty settings file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1878) Add failOnFlake option
[ https://issues.apache.org/jira/browse/SUREFIRE-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated SUREFIRE-1878: --- Description: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. was: The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail on failed tests, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. > Add failOnFlake option > -- > > Key: SUREFIRE-1878 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Stefan Oehme >Priority: Minor > > The Surefire plugin currently covers two use cases with its > `rerunFailingTestCount` option: > 1. rerunFailingTestCount=0: The build will fail immediately, but I don't know > if it was a real failure or a flake. This option is best for healthy code > bases with very little or no flakiness. > 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build > will be successful, so there is no pressure to fix the flakes. This helps > when the situation is really bad and I just want to get some green build > again to boost team morale :) > I'd like to support a third use case: > 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will > fail (so there is actually pressure to deal with flakiness) and I can tell > the difference between real failures and flakes. I think this would be the > best option for projects with a medium amount of flaky tests and a team that > wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1878) Add failOnFlake option
Stefan Oehme created SUREFIRE-1878: -- Summary: Add failOnFlake option Key: SUREFIRE-1878 URL: https://issues.apache.org/jira/browse/SUREFIRE-1878 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Reporter: Stefan Oehme The Surefire plugin currently covers two use cases with its `rerunFailingTestCount` option: 1. rerunFailingTestCount=0: The build will fail on failed tests, but I don't know if it was a real failure or a flake. This option is best for healthy code bases with very little or no flakiness. 2. rerunFailingTestCount>0: I will know when a test is flaky, but the build will be successful, so there is no pressure to fix the flakes. This helps when the situation is really bad and I just want to get some green build again to boost team morale :) I'd like to support a third use case: 3. rerunFailingTestCount>0 and a new option failOnFlake=true: The build will fail (so there is actually pressure to deal with flakiness) and I can tell the difference between real failures and flakes. I think this would be the best option for projects with a medium amount of flaky tests and a team that wants to take care of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267910#comment-17267910
]
Max Rydahl Andersen commented on MNG-5760:
--
would love to keep following this issue but with hudson being massive noise
generator I'll have to unsubscribe.
ping me if something need to test/verify/feedback on.
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-artifact-plugin] michael-o commented on pull request #7: prefer Apache Commons StringUtils
michael-o commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-762865807 > > > Lets validate we move to j8 for that too, then all these utilities are useless. What do you mean by that? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-plugin] rmannibucau commented on pull request #7: prefer Apache Commons StringUtils
rmannibucau commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-762854674 Lets validate we move to j8 for that too, then all these utilities are useless. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-plugin] michael-o commented on pull request #7: prefer Apache Commons StringUtils
michael-o commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-762829347 I fully agree with @elharo This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #331: [SUREFIRE-1876] Added support for skipping unit test execution not affecting integration test execution
Tibor17 commented on pull request #331: URL: https://github.com/apache/maven-surefire/pull/331#issuecomment-762823393 We are aiming for splitting both plugins, so that each of them would be controlled by unique property. But i think we do not have to create a new property. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-plugin] elharo commented on pull request #7: prefer Apache Commons StringUtils
elharo commented on pull request #7: URL: https://github.com/apache/maven-artifact-plugin/pull/7#issuecomment-762820234 Yes, that's why maven-shared-utils was made. And plexus-utils. And Apache commons lang. And Guava. Programmers seem really fond of building utility libraries to do the same hundred or so not-especially-difficult operations. We should standardize on one, and apache commons lang is by far the best maintained such library already in our tree. (Guava's good too but is generally not common in Apache projects. It also has some pretty bad version conflicts.) maven-shared-utils should be used for methods that are maven specific in some way, not general string and file manipulation utilities. Ultimately I want to deprecate and remove all such general purpose methods from maven-shared-utils so we have less generic utility code to maintain and can focus on Maven itself. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MDEPLOY-283) Improved configuration syntax for deploy-file
Gintas Grigelionis created MDEPLOY-283:
--
Summary: Improved configuration syntax for deploy-file
Key: MDEPLOY-283
URL: https://issues.apache.org/jira/browse/MDEPLOY-283
Project: Maven Deploy Plugin
Issue Type: Improvement
Reporter: Gintas Grigelionis
The configuration syntax for deployment of multiple files is ugly: ,
and as unrelated comma-separated and repetitive (for
types) lists. I would like to propose
{{}}
{{ }}
{{ ...}}
{{ ...}}
{{ ...}}
{{ }}
{{}}
as a complement (and maybe a replacement).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-1053) scm element removed during release:prepare when leveraging custom inheritance rules
[
https://issues.apache.org/jira/browse/MRELEASE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267820#comment-17267820
]
Konrad Windszus edited comment on MRELEASE-1053 at 1/19/21, 11:16 AM:
--
It happened again in
https://github.com/apache/jackrabbit-filevault/commit/00ec91784b52f3b87ff890535228d45e37a4630f.
[~hboutemy] Do you have any pointers what may go wrong here, as you implemented
https://issues.apache.org/jira/browse/MNG-6059?
Probably something in
https://github.com/apache/maven-release/blob/44ff401499713c981732f3379de2cf6693e0fdef/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/RewritePomsForDevelopmentPhase.java#L48
goes wrong.
was (Author: kwin):
It happened again in
https://github.com/apache/jackrabbit-filevault/commit/00ec91784b52f3b87ff890535228d45e37a4630f.
[~hboutemy] Do you have any pointers what may go wrong here, as you implemented
https://issues.apache.org/jira/browse/MNG-6059?
> scm element removed during release:prepare when leveraging custom inheritance
> rules
> ---
>
> Key: MRELEASE-1053
> URL: https://issues.apache.org/jira/browse/MRELEASE-1053
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> When leveraging the custom inheritance rules being introduced with MNG-6059
> the m-release-p removes the {{scm}} element from the pom.xml during
> {{release:prepare}}.
> You find an example for that behaviour at
> https://github.com/apache/jackrabbit-filevault/commit/3a175724d8d3608bc96e92ed7fd9154fd56d1e30#diff-04dc5d029560773ac79faaf3da0fbb22L68
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-1053) scm element removed during release:prepare when leveraging custom inheritance rules
[
https://issues.apache.org/jira/browse/MRELEASE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267820#comment-17267820
]
Konrad Windszus commented on MRELEASE-1053:
---
It happened again in
https://github.com/apache/jackrabbit-filevault/commit/00ec91784b52f3b87ff890535228d45e37a4630f.
[~hboutemy] Do you have any pointers what may go wrong here, as you implemented
https://issues.apache.org/jira/browse/MNG-6059?
> scm element removed during release:prepare when leveraging custom inheritance
> rules
> ---
>
> Key: MRELEASE-1053
> URL: https://issues.apache.org/jira/browse/MRELEASE-1053
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> When leveraging the custom inheritance rules being introduced with MNG-6059
> the m-release-p removes the {{scm}} element from the pom.xml during
> {{release:prepare}}.
> You find an example for that behaviour at
> https://github.com/apache/jackrabbit-filevault/commit/3a175724d8d3608bc96e92ed7fd9154fd56d1e30#diff-04dc5d029560773ac79faaf3da0fbb22L68
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-272) Add skip capability to deploy-file goal
[ https://issues.apache.org/jira/browse/MDEPLOY-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267819#comment-17267819 ] Gintas Grigelionis commented on MDEPLOY-272: I assume that this would prevent the deploy plugin from complaining about the configuration being incomplete, too? > Add skip capability to deploy-file goal > --- > > Key: MDEPLOY-272 > URL: https://issues.apache.org/jira/browse/MDEPLOY-272 > Project: Maven Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: Tom Esh >Priority: Major > > Currently the deploy-file goal doesn't support the > configuration parameter. > I have a case where that would be very useful, as I would like to > conditionally deploy a file based on a maven property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
