[GitHub] [maven-clean-plugin] dependabot[bot] opened a new pull request, #30: Bump plexus-xml from 4.0.0 to 4.0.2
dependabot[bot] opened a new pull request, #30: URL: https://github.com/apache/maven-clean-plugin/pull/30 Bumps [plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 4.0.0 to 4.0.2. Release notes Sourced from https://github.com/codehaus-plexus/plexus-xml/releases;>plexus-xml's releases. Plexus XML 4.0.2 What's Changed Cleanup after parent pom upgrade by https://github.com/slachiewicz;>@slachiewicz in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) by https://github.com/gnodet;>@gnodet in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/23;>codehaus-plexus/plexus-xml#23 New Contributors https://github.com/slachiewicz;>@slachiewicz made their first contribution in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Full Changelog: https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2;>https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2 Commits https://github.com/codehaus-plexus/plexus-xml/commit/944197c74386b199857a003160d840fb5593ac29;>944197c [maven-release-plugin] prepare release plexus-xml-4.0.2 https://github.com/codehaus-plexus/plexus-xml/commit/c3d99b433a272d8eb1cc7c799410799e8c16ace3;>c3d99b4 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/23;>#23) https://github.com/codehaus-plexus/plexus-xml/commit/a83cefa086c9a5bb8b6674a409016f378b19891e;>a83cefa Cleanup after parent pom upgrade https://github.com/codehaus-plexus/plexus-xml/commit/25a00cd9d04ff3ab7acdcebdefdbb19ec5c4560d;>25a00cd [maven-release-plugin] prepare for next development iteration https://github.com/codehaus-plexus/plexus-xml/commit/bcb6981e2a9c635d024e0422de2a997a00ffdd8e;>bcb6981 [maven-release-plugin] prepare release plexus-xml-4.0.1 https://github.com/codehaus-plexus/plexus-xml/commit/d227a49f0f9b552a61b2aaac3bbe2c722ce06fea;>d227a49 Fix detection of invalid spaces in prolog (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/20;>#20) https://github.com/codehaus-plexus/plexus-xml/commit/27d6127d3196d09263d8fe0f445b9d83f6ccfb75;>27d6127 pom.mxl and site.xml cleanup https://github.com/codehaus-plexus/plexus-xml/commit/62f50bc46c7b51d51a25541dfe0a502063dc1fc3;>62f50bc [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.0...plexus-xml-4.0.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [maven-parent] dependabot[bot] closed pull request #131: Bump plexus-xml from 4.0.0 to 4.0.1
dependabot[bot] closed pull request #131: Bump plexus-xml from 4.0.0 to 4.0.1 URL: https://github.com/apache/maven-parent/pull/131 -- 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-parent] dependabot[bot] commented on pull request #131: Bump plexus-xml from 4.0.0 to 4.0.1
dependabot[bot] commented on PR #131: URL: https://github.com/apache/maven-parent/pull/131#issuecomment-1621021373 Superseded by #132. -- 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-parent] dependabot[bot] opened a new pull request, #132: Bump plexus-xml from 4.0.0 to 4.0.2
dependabot[bot] opened a new pull request, #132: URL: https://github.com/apache/maven-parent/pull/132 Bumps [plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 4.0.0 to 4.0.2. Release notes Sourced from https://github.com/codehaus-plexus/plexus-xml/releases;>plexus-xml's releases. Plexus XML 4.0.2 What's Changed Cleanup after parent pom upgrade by https://github.com/slachiewicz;>@slachiewicz in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) by https://github.com/gnodet;>@gnodet in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/23;>codehaus-plexus/plexus-xml#23 New Contributors https://github.com/slachiewicz;>@slachiewicz made their first contribution in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Full Changelog: https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2;>https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2 Commits https://github.com/codehaus-plexus/plexus-xml/commit/944197c74386b199857a003160d840fb5593ac29;>944197c [maven-release-plugin] prepare release plexus-xml-4.0.2 https://github.com/codehaus-plexus/plexus-xml/commit/c3d99b433a272d8eb1cc7c799410799e8c16ace3;>c3d99b4 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/23;>#23) https://github.com/codehaus-plexus/plexus-xml/commit/a83cefa086c9a5bb8b6674a409016f378b19891e;>a83cefa Cleanup after parent pom upgrade https://github.com/codehaus-plexus/plexus-xml/commit/25a00cd9d04ff3ab7acdcebdefdbb19ec5c4560d;>25a00cd [maven-release-plugin] prepare for next development iteration https://github.com/codehaus-plexus/plexus-xml/commit/bcb6981e2a9c635d024e0422de2a997a00ffdd8e;>bcb6981 [maven-release-plugin] prepare release plexus-xml-4.0.1 https://github.com/codehaus-plexus/plexus-xml/commit/d227a49f0f9b552a61b2aaac3bbe2c722ce06fea;>d227a49 Fix detection of invalid spaces in prolog (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/20;>#20) https://github.com/codehaus-plexus/plexus-xml/commit/27d6127d3196d09263d8fe0f445b9d83f6ccfb75;>27d6127 pom.mxl and site.xml cleanup https://github.com/codehaus-plexus/plexus-xml/commit/62f50bc46c7b51d51a25541dfe0a502063dc1fc3;>62f50bc [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.0...plexus-xml-4.0.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[jira] [Created] (MNG-7836) Support alternative syntaxes for POMs
Guillaume Nodet created MNG-7836: Summary: Support alternative syntaxes for POMs Key: MNG-7836 URL: https://issues.apache.org/jira/browse/MNG-7836 Project: Maven Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.x-candidate -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7834) NPE in flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MNG-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7834:
-
Fix Version/s: 4.0.0-alpha-8
> NPE in flatten-maven-plugin
> ---
>
> Key: MNG-7834
> URL: https://issues.apache.org/jira/browse/MNG-7834
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-8
>
>
> The flatten-maven-plugin fails with a NullPointerException:
> {code}[ERROR] Failed to execute goal
> org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on project
> camel: failed to create a clean pom: Cannot invoke "java.util.List.stream()"
> because "dependencies" is null -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on
> project camel: failed to create a clean pom
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:341)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:324)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:114)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1623)
> Caused by: org.apache.maven.plugin.MojoExecutionException: failed to create a
> clean pom
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:556)
> at org.codehaus.mojo.flatten.FlattenMojo.execute(FlattenMojo.java:406)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:336)
> ... 15 common frames omitted
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.util.List.stream()" because "dependencies" is null
> at org.apache.maven.model.ModelBase.setDependencies(ModelBase.java:164)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createCleanPom(FlattenMojo.java:686)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:554)
> ... 18 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7834) NPE in flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MNG-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7834:
Assignee: Guillaume Nodet
> NPE in flatten-maven-plugin
> ---
>
> Key: MNG-7834
> URL: https://issues.apache.org/jira/browse/MNG-7834
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The flatten-maven-plugin fails with a NullPointerException:
> {code}[ERROR] Failed to execute goal
> org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on project
> camel: failed to create a clean pom: Cannot invoke "java.util.List.stream()"
> because "dependencies" is null -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on
> project camel: failed to create a clean pom
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:341)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:324)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:114)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1623)
> Caused by: org.apache.maven.plugin.MojoExecutionException: failed to create a
> clean pom
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:556)
> at org.codehaus.mojo.flatten.FlattenMojo.execute(FlattenMojo.java:406)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:336)
> ... 15 common frames omitted
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.util.List.stream()" because "dependencies" is null
> at org.apache.maven.model.ModelBase.setDependencies(ModelBase.java:164)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createCleanPom(FlattenMojo.java:686)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:554)
> ... 18 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-checkstyle-plugin] boyarsky opened a new pull request, #124: (doc) fix typo in "ckecks"
boyarsky opened a new pull request, #124: URL: https://github.com/apache/maven-checkstyle-plugin/pull/124 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MCHECKSTYLE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MCHECKSTYLE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCHECKSTYLE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7828) Bump guava from 31.1-jre to 32.0.1-jre
[ https://issues.apache.org/jira/browse/MNG-7828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739985#comment-17739985 ] ASF GitHub Bot commented on MNG-7828: - ywluogg commented on PR #1191: URL: https://github.com/apache/maven/pull/1191#issuecomment-1620707074 I'm supporting some images built for Maven for some customers, and they still need 3.8.X, but we are requested to do a vulnerability patch for this. > Bump guava from 31.1-jre to 32.0.1-jre > -- > > Key: MNG-7828 > URL: https://issues.apache.org/jira/browse/MNG-7828 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.x-candidate, 4.0.x-candidate >Reporter: Bruno Candido Volpato da Cunha >Priority: Major > > Currently used version is in the range of CVE-2023-2976, which was fixed in > 32.0.0. > > Please check [https://osv.dev/vulnerability/GHSA-7g45-4rm6-3mm3] for more > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-488:
--
Description:
Similar to what SLF4J Logger (https://www.slf4j.org/api/org/slf4j/Logger.html)
and {{org.apache.maven.plugin.logging.Log}} provide, there should be a method
to determine if a certain log level is enabled. This is useful to put a guard
around costly evaluation methods which are only ever useful once a certain
level is active.
As switching log level is mostly done via -X command line a {{isDebugEnabled}}
should be sufficient though for most of the cases.
Using the supplier parameter does not always help e.g. when multiple debug
outputs should be surrounded by the same guard.
was:
Similar to what SLF4J Logger (https://www.slf4j.org/api/org/slf4j/Logger.html)
and {{org.apache.maven.plugin.logging.Log}} provide, there should be a method
to determine if a certain log level is enabled. This is useful to put a guard
around costly evaluation methods which are only ever useful once a certain
level is active.
As switching log level is mostly done via -X command line a {{isDebugEnabled}}
should be sufficient though for most of the cases.
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
> Using the supplier parameter does not always help e.g. when multiple debug
> outputs should be surrounded by the same guard.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739976#comment-17739976
]
ASF GitHub Bot commented on MENFORCER-488:
--
kwin opened a new pull request, #279:
URL: https://github.com/apache/maven-enforcer/pull/279
(no comment)
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MENFORCER-488:
-
Assignee: Konrad Windszus
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[
https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739975#comment-17739975
]
Jim Sellers commented on MNG-7705:
--
Using 3.9.3 this seems better, but I can still get it to fail on a clean repo
with 3 concurrent builds using the same gav lockfile setup. But now it's on a
resolver-status.properties file.
{code:title=stacktrace on failing resolver-status.properties}
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-apache-connector/maven-metadata.xml
(3.5 kB at 130 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/bundles/jaxrs-ri/maven-metadata.xml
(3.3 kB at 127 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-apache5-connector/maven-metadata.xml
(861 B at 32 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jdk-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jdk-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jetty-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jetty-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-helidon-connector/maven-metadata.xml
(1.0 kB at 48 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloaded from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-grizzly-connector/maven-metadata.xml
(4.1 kB at 145 kB/s)
build 28-Jun-2023 13:52:41[INFO] Downloading from asb-repository:
https://example.com/maven-proxy/content/groups/all-released/org/glassfish/jersey/connectors/jersey-jnh-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[INFO] Downloading from
asb-snapshot-repository:
https://example.com/maven-proxy/content/groups/all-snapshots/org/glassfish/jersey/connectors/jersey-jnh-connector/maven-metadata.xml
build 28-Jun-2023 13:52:41[WARNING] Failed to write tracking file
'/home/bamboo/.m2/repository/org/glassfish/jersey/connectors/jersey-grizzly-connector/resolver-status.properties'
build 28-Jun-2023 13:52:41java.io.IOException: Resource deadlock avoided
build 28-Jun-2023 13:52:41at sun.nio.ch.FileDispatcherImpl.lock0
(Native Method)
build 28-Jun-2023 13:52:41at sun.nio.ch.FileDispatcherImpl.lock
(FileDispatcherImpl.java:94)
build 28-Jun-2023 13:52:41at sun.nio.ch.FileChannelImpl.lock
(FileChannelImpl.java:1072)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultTrackingFileManager.fileLock
(DefaultTrackingFileManager.java:140)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
(DefaultTrackingFileManager.java:85)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write
(DefaultUpdateCheckManager.java:527)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchMetadata
(DefaultUpdateCheckManager.java:501)
build 28-Jun-2023 13:52:41at
org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
[jira] [Updated] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled()
[
https://issues.apache.org/jira/browse/MENFORCER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-488:
--
Summary: EnforcerLogger: Provide isDebugEnabled() (was: EnforcerLogger:
Provide isDebugEnabled)
> EnforcerLogger: Provide isDebugEnabled()
>
>
> Key: MENFORCER-488
> URL: https://issues.apache.org/jira/browse/MENFORCER-488
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Rule API
>Reporter: Konrad Windszus
>Priority: Major
>
> Similar to what SLF4J Logger
> (https://www.slf4j.org/api/org/slf4j/Logger.html) and
> {{org.apache.maven.plugin.logging.Log}} provide, there should be a method to
> determine if a certain log level is enabled. This is useful to put a guard
> around costly evaluation methods which are only ever useful once a certain
> level is active.
> As switching log level is mostly done via -X command line a
> {{isDebugEnabled}} should be sufficient though for most of the cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-488) EnforcerLogger: Provide isDebugEnabled
Konrad Windszus created MENFORCER-488:
-
Summary: EnforcerLogger: Provide isDebugEnabled
Key: MENFORCER-488
URL: https://issues.apache.org/jira/browse/MENFORCER-488
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: Rule API
Reporter: Konrad Windszus
Similar to what SLF4J Logger (https://www.slf4j.org/api/org/slf4j/Logger.html)
and {{org.apache.maven.plugin.logging.Log}} provide, there should be a method
to determine if a certain log level is enabled. This is useful to put a guard
around costly evaluation methods which are only ever useful once a certain
level is active.
As switching log level is mostly done via -X command line a {{isDebugEnabled}}
should be sufficient though for most of the cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7733) maven4 user settings mirrorOf-external:* does not override global settings external:http:*
[
https://issues.apache.org/jira/browse/MNG-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739972#comment-17739972
]
Jim Sellers commented on MNG-7733:
--
Hi [~gnodet]
I checked the nightly 4.0.0-alpha-6-SNAPSHOT and it seems to resolve it for me
without needing to change from the mirrorOf * setup that I had.
This seems better for me, thanks!
> maven4 user settings mirrorOf-external:* does not override global settings
> external:http:*
> ---
>
> Key: MNG-7733
> URL: https://issues.apache.org/jira/browse/MNG-7733
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-4
>Reporter: James Nord
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: regresion
>
> I have a settings file in my home directory (~/.m2/settings.xml) that works
> fine with maven 3.x (including 3.9.0)
> containing
> {code}
>
>
> myco-internal
> external:*
> https://nexus-cache.mycorp.com/content/groups/staged
>
>
> {code}
> with maven 4.0.0-alpha4 when building a project it will fail in dependency
> resolution due to the `maven-default-http-blocker` mirror.
> {noformat}
> unable to create flattened dependencies: caught exception when flattening
> dependencies: Failed to read artifact descriptor for
> javax.servlet:javax.servlet-api::3.1.0: Could not transfer artifact
> net.java:jvnet-parent:pom:3 from/to maven-default-http-blocker
> (http://0.0.0.0/): Blocked mirror for repositories: [glassfish-repository
> (http://download.java.net/maven/glassfish, default, releases+snapshots)] -
> {noformat}
> However I expect that my user settings should override global settings.
> as {{external:\*}} used in my local settings should also match anything that
> is matched by {{external:http:\*}} in the global settings I would not expect
> that the global settings mirror would be used.
> However this is infact the case.
> if I use --global-settings to specify my local settings file then the builds
> work
> Additionally changing my mirror defintion to be
> {{external:\*,external:http:\*}} still does not work
> initial output from {{mvn -x install}}
> {noformat}
> [DEBUG] Reading global settings from
> 'c:\java\maven-4.0.0-alpha-4\conf\settings.xml'
> [DEBUG] Reading user settings from 'C:\Users\me\.m2\settings.xml'
> [DEBUG] Created adapter factory; available factories [file-lock,
> rwlock-local, semaphore-local, noop]; available name mappers [discriminating,
> file-gav, file-hgav, gav, static]
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> C:\Users\me\.m2\repository
> [DEBUG] Creating adapter using nameMapper 'gav' and factory 'rwlock-local'
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for central
> (https://repo.maven.apache.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> apache.snapshots (http://repository.apache.org/snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for apache.snapshots
> (https://repository.apache.org/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> codehaus.snapshots (http://snapshots.repository.codehaus.org).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> repository.jboss.org (http://repository.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> snapshots.jboss.org (http://snapshots.jboss.org/maven2).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
> oss.sonatype.org/jboss-snapshots
> (http://oss.sonatype.org/content/repositories/jboss-snapshots).
> [DEBUG] Using mirror myco-internal
> (https://nexus-cache.mycorp.com/content/groups/staged) for jgit-repository
> (https://repo.eclipse.org/content/repositories/jgit-releases/).
> [DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for spy
> (http://files.couchbase.com/maven2/).
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] kwin opened a new pull request, #278: Clarify availability of AbstractEnforcerRule
kwin opened a new pull request, #278: URL: https://github.com/apache/maven-enforcer/pull/278 Improve links to javadoc Fix some typos -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-361) Unreliable TCP and retries on upload and download
[ https://issues.apache.org/jira/browse/MRESOLVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739966#comment-17739966 ] Konrad Windszus commented on MRESOLVER-361: --- FTR: This should also improve retry handling for GET as the default retry handler was switched to https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/client/StandardHttpRequestRetryHandler.html which retries also GET requests. > Unreliable TCP and retries on upload and download > - > > Key: MRESOLVER-361 > URL: https://issues.apache.org/jira/browse/MRESOLVER-361 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Two issues reported: > * PUT on closed connection is not retried. Suggested fix: change retry > handler to one that treats PUT as idempotent. > * -Oddity with 1 vs 2+ checksum algorithm used, in first case checksum > upload failure fails whole build, in second it only warns.- This proved > wrong, user build failed as metadata (so "main" payload not checksum of the > main payload) failed due HTTP connection error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-361) Unreliable TCP and retries on upload and download
[ https://issues.apache.org/jira/browse/MRESOLVER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MRESOLVER-361: -- Summary: Unreliable TCP and retries on upload and download (was: Unreliable TCP and retries on upload) > Unreliable TCP and retries on upload and download > - > > Key: MRESOLVER-361 > URL: https://issues.apache.org/jira/browse/MRESOLVER-361 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.9.10 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.11 > > > Two issues reported: > * PUT on closed connection is not retried. Suggested fix: change retry > handler to one that treats PUT as idempotent. > * -Oddity with 1 vs 2+ checksum algorithm used, in first case checksum > upload failure fails whole build, in second it only warns.- This proved > wrong, user build failed as metadata (so "main" payload not checksum of the > main payload) failed due HTTP connection error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] kwin merged pull request #434: Clarify collection implementations being injected
kwin merged PR #434: URL: https://github.com/apache/maven-site/pull/434 -- 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] (MNG-7835) Support for alternative POM syntaxes
Guillaume Nodet created MNG-7835: Summary: Support for alternative POM syntaxes Key: MNG-7835 URL: https://issues.apache.org/jira/browse/MNG-7835 Project: Maven Issue Type: New Feature Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #1196: Use model processor when locating the root pom when using -f/--file
gnodet opened a new pull request, #1196: URL: https://github.com/apache/maven/pull/1196 (no comment) -- 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] slawekjaranowski commented on pull request #435: Fix broken link to Gitea's repository manager support
slawekjaranowski commented on PR #435: URL: https://github.com/apache/maven-site/pull/435#issuecomment-1620373722 @wetneb thanks -- 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] slawekjaranowski merged pull request #435: Fix broken link to Gitea's repository manager support
slawekjaranowski merged PR #435: URL: https://github.com/apache/maven-site/pull/435 -- 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] (MJAVADOC-751) No warnings for localized output
[ https://issues.apache.org/jira/browse/MJAVADOC-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739928#comment-17739928 ] ASF GitHub Bot commented on MJAVADOC-751: - sitepark-schaeper commented on PR #206: URL: https://github.com/apache/maven-javadoc-plugin/pull/206#issuecomment-1620308849 > This needs a test. How would one go about testing this? Do we execute a test that executes the javadoc executable and check wether the output is english? There would also have to be a german/japanese/chinese environment to execute this test in as doing so in only an english environments seems redundant. > This might be a temporary workaround, but longer term I wonder if there's a non-command line way to invoke Javadoc these days. In Java 8 it should be as easy as: ```java javax.tools.ToolProvider.getSystemDocumentationTool().run(in, out, err, args) ``` And in Java 9+: ```java java.util.spi.ToolProvider.getSystemDocumentationTool().run(in, out, err, args); ``` But if we do that than we cannot influence the output locale anymore as it will always use `Locale.default()` (see [here](https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L136)) and therefore cannot parse it reliably. > No warnings for localized output > > > Key: MJAVADOC-751 > URL: https://issues.apache.org/jira/browse/MJAVADOC-751 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.5.0 >Reporter: Mario Schäper >Priority: Minor > Labels: easyfix, pull-request-available > Original Estimate: 1h > Remaining Estimate: 1h > > If the output of the javadoc executable is localized the following two errors > occur depending on the exit code: > 1) non-zero: the informational output filter (introduced in MJAVADOC-721) > does not work > 2) zero: no warnings are recognized > > #2 is particularly problematic if `failOnWarnings` is set, since this may > cause a build to fail in english environments, but not on certain others. > > Affected are japanese, chinese and since [JDK > 19|[https://github.com/openjdk/jdk/commit/38df5701ff82|https://github.com/openjdk/jdk/commit/38df5701ff82)]] > german. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] sitepark-schaeper commented on pull request #206: [MJAVADOC-751] No warnings for localized output
sitepark-schaeper commented on PR #206: URL: https://github.com/apache/maven-javadoc-plugin/pull/206#issuecomment-1620308849 > This needs a test. How would one go about testing this? Do we execute a test that executes the javadoc executable and check wether the output is english? There would also have to be a german/japanese/chinese environment to execute this test in as doing so in only an english environments seems redundant. > This might be a temporary workaround, but longer term I wonder if there's a non-command line way to invoke Javadoc these days. In Java 8 it should be as easy as: ```java javax.tools.ToolProvider.getSystemDocumentationTool().run(in, out, err, args) ``` And in Java 9+: ```java java.util.spi.ToolProvider.getSystemDocumentationTool().run(in, out, err, args); ``` But if we do that than we cannot influence the output locale anymore as it will always use `Locale.default()` (see [here](https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L136)) and therefore cannot parse it reliably. -- 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] wetneb opened a new pull request, #435: Fix broken link to Gitea's repository manager support
wetneb opened a new pull request, #435: URL: https://github.com/apache/maven-site/pull/435 I have not checked the other links. -- 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-plugin-tools] dependabot[bot] closed pull request #218: Bump plexus-xml from 4.0.0 to 4.0.1
dependabot[bot] closed pull request #218: Bump plexus-xml from 4.0.0 to 4.0.1 URL: https://github.com/apache/maven-plugin-tools/pull/218 -- 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-plugin-tools] dependabot[bot] opened a new pull request, #219: Bump plexus-xml from 4.0.0 to 4.0.2
dependabot[bot] opened a new pull request, #219: URL: https://github.com/apache/maven-plugin-tools/pull/219 Bumps [plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 4.0.0 to 4.0.2. Release notes Sourced from https://github.com/codehaus-plexus/plexus-xml/releases;>plexus-xml's releases. Plexus XML 4.0.2 What's Changed Cleanup after parent pom upgrade by https://github.com/slachiewicz;>@slachiewicz in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) by https://github.com/gnodet;>@gnodet in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/23;>codehaus-plexus/plexus-xml#23 New Contributors https://github.com/slachiewicz;>@slachiewicz made their first contribution in https://redirect.github.com/codehaus-plexus/plexus-xml/pull/22;>codehaus-plexus/plexus-xml#22 Full Changelog: https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2;>https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.1...plexus-xml-4.0.2 Commits https://github.com/codehaus-plexus/plexus-xml/commit/944197c74386b199857a003160d840fb5593ac29;>944197c [maven-release-plugin] prepare release plexus-xml-4.0.2 https://github.com/codehaus-plexus/plexus-xml/commit/c3d99b433a272d8eb1cc7c799410799e8c16ace3;>c3d99b4 Upgrade to 4.0.0-alpha-7 and exclude dependency to sisu (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/17;>#17) (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/23;>#23) https://github.com/codehaus-plexus/plexus-xml/commit/a83cefa086c9a5bb8b6674a409016f378b19891e;>a83cefa Cleanup after parent pom upgrade https://github.com/codehaus-plexus/plexus-xml/commit/25a00cd9d04ff3ab7acdcebdefdbb19ec5c4560d;>25a00cd [maven-release-plugin] prepare for next development iteration https://github.com/codehaus-plexus/plexus-xml/commit/bcb6981e2a9c635d024e0422de2a997a00ffdd8e;>bcb6981 [maven-release-plugin] prepare release plexus-xml-4.0.1 https://github.com/codehaus-plexus/plexus-xml/commit/d227a49f0f9b552a61b2aaac3bbe2c722ce06fea;>d227a49 Fix detection of invalid spaces in prolog (https://redirect.github.com/codehaus-plexus/plexus-xml/issues/20;>#20) https://github.com/codehaus-plexus/plexus-xml/commit/27d6127d3196d09263d8fe0f445b9d83f6ccfb75;>27d6127 pom.mxl and site.xml cleanup https://github.com/codehaus-plexus/plexus-xml/commit/62f50bc46c7b51d51a25541dfe0a502063dc1fc3;>62f50bc [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-4.0.0...plexus-xml-4.0.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [maven] gnodet commented on a diff in pull request #1193: Improve API doc for ArtifactHandler
gnodet commented on code in PR #1193:
URL: https://github.com/apache/maven/pull/1193#discussion_r1251983850
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -19,10 +19,10 @@
package org.apache.maven.artifact.handler;
/**
- * An artifact handler defines for a dependency type, defined as Plexus
role:
- * extension and classifier, to be able to download the file,
+ * An artifact handler contains metadata derived from the dependency element
that references the artifact:
+ * extension and classifier, to be able to download the file
* information on how to use the artifact: whether to add it to the
classpath, or to take into account its
- * dependencies.
+ * dependencies
Review Comment:
Should we keep the `.` and add `,` at the end of the previous ``.
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -19,10 +19,10 @@
package org.apache.maven.artifact.handler;
/**
- * An artifact handler defines for a dependency type, defined as Plexus
role:
- * extension and classifier, to be able to download the file,
+ * An artifact handler contains metadata derived from the dependency element
that references the artifact:
Review Comment:
I don't think that's true.
The metadata is not `derived from the dependency element`. The set of
artifact handlers is reduced and provides metadata related to the `dependency
type`.
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -32,7 +32,8 @@ public interface ArtifactHandler {
String ROLE = ArtifactHandler.class.getName();
/**
- * Get the file extension associated to the file represented by the
dependency type.
+ * Returns the file name extension of the artifact;
Review Comment:
`the file name extension` -> `the default file name extension`
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -41,7 +42,7 @@ public interface ArtifactHandler {
String getDirectory();
/**
- * Get the classifier associated to the dependency type.
+ * Returns the classifier of the dependency.
Review Comment:
Agreed, `classifier` -> `default classifier`
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -19,10 +19,10 @@
package org.apache.maven.artifact.handler;
/**
- * An artifact handler defines for a dependency type, defined as Plexus
role:
- * extension and classifier, to be able to download the file,
+ * An artifact handler contains metadata derived from the dependency element
that references the artifact:
+ * extension and classifier, to be able to download the file
Review Comment:
`extension and classifier` -> `défaut extension and classifier`
--
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] (MNGSITE-521) Define dependency type
Elliotte Rusty Harold created MNGSITE-521: - Summary: Define dependency type Key: MNGSITE-521 URL: https://issues.apache.org/jira/browse/MNGSITE-521 Project: Maven Project Web Site Issue Type: Bug Reporter: Elliotte Rusty Harold At no point I can find do we ever explain what a "dependency type" is though it's referenced in various places in the docs. It's not a Java type. It's not a file type. Beyond that I can't explain it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6401) Support proxy port interpolation in settings.xml
[ https://issues.apache.org/jira/browse/MNG-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739901#comment-17739901 ] ASF GitHub Bot commented on MNG-6401: - elharo commented on code in PR #1194: URL: https://github.com/apache/maven/pull/1194#discussion_r1251925120 ## api/maven-api-settings/src/main/mdo/settings.mdo: ## @@ -535,6 +539,62 @@ String + + + 1.0.0/1.3.0 + + + + + + 2.0.0+ + + - - active + + activeString 1.0.0+ false true
[GitHub] [maven] elharo commented on a diff in pull request #1194: [MNG-6401] Support interpolation of the proxy port in settings.xml
elharo commented on code in PR #1194: URL: https://github.com/apache/maven/pull/1194#discussion_r1251925120 ## api/maven-api-settings/src/main/mdo/settings.mdo: ## @@ -535,6 +539,62 @@ String + + + 1.0.0/1.3.0 + + + + + + 2.0.0+ + + - - active + + activeString 1.0.0+ false true
[GitHub] [maven-mvnd] gnodet commented on issue #863: mvnd is incompatible with revision，versions-maven-plugin is 2.7
gnodet commented on issue #863: URL: https://github.com/apache/maven-mvnd/issues/863#issuecomment-1619995156 > I attached the working log file mvn.txt with maven and failing log file mvnd.txt with mvnd, but i am not sure the specific step to reproduce this issue > > [mvn.txt](https://github.com/apache/maven-mvnd/files/11947522/mvn.txt) [mvnd.txt](https://github.com/apache/maven-mvnd/files/11947523/mvnd.txt) Did you use the same maven version of Maven ? mvnd comes with `m39` supporting Maven 3.9.x and `m40` supporting Maven 4.0.0-alpha-x. Given the log, it sounds like it could be a different behaviour between those. Can you maybe add the `-V` flag to both run to have the complete information ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-193) API change: let MavenReportRenderer#render() throw an exception
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-193: --- Component/s: (was: maven-reporting-impl) > API change: let MavenReportRenderer#render() throw an exception > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Assignee: Michael Osipov >Priority: Major > Labels: doxia-2.0.0-stack > Fix For: maven-reporting-api-4.0.0-M7 > > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-193) API change: let MavenReportRenderer#render() throw an exception
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739876#comment-17739876 ] ASF GitHub Bot commented on MSHARED-193: michael-o opened a new pull request, #18: URL: https://github.com/apache/maven-reporting-api/pull/18 …xception This closes #18 > API change: let MavenReportRenderer#render() throw an exception > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api, maven-reporting-impl >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Assignee: Michael Osipov >Priority: Major > Labels: doxia-2.0.0-stack > Fix For: maven-reporting-api-4.0.0-M7 > > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-reporting-api] michael-o opened a new pull request, #18: [MSHARED-193] API change: let MavenReportRenderer#render() throw an e…
michael-o opened a new pull request, #18: URL: https://github.com/apache/maven-reporting-api/pull/18 …xception This closes #18 -- 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-mvnd] gnodet commented on issue #867: mvnd slower than mvn
gnodet commented on issue #867: URL: https://github.com/apache/maven-mvnd/issues/867#issuecomment-1619965315 > Awesome. Thanks for your tests and feedback (esp. on optimization). > Did you run the `mvnd` with quickly option? No > Did you run the `mvn` without parallel (e.g. `-T 8`)? Yes, I used the same command for all runs. I think it was `[mvn or mvnd] -DskipTests install -T8`. For mvnd, I run it a few times, the subsequent runs are faster than the first one. -- 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-mvnd] ppalaga commented on issue #865: mvnd fails to run through powershell
ppalaga commented on issue #865: URL: https://github.com/apache/maven-mvnd/issues/865#issuecomment-1619924481 > It looks like mvn just drops "" arguments but mvnd tries to parse them as phases. This is interesting. I think we'd be interested to behave in the same way as stock Maven. WDYT, @gnodet? -- 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-mvnd] bonepl commented on issue #865: mvnd fails to run through powershell
bonepl commented on issue #865: URL: https://github.com/apache/maven-mvnd/issues/865#issuecomment-1619885594 okay, I debugged stuff more - something doesn't work between powershell and mvnd - some double quotes were passed "as is" to executable. It looks like mvn just drops `""` arguments but mvnd tries to parse them as phases. Thanks for feedback anyway. -- 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-7834) NPE in flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MNG-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739859#comment-17739859
]
ASF GitHub Bot commented on MNG-7834:
-
gnodet commented on code in PR #1195:
URL: https://github.com/apache/maven/pull/1195#discussion_r1251743128
##
src/mdo/model-v3.vm:
##
@@ -201,18 +201,27 @@ public class ${class.name}
if (!Objects.equals(map, getDelegate().get${cap}())) {
update(getDelegate().with${cap}(map));
}
- #else
+ #elseif ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
+if (${field.name} == null) {
+${field.name} = Collections.emptyList();
+}
if (!Objects.equals(${field.name}, ${pfx}${cap}())) {
-#if ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
update(getDelegate().with${cap}(
- ${field.name}.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
+${field.name}.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
${field.name}.forEach(e -> e.childrenTracking = this::replace);
-#elseif ( $field.to && $field.to != "String" )
-update(getDelegate().with${cap}(${field.name}.getDelegate()));
-${field.name}.childrenTracking = this::replace;
-#else
+}
+ #elseif ( $field.to && $field.to != "String" )
+if (!Objects.equals(${field.name}, ${pfx}${cap}())){
Review Comment:
The new code looks like:
```
public void setDistributionManagement(DistributionManagement
distributionManagement) {
if (!Objects.equals(distributionManagement,
getDistributionManagement())){
if (distributionManagement != null) {
update(getDelegate().withDistributionManagement(distributionManagement.getDelegate()));
distributionManagement.childrenTracking = this::replace;
} else {
update(getDelegate().withDistributionManagement(null));
}
}
}
```
> NPE in flatten-maven-plugin
> ---
>
> Key: MNG-7834
> URL: https://issues.apache.org/jira/browse/MNG-7834
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Guillaume Nodet
>Priority: Major
>
> The flatten-maven-plugin fails with a NullPointerException:
> {code}[ERROR] Failed to execute goal
> org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on project
> camel: failed to create a clean pom: Cannot invoke "java.util.List.stream()"
> because "dependencies" is null -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on
> project camel: failed to create a clean pom
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:341)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:324)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:114)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1623)
> Caused by: org.apache.maven.plugin.MojoExecutionException: failed to create a
> clean pom
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:556)
> at org.codehaus.mojo.flatten.FlattenMojo.execute(FlattenMojo.java:406)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
>
[GitHub] [maven] gnodet commented on a diff in pull request #1195: [MNG-7834] Fix NullPointerException in flatten-maven-plugin
gnodet commented on code in PR #1195:
URL: https://github.com/apache/maven/pull/1195#discussion_r1251743128
##
src/mdo/model-v3.vm:
##
@@ -201,18 +201,27 @@ public class ${class.name}
if (!Objects.equals(map, getDelegate().get${cap}())) {
update(getDelegate().with${cap}(map));
}
- #else
+ #elseif ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
+if (${field.name} == null) {
+${field.name} = Collections.emptyList();
+}
if (!Objects.equals(${field.name}, ${pfx}${cap}())) {
-#if ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
update(getDelegate().with${cap}(
- ${field.name}.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
+${field.name}.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
${field.name}.forEach(e -> e.childrenTracking = this::replace);
-#elseif ( $field.to && $field.to != "String" )
-update(getDelegate().with${cap}(${field.name}.getDelegate()));
-${field.name}.childrenTracking = this::replace;
-#else
+}
+ #elseif ( $field.to && $field.to != "String" )
+if (!Objects.equals(${field.name}, ${pfx}${cap}())){
Review Comment:
The new code looks like:
```
public void setDistributionManagement(DistributionManagement
distributionManagement) {
if (!Objects.equals(distributionManagement,
getDistributionManagement())){
if (distributionManagement != null) {
update(getDelegate().withDistributionManagement(distributionManagement.getDelegate()));
distributionManagement.childrenTracking = this::replace;
} else {
update(getDelegate().withDistributionManagement(null));
}
}
}
```
--
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-7834) NPE in flatten-maven-plugin
[
https://issues.apache.org/jira/browse/MNG-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739855#comment-17739855
]
ASF GitHub Bot commented on MNG-7834:
-
gnodet commented on code in PR #1195:
URL: https://github.com/apache/maven/pull/1195#discussion_r1251736267
##
src/mdo/model-v3.vm:
##
@@ -201,18 +201,25 @@ public class ${class.name}
if (!Objects.equals(map, getDelegate().get${cap}())) {
update(getDelegate().with${cap}(map));
}
- #else
+ #elseif ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
+if (${field.name} == null) {
Review Comment:
So the new code now looks like:
```
public void setDependencies(List dependencies) {
if (dependencies == null) {
dependencies = Collections.emptyList();
}
if (!Objects.equals(dependencies, getDependencies())) {
update(getDelegate().withDependencies(
dependencies.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
dependencies.forEach(e -> e.childrenTracking = this::replace);
}
}
```
> NPE in flatten-maven-plugin
> ---
>
> Key: MNG-7834
> URL: https://issues.apache.org/jira/browse/MNG-7834
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Guillaume Nodet
>Priority: Major
>
> The flatten-maven-plugin fails with a NullPointerException:
> {code}[ERROR] Failed to execute goal
> org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on project
> camel: failed to create a clean pom: Cannot invoke "java.util.List.stream()"
> because "dependencies" is null -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.codehaus.mojo:flatten-maven-plugin:1.5.0:flatten (default-cli) on
> project camel: failed to create a clean pom
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:341)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:324)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:114)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204)
> at
> io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:577)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1623)
> Caused by: org.apache.maven.plugin.MojoExecutionException: failed to create a
> clean pom
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:556)
> at org.codehaus.mojo.flatten.FlattenMojo.execute(FlattenMojo.java:406)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:336)
> ... 15 common frames omitted
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.util.List.stream()" because "dependencies" is null
> at org.apache.maven.model.ModelBase.setDependencies(ModelBase.java:164)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createCleanPom(FlattenMojo.java:686)
> at
> org.codehaus.mojo.flatten.FlattenMojo.createFlattenedPom(FlattenMojo.java:554)
> ... 18 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1195: [MNG-7834] Fix NullPointerException in flatten-maven-plugin
gnodet commented on code in PR #1195:
URL: https://github.com/apache/maven/pull/1195#discussion_r1251736267
##
src/mdo/model-v3.vm:
##
@@ -201,18 +201,25 @@ public class ${class.name}
if (!Objects.equals(map, getDelegate().get${cap}())) {
update(getDelegate().with${cap}(map));
}
- #else
+ #elseif ( $field.to != "String" && $field.type == "java.util.List" &&
$field.multiplicity == "*" )
+if (${field.name} == null) {
Review Comment:
So the new code now looks like:
```
public void setDependencies(List dependencies) {
if (dependencies == null) {
dependencies = Collections.emptyList();
}
if (!Objects.equals(dependencies, getDependencies())) {
update(getDelegate().withDependencies(
dependencies.stream().map(c ->
c.getDelegate()).collect(Collectors.toList(;
dependencies.forEach(e -> e.childrenTracking = this::replace);
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7832: --- Description: MNG-5697 proposed to move at the same time packaging mapping AND artifact handlers to packaging-oriented plugins packaging mapping is feasible, and can make sense: user configures a packaging plugin in his pom.xml to benefit from the full associated build lifecycle, why not but attifact handler is completely another beast: it's about consuming an artifact as a dependency, then not lead at all by the packaging of the project consuming the artifacts as dependencies https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html we need to split the 2 aspects: 1. finish lifecycle mapping definition to plugins, and remove at the end the definition from core, while learning users how to not any more benefit from implicit core definition 2. revert artifact handlers copy to packaging plugins, because they create confusion: artifacts will never be consumed with an artifact handler defined by an associated packaging plugin once someone finds something reasonable about artifact handlers, we can implement it later was: MNG-5697 proposed to move at the same time packaging mapping AND artifact handlers to packaging-oriented plugins packaging mapping is feasible, and can make sense: user configures a packaging plugin in his pom.xml to benefit from the full associated build lifecycle, why not but attifact handler is completely another beast: it's about consuming an artifact as a dependency, then not lead at all by the packaging of the project consuming the artifact https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html we need to split the 2 aspects: 1. finish lifecycle mapping definition to plugins, and remove at the end the definition from core, while learning users how to not any more benefit from implicit core definition 2. revert artifact handlers copy to packaging plugins, because they create confusion: artifacts will never be consumed with an artifact handler defined by an associated packaging plugin once someone finds something reasonable about artifact handlers, we can implement it later > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifacts as dependencies > https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7832: --- Description: MNG-5697 proposed to move at the same time packaging mapping AND artifact handlers to packaging-oriented plugins packaging mapping is feasible, and can make sense: user configures a packaging plugin in his pom.xml to benefit from the full associated build lifecycle, why not but attifact handler is completely another beast: it's about consuming an artifact as a dependency, then not lead at all by the packaging of the project consuming the artifact https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html we need to split the 2 aspects: 1. finish lifecycle mapping definition to plugins, and remove at the end the definition from core, while learning users how to not any more benefit from implicit core definition 2. revert artifact handlers copy to packaging plugins, because they create confusion: artifacts will never be consumed with an artifact handler defined by an associated packaging plugin once someone finds something reasonable about artifact handlers, we can implement it later was: MNG-5697 proposed to move at the same time packaging mapping AND artifact handlers to packaging-oriented plugins packaging mapping is feasible, and can make sense: user configures a packaging plugin in his pom.xml to benefit from the full associated build lifecycle, why not but attifact handler is completely another beast: it's about consuming an artifact as a dependency, then not lead at all by the packaging of the project consuming the artifact we need to split the 2 aspects: 1. finish lifecycle mapping definition to plugins, and remove at the end the definition from core, while learning users how to not any more benefit from implicit core definition 2. revert artifact handlers copy to packaging plugins, because they create confusion: artifacts will never be consumed with an artifact handler defined by an associated packaging plugin once someone finds something reasonable about artifact handlers, we can implement it later > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739813#comment-17739813 ] Herve Boutemy edited comment on MNG-7832 at 7/4/23 6:45 AM: I understand the global idea: thanks Robert for the reminder we still need to document precisely how this will be done by normal users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency (just for fun, I'm happy to see what will be chosen for test-jar, java-source and javadoc, even if the impact on users will be much smaller than jar) on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please let's do it in the right order: document what creating and using custom artifact handlers mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) was (Author: hboutemy): I understand the global idea: thanks Robert for the reminder we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please let's do it in the right order: document what creating and using custom artifact handlers mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739813#comment-17739813 ] Herve Boutemy edited comment on MNG-7832 at 7/4/23 6:41 AM: I understand the global idea: thanks Robert for the reminder we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please let's do it in the right order: document what creating and using custom artifact handlers mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) was (Author: hboutemy): I understand the global idea: thanks Robert for the reminder we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please do let's do it in the right order: document what creating and using custom ones mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #1192: Small changes
gnodet merged PR #1192: URL: https://github.com/apache/maven/pull/1192 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739813#comment-17739813 ] Herve Boutemy edited comment on MNG-7832 at 7/4/23 6:35 AM: I understand the global idea: thanks Robert for the reminder we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please do let's do it in the right order: document what creating and using custom ones mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) was (Author: hboutemy): I understand the global idea we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please do let's do it in the right order: document what creating and using custom ones mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1193: Improve API doc for ArtifactHandler
gnodet commented on code in PR #1193:
URL: https://github.com/apache/maven/pull/1193#discussion_r1251554945
##
maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java:
##
@@ -41,7 +42,7 @@ public interface ArtifactHandler {
String getDirectory();
/**
- * Get the classifier associated to the dependency type.
+ * Returns the classifier of the dependency.
Review Comment:
The `ArtifactHandler` is unrelated to the artifact's own pom.xml.
The `ArtifactHandler` is used to determine a few informations about a
dependency. It is retrieved based on the [_dependency
type_](https://maven.apache.org/ref/4-LATEST/apidocs/org/apache/maven/api/model/Dependency.html#getType()).
But the
[`Dependency`](https://maven.apache.org/ref/4-LATEST/apidocs/org/apache/maven/api/model/Dependency.html)
can define a classifier, which takes precedence over the default one provided
by the artifact handler.
--
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-7832) revert artifact handlers move to plugins
[ https://issues.apache.org/jira/browse/MNG-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739813#comment-17739813 ] Herve Boutemy commented on MNG-7832: I understand the global idea we still need to document precisely how this will be done by users consuming dependencies (which is a different question to users building with a packaging) and if it is not relatively transparent, I think some base artifact handlers deserve staying in Maven core, like jar = THE basic java dependency on moving less used artifact handlers from Jakarta EE land out of core into custom artifact handlers, I have no doubt: in fact, in the past, our main issue is that it has never been documented how to create a custom artifact handler and how to consume it (same for custom packaging): AFAIK, we don't have any documentation yet, we just have a better documentation of core ones. I'm not against moving things out of core, but please do let's do it in the right order: document what creating and using custom ones mean. Then and only then we can do the move (and again, I imagine we won't do the brutal move for absolutely everything, as it is done currently without taking care of user experience) > revert artifact handlers move to plugins > > > Key: MNG-7832 > URL: https://issues.apache.org/jira/browse/MNG-7832 > Project: Maven > Issue Type: Sub-task > Components: Dependencies, Plugins and Lifecycle >Reporter: Herve Boutemy >Priority: Major > > MNG-5697 proposed to move at the same time packaging mapping AND artifact > handlers to packaging-oriented plugins > packaging mapping is feasible, and can make sense: user configures a > packaging plugin in his pom.xml to benefit from the full associated build > lifecycle, why not > but attifact handler is completely another beast: it's about consuming an > artifact as a dependency, then not lead at all by the packaging of the > project consuming the artifact > we need to split the 2 aspects: > 1. finish lifecycle mapping definition to plugins, and remove at the end the > definition from core, while learning users how to not any more benefit from > implicit core definition > 2. revert artifact handlers copy to packaging plugins, because they create > confusion: artifacts will never be consumed with an artifact handler defined > by an associated packaging plugin > once someone finds something reasonable about artifact handlers, we can > implement it later -- This message was sent by Atlassian Jira (v8.20.10#820010)
