[GitHub] [maven-apache-parent] olamy commented on pull request #97: Bump maven-remote-resources-plugin from 1.7.0 to 3.0.0
olamy commented on PR #97: URL: https://github.com/apache/maven-apache-parent/pull/97#issuecomment-1207130069 do not apply because of https://issues.apache.org/jira/browse/MRRESOURCES-121 -- 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] (MRRESOURCES-121) version 3.0.0 fail to include some dependencies
Olivier Lamy created MRRESOURCES-121: Summary: version 3.0.0 fail to include some dependencies Key: MRRESOURCES-121 URL: https://issues.apache.org/jira/browse/MRRESOURCES-121 Project: Maven Remote Resources Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Olivier Lamy for some reasons, the version is skipping some dependencies and those dependencies are not included anymore in DEPENDENCIES file! example building maven-core branch maven-3.8.x module maven-core give the following warnings [*INFO*] *---* maven-remote-resources-plugin:3.0.0:process *(process-resource-bundles)* @ maven-core *---* [*INFO*] Preparing remote bundle org.apache:apache-jar-resource-bundle:1.4 [*INFO*] Copying 3 resources from 1 bundle. [*WARNING*] Failed to build parent project for org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0 [*WARNING*] Invalid project model for artifact [plexus-sec-dispatcher:org.codehaus.plexus:2.0]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.codehaus.plexus:plexus-cipher:jar:2.0 [*WARNING*] Invalid project model for artifact [plexus-cipher:org.codehaus.plexus:2.0]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.apache.commons:commons-lang3:jar:3.8.1 [*WARNING*] Invalid project model for artifact [commons-lang3:org.apache.commons:3.8.1]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.apache.maven.resolver:maven-resolver-api:jar:1.6.3 [*WARNING*] Invalid project model for artifact [maven-resolver-api:org.apache.maven.resolver:1.6.3]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.apache.maven.resolver:maven-resolver-spi:jar:1.6.3 [*WARNING*] Invalid project model for artifact [maven-resolver-spi:org.apache.maven.resolver:1.6.3]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.apache.maven.resolver:maven-resolver-util:jar:1.6.3 [*WARNING*] Invalid project model for artifact [maven-resolver-util:org.apache.maven.resolver:1.6.3]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for org.apache.maven.resolver:maven-resolver-impl:jar:1.6.3 [*WARNING*] Invalid project model for artifact [maven-resolver-impl:org.apache.maven.resolver:1.6.3]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for commons-io:commons-io:jar:2.6 [*WARNING*] Invalid project model for artifact [commons-io:commons-io:2.6]. It will be ignored by the remote resources Mojo. [*WARNING*] Failed to build parent project for com.google.inject:guice:jar:4.2.2 [*WARNING*] Invalid project model for artifact [guice:com.google.inject:4.2.2]. It will be ignored by the remote resources Mojo. This result those dependencies not anymore part of the DEPENDENCIES file diff: *➜* *maven-core* *git:(**maven-3.8.x**)* *✗* diff work/after-upgrade/DEPENDENCIES work/before-upgrade/DEPENDENCIES 38a39,44 > From: 'Codehaus Plexus' (https://codehaus-plexus.github.io/) > - Plexus Cipher: encryption/decryption Component > (https://codehaus-plexus.github.io/plexus-cipher/) > org.codehaus.plexus:plexus-cipher:jar:2.0 > License: Apache License, Version 2.0 > (http://www.apache.org/licenses/LICENSE-2.0.txt) > - Plexus Security Dispatcher Component > (https://codehaus-plexus.github.io/plexus-sec-dispatcher/) > org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0 > License: Apache License, Version 2.0 > (http://www.apache.org/licenses/LICENSE-2.0.txt) > 42a49,52 > From: 'Google, Inc.' (http://www.google.com) > - Google Guice - Core Library (https://github.com/google/guice/guice) > com.google.inject:guice:jar:4.2.2 > License: The Apache Software License, Version 2.0 > (http://www.apache.org/licenses/LICENSE-2.0.txt) > 47a58,61 > - Apache Commons IO (http://commons.apache.org/proper/commons-io/) > commons-io:commons-io:jar:2.6 > License: Apache License, Version 2.0 > (https://www.apache.org/licenses/LICENSE-2.0.txt) > - Apache Commons Lang (http://commons.apache.org/proper/commons-lang/) > org.apache.commons:commons-lang3:jar:3.8.1 > License: Apache License, Version 2.0 > (https://www.apache.org/licenses/LICENSE-2.0.txt) 65a80,87 > - Maven Artifact Resolver API > (https://maven.apache.org/resolver/maven-resolver-api/) > org.apache.maven.resolver:maven-resolver-api:jar:1.6.3 > License: Apache License, Version 2.0 > (https://www.apache.org/licenses/LICENSE-2.0.txt) > - Maven Artifact Resolver Implementation > (https://maven.apache.org/resolver/maven-resolver-impl/) > org.apache.maven.resolver:maven-resolver-impl:jar:1.6.3 > License: Apache License, Version
[jira] [Created] (MJAVADOC-722) Allow Logging Javadoc Warnings and Errors to File
Alan Zimmer created MJAVADOC-722: Summary: Allow Logging Javadoc Warnings and Errors to File Key: MJAVADOC-722 URL: https://issues.apache.org/jira/browse/MJAVADOC-722 Project: Maven Javadoc Plugin Issue Type: New Feature Components: javadoc Reporter: Alan Zimmer Allow for Javadoc generation, either implicitly or through a new configuration, to generate a file containing the warnings and errors that were found during Javadoc generation. Possibly following a similar pattern to the argfile and options that are generated containing parameters passed to Javadoc create an errors files that will be placed in the Javadoc output folder that is ignored during Javadoc JAR creation. This change would allow for CI systems to run Javadoc builds in parallel while still easily capturing any errors without the need for complex logging systems and would strongly ensure that there is a unique error report for each project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-670) Remove code duplication in XdocSink
[
https://issues.apache.org/jira/browse/DOXIA-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17576019#comment-17576019
]
ASF GitHub Bot commented on DOXIA-670:
--
michael-o commented on code in PR #116:
URL: https://github.com/apache/maven-doxia/pull/116#discussion_r939155456
##
doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocSink.java:
##
@@ -382,119 +377,6 @@ else if ( depth == SECTION_LEVEL_5 )
//
// ---
-/**
- * {@inheritDoc}
- *
- * @see XdocMarkup#SOURCE_TAG
- * @see javax.swing.text.html.HTML.Tag#PRE
- * @param attributes a {@link
org.apache.maven.doxia.sink.SinkEventAttributes} object.
- */
-public void verbatim( SinkEventAttributes attributes )
-{
Review Comment:
I think this statement is nonsense and this method needs to be retained:
* Xdoc uses element of HTML5, but is not HTML5
* When XdocParser writes to a sink that sink will never see ``
anymore.
We have here a mix of custom elements and HTML5.
> Remove code duplication in XdocSink
> ---
>
> Key: DOXIA-670
> URL: https://issues.apache.org/jira/browse/DOXIA-670
> Project: Maven Doxia
> Issue Type: Task
> Components: Module - Xhtml
>Affects Versions: 2.0.0-M3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M4
>
>
> {{XdocSink}} duplicates code from the parent class. That code can be removed.
> It has one caveat: The {{source}} element cannot be retained at all because
> it has a completely different meaning in HTML5:
> https://www.tutorialrepublic.com/html-reference/html5-source-tag.php and
> since only the {{XHTML5Parser}} can properly detect the new construct
> {{verbatim(boxed)}} will always be parsed as unboxed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] michael-o commented on a diff in pull request #116: [DOXIA-670] Remove code duplication in XdocSink
michael-o commented on code in PR #116:
URL: https://github.com/apache/maven-doxia/pull/116#discussion_r939155456
##
doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocSink.java:
##
@@ -382,119 +377,6 @@ else if ( depth == SECTION_LEVEL_5 )
//
// ---
-/**
- * {@inheritDoc}
- *
- * @see XdocMarkup#SOURCE_TAG
- * @see javax.swing.text.html.HTML.Tag#PRE
- * @param attributes a {@link
org.apache.maven.doxia.sink.SinkEventAttributes} object.
- */
-public void verbatim( SinkEventAttributes attributes )
-{
Review Comment:
I think this statement is nonsense and this method needs to be retained:
* Xdoc uses element of HTML5, but is not HTML5
* When XdocParser writes to a sink that sink will never see ``
anymore.
We have here a mix of custom elements and HTML5.
--
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] (DOXIA-670) Remove code duplication in XdocSink
[
https://issues.apache.org/jira/browse/DOXIA-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575985#comment-17575985
]
ASF GitHub Bot commented on DOXIA-670:
--
michael-o commented on code in PR #116:
URL: https://github.com/apache/maven-doxia/pull/116#discussion_r939037143
##
doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocSink.java:
##
@@ -382,119 +377,6 @@ else if ( depth == SECTION_LEVEL_5 )
//
// ---
-/**
- * {@inheritDoc}
- *
- * @see XdocMarkup#SOURCE_TAG
- * @see javax.swing.text.html.HTML.Tag#PRE
- * @param attributes a {@link
org.apache.maven.doxia.sink.SinkEventAttributes} object.
- */
-public void verbatim( SinkEventAttributes attributes )
-{
Review Comment:
I don't have a better idea how to make it proper, but it is definitively
broken with XHML5.
> Remove code duplication in XdocSink
> ---
>
> Key: DOXIA-670
> URL: https://issues.apache.org/jira/browse/DOXIA-670
> Project: Maven Doxia
> Issue Type: Task
> Components: Module - Xhtml
>Affects Versions: 2.0.0-M3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M4
>
>
> {{XdocSink}} duplicates code from the parent class. That code can be removed.
> It has one caveat: The {{source}} element cannot be retained at all because
> it has a completely different meaning in HTML5:
> https://www.tutorialrepublic.com/html-reference/html5-source-tag.php and
> since only the {{XHTML5Parser}} can properly detect the new construct
> {{verbatim(boxed)}} will always be parsed as unboxed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] michael-o commented on a diff in pull request #116: [DOXIA-670] Remove code duplication in XdocSink
michael-o commented on code in PR #116:
URL: https://github.com/apache/maven-doxia/pull/116#discussion_r939037143
##
doxia-modules/doxia-module-xdoc/src/main/java/org/apache/maven/doxia/module/xdoc/XdocSink.java:
##
@@ -382,119 +377,6 @@ else if ( depth == SECTION_LEVEL_5 )
//
// ---
-/**
- * {@inheritDoc}
- *
- * @see XdocMarkup#SOURCE_TAG
- * @see javax.swing.text.html.HTML.Tag#PRE
- * @param attributes a {@link
org.apache.maven.doxia.sink.SinkEventAttributes} object.
- */
-public void verbatim( SinkEventAttributes attributes )
-{
Review Comment:
I don't have a better idea how to make it proper, but it is definitively
broken with XHML5.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-dependency-plugin] michael-o commented on a diff in pull request #233: [MDEP-782] - Add ability to strip type
michael-o commented on code in PR #233: URL: https://github.com/apache/maven-dependency-plugin/pull/233#discussion_r939016719 ## pom.xml: ## @@ -30,7 +30,7 @@ under the License. maven-dependency-plugin - 3.3.1-SNAPSHOT + 3.3.2-SNAPSHOT Review Comment: Why? -- 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-site] michael-o merged pull request #317: Add predictive test selection to Gradle Enterprise Maven extension
michael-o merged PR #317: URL: https://github.com/apache/maven-site/pull/317 -- 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-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575849#comment-17575849
]
ASF GitHub Bot commented on MNG-7098:
-
MartinKanters opened a new pull request, #783:
URL: https://github.com/apache/maven/pull/783
This PR ensures that when a multi module project is resumed halfway, the
project progress counter is not reset.
[Related issue](https://issues.apache.org/jira/browse/MNG-7098).
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/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to
use the JIRA issue
title in the pull request title and in the first line of the commit
message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be 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).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] MartinKanters opened a new pull request, #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
MartinKanters opened a new pull request, #783: URL: https://github.com/apache/maven/pull/783 This PR ensures that when a multi module project is resumed halfway, the project progress counter is not reset. [Related issue](https://issues.apache.org/jira/browse/MNG-7098). 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/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be 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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] slawekjaranowski commented on pull request #65: Bump maven-site-plugin from 3.12.0 to 3.12.1
slawekjaranowski commented on PR #65: URL: https://github.com/apache/maven-jxr/pull/65#issuecomment-1206347891 @michael-o can you look at IT tests build result ... ``` An issue has occurred with maven-javadoc-plugin:3.4.0:aggregate report, skipping LinkageError Receiver class org.apache.maven.plugins.javadoc.AggregatorJavadocReport does not define or inherit an implementation of the resolved method 'abstract void generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface org.apache.maven.reporting.MavenReport., please report an issue to Maven dev team. java.lang.AbstractMethodError: Receiver class org.apache.maven.plugins.javadoc.AggregatorJavadocReport does not define or inherit an implementation of the resolved method 'abstract void generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface org.apache.maven.reporting.MavenReport. ``` -- 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] (MCHECKSTYLE-416) Release Version 3.2 on Master
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575695#comment-17575695 ] James commented on MCHECKSTYLE-416: --- Thanks for the commentary, Michael. I've added a comment over on 398 to ask whether it will be resolved soon or perhaps whether that ticket could target a later release and hence unblock 3.2 being released. https://issues.apache.org/jira/browse/MCHECKSTYLE-398?focusedCommentId=17575694=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17575694 > Release Version 3.2 on Master > - > > Key: MCHECKSTYLE-416 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-416 > Project: Maven Checkstyle Plugin > Issue Type: Wish >Reporter: James >Priority: Minor > > Hi! Sorry for the ticket, please do feel free to resolve this immediately if > it's not appropriate here (I couldn't work out another way to ask this > question other than via Jira). > We see that 3.2-SNAPSHOT is sat there on master. That uses version 9.3 of > the Checkstyle library which appears to contain Java 17 support. > We're wondering when 3.2 will be released (along with the Java 17 support > we're looking for)? Is there a rough estimate for that or it's impossible to > know at this point? > We can always work around it using > [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html] > but we'd like to stay on a default configuration if we can hence this > request/question. Getting a feeling for the release date allows us to plan > appropriately. > Really appreciate any guidance/information you have here and please do feel > free to resolve this ticket immediately if it's not appropriate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCHECKSTYLE-398) suppressions inside JAR, non-absolute path, cannot be found
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575694#comment-17575694
]
James commented on MCHECKSTYLE-398:
---
Hi! This ticket is blocking
https://issues.apache.org/jira/browse/MCHECKSTYLE-416 (release of plugin
version 3.2). Is this ticket likely to go soon? Perhaps it's able to target a
later release after 3.2 and hence allow that out of the door?
> suppressions inside JAR, non-absolute path, cannot be found
> ---
>
> Key: MCHECKSTYLE-398
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-398
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 3.1.1
>Reporter: CHAN Shih-Ping
>Priority: Major
> Fix For: 3.2.0
>
>
> When the configuration file and suppressions XML file are inside a JAR, then
> if the configuration file references the suppressions file with a
> non-absolute path, the suppressions file cannot be located.
>
> wildfly-checkstyle-config:1.0.8.Final is a plugin dependency of
> maven-checkstyle-plugin:3.1.1, containing both
> {{wildfly-checkstyle/checkstyle.xml}} and
> {{wildfly-checkstyle/suppressions.xml
>
> {code:java}
> # inside checkstyle.xml we reference suppressions.xml with a absolute path
> # this doesn't work if the path is changed to non-absolute
> # wildfly-checkstyle/suppressions.xml, but both absolute/non-absolute
> reference
> # work in checkstyle-all.jar
>
>
> {code}
> The configuration file is {{wildfly-checkstyle/checkstyle.xml}} inside the
> JAR.
> Standard Maven project:
> {code:xml}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 3.1.1
>
> wildfly-checkstyle/checkstyle.xml
> true
>
> ${project.build.sourceDirectory}
>
> **/*.properties,**/*.xml
> true
> true
> true
> true
> true
> samedir=/wildfly-checkstyle/
>
>
>
> org.wildfly.checkstyle
> wildfly-checkstyle-config
> 1.0.8.Final
>
>
> com.puppycrawl.tools
> checkstyle
> 8.36.2
>
>
> {code}
> This configuraton works but if the reference to suppressions is non-absolute:
> {{wildfly-checkstyle/suppressions.xml}}, then
> {code:java}
> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot
> initialize module SuppressionFilter - Unable to find:
> wildfly-checkstyle/suppressions.xml
> at com.puppycrawl.tools.checkstyle.Checker.setupChild (Checker.java:482)
> at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure
> (AutomaticBean.java:201)
> at
> org.apache.maven.plugins.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle
> (DefaultCheckstyleExecutor.java:168)
> at
> org.apache.maven.plugins.checkstyle.AbstractCheckstyleReport.executeReport
> (AbstractCheckstyleReport.java:533)
> at org.apache.maven.plugins.checkstyle.CheckstyleReport.executeReport
> (CheckstyleReport.java:57)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:255)
> at org.apache.maven.reporting.AbstractMavenReport.execute
> (AbstractMavenReport.java:143)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> {code}
> Using checkstyle-8.36.2-all.jar on the command line works whether the path
> reference has the leading {{'/'}} or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCHECKSTYLE-416) Release Version 3.2 on Master
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575680#comment-17575680 ] Michael Osipov commented on MCHECKSTYLE-416: This one is still open: MCHECKSTYLE-398. If this one is resolved I could do likely the technical release. Also one needs to check for open PR whether they are trivial to merge. > Release Version 3.2 on Master > - > > Key: MCHECKSTYLE-416 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-416 > Project: Maven Checkstyle Plugin > Issue Type: Wish >Reporter: James >Priority: Minor > > Hi! Sorry for the ticket, please do feel free to resolve this immediately if > it's not appropriate here (I couldn't work out another way to ask this > question other than via Jira). > We see that 3.2-SNAPSHOT is sat there on master. That uses version 9.3 of > the Checkstyle library which appears to contain Java 17 support. > We're wondering when 3.2 will be released (along with the Java 17 support > we're looking for)? Is there a rough estimate for that or it's impossible to > know at this point? > We can always work around it using > [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html] > but we'd like to stay on a default configuration if we can hence this > request/question. Getting a feeling for the release date allows us to plan > appropriately. > Really appreciate any guidance/information you have here and please do feel > free to resolve this ticket immediately if it's not appropriate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-416) Release Version 3.2 on Master
James created MCHECKSTYLE-416: - Summary: Release Version 3.2 on Master Key: MCHECKSTYLE-416 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-416 Project: Maven Checkstyle Plugin Issue Type: Wish Reporter: James Hi! Sorry for the ticket, please do feel free to resolve this immediately if it's not appropriate here (I couldn't work out another way to ask this question other than via Jira). We see that 3.2-SNAPSHOT is sat there on master. That uses version 9.3 of the Checkstyle library which appears to contain Java 17 support. We're wondering when 3.2 will be released (along with the Java 17 support we're looking for)? Is there a rough estimate for that or it's impossible to know at this point? We can always work around it using [https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html] but we'd like to stay on a default configuration if we can hence this request/question. Getting a feeling for the release date allows us to plan appropriately. Really appreciate any guidance/information you have here and please do feel free to resolve this ticket immediately if it's not appropriate. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] MartinKanters commented on a diff in pull request #131: [MNG-7310] Add a test for MNG-7310
MartinKanters commented on code in PR #131:
URL:
https://github.com/apache/maven-integration-testing/pull/131#discussion_r938633667
##
core-it-suite/src/test/resources/mng-7310-lifecycle-activated-in-specified-module/extension/pom.xml:
##
@@ -0,0 +1,111 @@
+
+
+
+
+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
+
+ mng-7310-lifecycle-activated-in-specified-module
+ mng-7310-lifecycle-activated-in-specified-module
+ 0.1
+
+ maven-plugin
+
+
+3.2.1
Review Comment:
Done
##
core-it-suite/src/test/resources/mng-7310-lifecycle-activated-in-specified-module/extension/pom.xml:
##
@@ -0,0 +1,111 @@
+
+
+
+
+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
+
+ mng-7310-lifecycle-activated-in-specified-module
+ mng-7310-lifecycle-activated-in-specified-module
+ 0.1
+
+ maven-plugin
+
+
+3.2.1
+1.8
+1.8
+
+
+
+
+ org.apache.maven
+ maven-core
+ ${maven.version}
+ provided
+
+
+ org.apache.maven.plugin-tools
+ maven-plugin-annotations
+ 3.2
+ provided
+
+
+ org.apache.maven
+ maven-plugin-api
+ 2.0
Review Comment:
Made it consistent
--
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] (MPIR-423) dependencies goal doesn't create required resources
[
https://issues.apache.org/jira/browse/MPIR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-423:
Fix Version/s: 3.4.1
> dependencies goal doesn't create required resources
> ---
>
> Key: MPIR-423
> URL: https://issues.apache.org/jira/browse/MPIR-423
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.8.6
> maven-project-info-reports-plugin 3.4.0
>Reporter: AB-xdev
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.4.1
>
> Attachments: image-2022-08-05-10-17-51-809.png
>
>
> This problem occurs since {{3.4.0}};
> {{3.3.x}} seems to work fine.
> When running the {{dependencies}}-goal most css and images resources are
> missing.
> Example:
> https://xdev-software.github.io/vaadin-grid-exporter/dependencies/
> !image-2022-08-05-10-17-51-809.png!
> How to reproduce:
> * Create a new maven project {{mvn archetype:generate
> -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false}}
> * Enter the project {{cd my-app}}
> * Run {{mvn
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
> * Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPIR-423) dependencies goal doesn't create required resources
[
https://issues.apache.org/jira/browse/MPIR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575665#comment-17575665
]
Michael Osipov commented on MPIR-423:
-
I can confirm that standalone execution is broken by MPIR-422. I will take care
of that. Thanks for the report. I was totally focused on maven-site-plugin
execution.
> dependencies goal doesn't create required resources
> ---
>
> Key: MPIR-423
> URL: https://issues.apache.org/jira/browse/MPIR-423
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.8.6
> maven-project-info-reports-plugin 3.4.0
>Reporter: AB-xdev
>Priority: Major
> Attachments: image-2022-08-05-10-17-51-809.png
>
>
> This problem occurs since {{3.4.0}};
> {{3.3.x}} seems to work fine.
> When running the {{dependencies}}-goal most css and images resources are
> missing.
> Example:
> https://xdev-software.github.io/vaadin-grid-exporter/dependencies/
> !image-2022-08-05-10-17-51-809.png!
> How to reproduce:
> * Create a new maven project {{mvn archetype:generate
> -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false}}
> * Enter the project {{cd my-app}}
> * Run {{mvn
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
> * Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPIR-423) dependencies goal doesn't create required resources
[
https://issues.apache.org/jira/browse/MPIR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-423:
---
Assignee: Michael Osipov
> dependencies goal doesn't create required resources
> ---
>
> Key: MPIR-423
> URL: https://issues.apache.org/jira/browse/MPIR-423
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.8.6
> maven-project-info-reports-plugin 3.4.0
>Reporter: AB-xdev
>Assignee: Michael Osipov
>Priority: Major
> Attachments: image-2022-08-05-10-17-51-809.png
>
>
> This problem occurs since {{3.4.0}};
> {{3.3.x}} seems to work fine.
> When running the {{dependencies}}-goal most css and images resources are
> missing.
> Example:
> https://xdev-software.github.io/vaadin-grid-exporter/dependencies/
> !image-2022-08-05-10-17-51-809.png!
> How to reproduce:
> * Create a new maven project {{mvn archetype:generate
> -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false}}
> * Enter the project {{cd my-app}}
> * Run {{mvn
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
> * Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPIR-423) dependencies goal doesn't create required resources
[
https://issues.apache.org/jira/browse/MPIR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AB-xdev updated MPIR-423:
-
Description:
This problem occurs since {{3.4.0}};
{{3.3.x}} seems to work fine.
When running the {{dependencies}}-goal most css and images resources are
missing.
Example:
https://xdev-software.github.io/vaadin-grid-exporter/dependencies/
!image-2022-08-05-10-17-51-809.png!
How to reproduce:
* Create a new maven project {{mvn archetype:generate
-DgroupId=com.mycompany.app -DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DinteractiveMode=false}}
* Enter the project {{cd my-app}}
* Run {{mvn
org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
* Open {{target/site/dependencies.html}}
was:
This problem occurs since {{3.4.0}}, {{3.3.x}} seems to work fine.
When running the {{dependencies}}-goal most css and images resources are
missing.
Example:
!image-2022-08-05-10-17-51-809.png!
How to reproduce:
* Create a new maven project {{mvn archetype:generate
-DgroupId=com.mycompany.app -DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DinteractiveMode=false}}
* Enter the project {{cd my-app}}
* Run {{mvn
org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
* Open {{target/site/dependencies.html}}
> dependencies goal doesn't create required resources
> ---
>
> Key: MPIR-423
> URL: https://issues.apache.org/jira/browse/MPIR-423
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.8.6
> maven-project-info-reports-plugin 3.4.0
>Reporter: AB-xdev
>Priority: Major
> Attachments: image-2022-08-05-10-17-51-809.png
>
>
> This problem occurs since {{3.4.0}};
> {{3.3.x}} seems to work fine.
> When running the {{dependencies}}-goal most css and images resources are
> missing.
> Example:
> https://xdev-software.github.io/vaadin-grid-exporter/dependencies/
> !image-2022-08-05-10-17-51-809.png!
> How to reproduce:
> * Create a new maven project {{mvn archetype:generate
> -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false}}
> * Enter the project {{cd my-app}}
> * Run {{mvn
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
> * Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPIR-423) dependencies goal doesn't create required resources
[
https://issues.apache.org/jira/browse/MPIR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575661#comment-17575661
]
Michael Osipov commented on MPIR-423:
-
I have the feeling that I know the reason...let me verify this one first...
> dependencies goal doesn't create required resources
> ---
>
> Key: MPIR-423
> URL: https://issues.apache.org/jira/browse/MPIR-423
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 3.4.0
> Environment: Apache Maven 3.8.6
> maven-project-info-reports-plugin 3.4.0
>Reporter: AB-xdev
>Priority: Major
> Attachments: image-2022-08-05-10-17-51-809.png
>
>
> This problem occurs since {{3.4.0}}, {{3.3.x}} seems to work fine.
> When running the {{dependencies}}-goal most css and images resources are
> missing.
> Example:
> !image-2022-08-05-10-17-51-809.png!
> How to reproduce:
> * Create a new maven project {{mvn archetype:generate
> -DgroupId=com.mycompany.app -DartifactId=my-app
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
> -DinteractiveMode=false}}
> * Enter the project {{cd my-app}}
> * Run {{mvn
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
> * Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-integration-testing] michael-o commented on a diff in pull request #131: [MNG-7310] Add a test for MNG-7310
michael-o commented on code in PR #131:
URL:
https://github.com/apache/maven-integration-testing/pull/131#discussion_r938572449
##
core-it-suite/src/test/resources/mng-7310-lifecycle-activated-in-specified-module/extension/pom.xml:
##
@@ -0,0 +1,111 @@
+
+
+
+
+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
+
+ mng-7310-lifecycle-activated-in-specified-module
+ mng-7310-lifecycle-activated-in-specified-module
+ 0.1
+
+ maven-plugin
+
+
+3.2.1
Review Comment:
No, this is hiding the actual `maven.version` property. Please always use
`mavenVersion`.
##
core-it-suite/src/test/resources/mng-7310-lifecycle-activated-in-specified-module/extension/pom.xml:
##
@@ -0,0 +1,111 @@
+
+
+
+
+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
+
+ mng-7310-lifecycle-activated-in-specified-module
+ mng-7310-lifecycle-activated-in-specified-module
+ 0.1
+
+ maven-plugin
+
+
+3.2.1
+1.8
+1.8
+
+
+
+
+ org.apache.maven
+ maven-core
+ ${maven.version}
+ provided
+
+
+ org.apache.maven.plugin-tools
+ maven-plugin-annotations
+ 3.2
+ provided
+
+
+ org.apache.maven
+ maven-plugin-api
+ 2.0
Review Comment:
Should be consistent with the Maven version
--
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] (MPIR-423) dependencies goal doesn't create required resources
AB-xdev created MPIR-423:
Summary: dependencies goal doesn't create required resources
Key: MPIR-423
URL: https://issues.apache.org/jira/browse/MPIR-423
Project: Maven Project Info Reports Plugin
Issue Type: Bug
Components: dependencies
Affects Versions: 3.4.0
Environment: Apache Maven 3.8.6
maven-project-info-reports-plugin 3.4.0
Reporter: AB-xdev
Attachments: image-2022-08-05-10-17-51-809.png
This problem occurs since {{3.4.0}}, {{3.3.x}} seems to work fine.
When running the {{dependencies}}-goal most css and images resources are
missing.
Example:
!image-2022-08-05-10-17-51-809.png!
How to reproduce:
* Create a new maven project {{mvn archetype:generate
-DgroupId=com.mycompany.app -DartifactId=my-app
-DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4
-DinteractiveMode=false}}
* Enter the project {{cd my-app}}
* Run {{mvn
org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.0:dependencies}}
* Open {{target/site/dependencies.html}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575639#comment-17575639
]
ASF GitHub Bot commented on MNG-7310:
-
michael-o commented on code in PR #639:
URL: https://github.com/apache/maven/pull/639#discussion_r938569898
##
maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycles.java:
##
@@ -139,13 +138,34 @@ public List getLifeCycles()
}
};
+Map lifecyclesMap = lookupLifecycleMap();
+
// ensure canonical order of standard lifecycles
return lifecyclesMap.values().stream()
.peek( l -> Objects.requireNonNull( l.getId(),
"A lifecycle must have an id." ) )
.sorted( Comparator.comparing(
Lifecycle::getId, comparator ) )
.collect( Collectors.toList() );
}
+private Map lookupLifecycleMap()
+{
+// This code is here to ensure maven-compat's EmptyLifecycleExecutor
keeps on working.
+if ( plexusContainer == null )
+{
+return new HashMap<>();
+}
+
+// Lifecycles cannot be cached as extensions might add custom
lifecycles later in the execution.
+try
+{
+return plexusContainer.lookupMap( Lifecycle.class );
+}
+catch ( ComponentLookupException e )
+{
+throw new RuntimeException( "Unable to lookup lifecycles from the
plexus container", e );
Review Comment:
Would an `IllegalStateException` better here?
##
maven-core/src/test/java/org/apache/maven/lifecycle/DefaultLifecyclesTest.java:
##
@@ -81,7 +86,7 @@ public void testWrapperLifecycle()
}
@Test
-public void testCustomLifecycle()
+public void testCustomLifecycle() throws ComponentLookupException
Review Comment:
Should be a new line if it is in the other test of this changeset
##
maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/DefaultLifecyclesStub.java:
##
@@ -25,15 +27,16 @@
import java.util.Map;
import static
org.apache.maven.lifecycle.internal.stub.LifecycleExecutionPlanCalculatorStub.*;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
/**
* @author Kristian Rosenvold
*/
public class DefaultLifecyclesStub
{
-public static DefaultLifecycles createDefaultLifecycles()
-{
+public static DefaultLifecycles createDefaultLifecycles() throws
ComponentLookupException {
Review Comment:
Same here
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #639: [MNG-7310] Using the plexusContainer to prevent loading lifecycle defined by extensions from other submodules.
michael-o commented on code in PR #639:
URL: https://github.com/apache/maven/pull/639#discussion_r938569898
##
maven-core/src/main/java/org/apache/maven/lifecycle/DefaultLifecycles.java:
##
@@ -139,13 +138,34 @@ public List getLifeCycles()
}
};
+Map lifecyclesMap = lookupLifecycleMap();
+
// ensure canonical order of standard lifecycles
return lifecyclesMap.values().stream()
.peek( l -> Objects.requireNonNull( l.getId(),
"A lifecycle must have an id." ) )
.sorted( Comparator.comparing(
Lifecycle::getId, comparator ) )
.collect( Collectors.toList() );
}
+private Map lookupLifecycleMap()
+{
+// This code is here to ensure maven-compat's EmptyLifecycleExecutor
keeps on working.
+if ( plexusContainer == null )
+{
+return new HashMap<>();
+}
+
+// Lifecycles cannot be cached as extensions might add custom
lifecycles later in the execution.
+try
+{
+return plexusContainer.lookupMap( Lifecycle.class );
+}
+catch ( ComponentLookupException e )
+{
+throw new RuntimeException( "Unable to lookup lifecycles from the
plexus container", e );
Review Comment:
Would an `IllegalStateException` better here?
##
maven-core/src/test/java/org/apache/maven/lifecycle/DefaultLifecyclesTest.java:
##
@@ -81,7 +86,7 @@ public void testWrapperLifecycle()
}
@Test
-public void testCustomLifecycle()
+public void testCustomLifecycle() throws ComponentLookupException
Review Comment:
Should be a new line if it is in the other test of this changeset
##
maven-core/src/test/java/org/apache/maven/lifecycle/internal/stub/DefaultLifecyclesStub.java:
##
@@ -25,15 +27,16 @@
import java.util.Map;
import static
org.apache.maven.lifecycle.internal.stub.LifecycleExecutionPlanCalculatorStub.*;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
/**
* @author Kristian Rosenvold
*/
public class DefaultLifecyclesStub
{
-public static DefaultLifecycles createDefaultLifecycles()
-{
+public static DefaultLifecycles createDefaultLifecycles() throws
ComponentLookupException {
Review Comment:
Same 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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIA-670) Remove code duplication in XdocSink
[
https://issues.apache.org/jira/browse/DOXIA-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575625#comment-17575625
]
ASF GitHub Bot commented on DOXIA-670:
--
michael-o commented on PR #116:
URL: https://github.com/apache/maven-doxia/pull/116#issuecomment-1206155487
Note: This change requires to drop:
https://github.com/apache/maven-doxia/blob/3b1499d0572718fa4dcb7c6b775bedbe757d46c5/doxia-modules/doxia-module-xdoc/src/main/resources/xdoc-2.0.xsd#L2923-L2935
and release a new version. Alternatively, we'd translate source to `...`
> Remove code duplication in XdocSink
> ---
>
> Key: DOXIA-670
> URL: https://issues.apache.org/jira/browse/DOXIA-670
> Project: Maven Doxia
> Issue Type: Task
> Components: Module - Xhtml
>Affects Versions: 2.0.0-M3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M4
>
>
> {{XdocSink}} duplicates code from the parent class. That code can be removed.
> It has one caveat: The {{source}} element cannot be retained at all because
> it has a completely different meaning in HTML5:
> https://www.tutorialrepublic.com/html-reference/html5-source-tag.php and
> since only the {{XHTML5Parser}} can properly detect the new construct
> {{verbatim(boxed)}} will always be parsed as unboxed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] michael-o commented on pull request #116: [DOXIA-670] Remove code duplication in XdocSink
michael-o commented on PR #116: URL: https://github.com/apache/maven-doxia/pull/116#issuecomment-1206155487 Note: This change requires to drop: https://github.com/apache/maven-doxia/blob/3b1499d0572718fa4dcb7c6b775bedbe757d46c5/doxia-modules/doxia-module-xdoc/src/main/resources/xdoc-2.0.xsd#L2923-L2935 and release a new version. Alternatively, we'd translate source to `...` -- 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] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6268 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6268/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-782) Add a option to unpack goals
[
https://issues.apache.org/jira/browse/MDEP-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575615#comment-17575615
]
Jasper Kamerling commented on MDEP-782:
---
I could also really use this functionality.
I went out and created the pull request for this: [[MDEP-782] - Add ability to
strip type by scramados · Pull Request #233 · apache/maven-dependency-plugin
(github.com)|https://github.com/apache/maven-dependency-plugin/pull/233]
> Add a option to unpack goals
>
>
> Key: MDEP-782
> URL: https://issues.apache.org/jira/browse/MDEP-782
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: unpack-dependencies
>Affects Versions: 3.2.0
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
>Reporter: Andreas Sewe
>Priority: Major
>
> When using {{unpack-dependencies}} with
> {noformat}
> true
> true
> {noformat}
> dependencies will get unpacked in directories like
> {{{}${outputDirectory}/some-artifactId-{*}jar{*}/{}}}. In other words, the
> artifact's type is always appended; AFAICT from the
> [code|https://maven.apache.org/plugins/maven-dependency-plugin/xref/org/apache/maven/plugins/dependency/utils/DependencyUtil.html#L189],
> there is no way to unpack into a directory whose name is just the
> dependency's {{{}artifactId{}}}.
> It would hence be nice to have a {{}} configuration option to
> mirror
> [{{}}|https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html#stripVersion]
> and
> [{{}}|https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html#stripClassifier]
> (although the later option is also ignored on {{{}unpack-dependencies{}}}. A
> separate bug?).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-5728 #9 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5728/9/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build failed in Jenkins: Maven » Maven TLP » maven » MNG-6829 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: michael-o): Fixed with [95ee8908370744153531aa2e80a9bce93dc5d9bc|https://gitbox.apache.org/repos/asf?p=maven.git=commit=95ee8908370744153531aa2e80a9bce93dc5d9bc] and ITs with [10fd1f967dd95bf7b8451cec0a20fd88f55582c8|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git=commit=10fd1f967dd95bf7b8451cec0a20fd88f55582c8]. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6113 #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6113/3/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » master #65 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/65/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6888 #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6888/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6957 #12 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6957/12/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6552 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » master #64 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/64/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » master #66 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/66/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6054 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6054/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6114 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6114/2/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6909 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6909/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6952 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6952/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6550 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6554 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » Bananeweizen-MNG-6907 #16 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/Bananeweizen-MNG-6907/16/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven-studies » maven-metrics #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-studies/job/maven-metrics/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728 ] Robert Scholte deleted comment on MNG-5728: - was (Author: hudson): Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/15/ > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Nicolas Juneau >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0-alpha-1, 4.0.0 > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] scramados opened a new pull request, #233: [MDEP-782] - Add ability to strip type
scramados opened a new pull request, #233: URL: https://github.com/apache/maven-dependency-plugin/pull/233 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/MDEP) 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 `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-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. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] guylabs opened a new pull request, #317: Add predictive test selection to Gradle Enterprise Maven extension
guylabs opened a new pull request, #317: URL: https://github.com/apache/maven-site/pull/317 Adds the predictive test selection feature to the description of the Gradle Enterprise Maven extension. Second commit formats the file. -- 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
