Re: [PR] [PR-104] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2049062373 @olamy : Surely, will create the Jira about it. Don't know about the plans too, but a release planned in the coming weeks is a good motivation. -- 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] [Closed] (MENFORCER-475) Only evaluate after aggregating pluginManagement
[ https://issues.apache.org/jira/browse/MENFORCER-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MENFORCER-475. - Resolution: Not A Problem > Only evaluate after aggregating pluginManagement > > > Key: MENFORCER-475 > URL: https://issues.apache.org/jira/browse/MENFORCER-475 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: requirePluginVersions >Affects Versions: 3.2.1 >Reporter: Delany >Priority: Major > > The rule fails if a plugin is configured in 2 pluginManagement sections (one > of which is in a profile), and the profile's pluginManagement does not > configure a plugin version. > Profiles are often used to augment the existing configuration for a plugin, > so there's no need to repeat the version number. > However if the profile is introducing the plugin to the build, then a version > tag should be required. > The rule should evaluate whether a version number has been set after > aggregating the configurations and resolving the profiles. > This is a new issue from Maven 4.0.0-alpha-5 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-735) Upgrade commons-io:commons-io to 2.16.1
[ https://issues.apache.org/jira/browse/DOXIA-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIA-735: - Summary: Upgrade commons-io:commons-io to 2.16.1 (was: Upgrade commons-io:commons-io to 2.16.0) > Upgrade commons-io:commons-io to 2.16.1 > --- > > Key: DOXIA-735 > URL: https://issues.apache.org/jira/browse/DOXIA-735 > Project: Maven Doxia > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 2.0.0, 2.0.0-M10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-735) Upgrade commons-io:commons-io to 2.16.1
[ https://issues.apache.org/jira/browse/DOXIA-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836042#comment-17836042 ] Michael Osipov commented on DOXIA-735: -- https://github.com/apache/maven-doxia/pull/207 > Upgrade commons-io:commons-io to 2.16.1 > --- > > Key: DOXIA-735 > URL: https://issues.apache.org/jira/browse/DOXIA-735 > Project: Maven Doxia > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 2.0.0, 2.0.0-M10 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8084] Move ModelBuilder and resolver provider to v4 api [maven]
cstamas commented on code in PR #1457:
URL: https://github.com/apache/maven/pull/1457#discussion_r1560604618
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ModelBuilderResult.java:
##
@@ -54,22 +54,28 @@ public interface ModelBuilderResult {
Model getFileModel();
/**
- * Gets the assembled model.
- *
- * @return The assembled model, never {@code null}.
+ * Returns the file model + profile injection.
+ * This
Review Comment:
This?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8084) Make the v4 api usable outside the Maven runtime
[
https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836044#comment-17836044
]
ASF GitHub Bot commented on MNG-8084:
-
cstamas commented on code in PR #1457:
URL: https://github.com/apache/maven/pull/1457#discussion_r1560604618
##
api/maven-api-core/src/main/java/org/apache/maven/api/services/ModelBuilderResult.java:
##
@@ -54,22 +54,28 @@ public interface ModelBuilderResult {
Model getFileModel();
/**
- * Gets the assembled model.
- *
- * @return The assembled model, never {@code null}.
+ * Returns the file model + profile injection.
+ * This
Review Comment:
This?
> Make the v4 api usable outside the Maven runtime
>
>
> Key: MNG-8084
> URL: https://issues.apache.org/jira/browse/MNG-8084
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Fix reporting before release [maven-doxia]
michael-o merged PR #208: URL: https://github.com/apache/maven-doxia/pull/208 -- 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
[PR] Fix a typo. [maven-site]
algonell opened a new pull request, #509: URL: https://github.com/apache/maven-site/pull/509 It seems that something is missing in the first sentence of this paragraph. There are multiple options, but just adding "work" seems to be fine. Thinking out loud, it could also be: "Using archetypes provides a great way to enable developers create projects quickly in a way consistent with best practices employed by your project or organization." -- 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
Re: [PR] [SCM-939] Towards JUnit4 ... DRAFT !! [maven-scm]
michael-o closed pull request #150: [SCM-939] Towards JUnit4 ... DRAFT !! URL: https://github.com/apache/maven-scm/pull/150 -- 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] [Closed] (SCM-939) Assume SCM is present
[
https://issues.apache.org/jira/browse/SCM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-939.
--
Resolution: Fixed
Fixed with
[95817d6b72d336450a54060371a4c7e593a75586|https://gitbox.apache.org/repos/asf?p=maven-scm.git&a=commit&h=95817d6b72d336450a54060371a4c7e593a75586].
> Assume SCM is present
> -
>
> Key: SCM-939
> URL: https://issues.apache.org/jira/browse/SCM-939
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.1.0
>
>
> We have a lot of tests that do something like this:
>
> if ( !ScmTestCase.isSystemCmd( SvnScmTestUtils.SVN_COMMAND_LINE ) )
> {
> ScmTestCase.printSystemCmdUnavail( SvnScmTestUtils.SVN_COMMAND_LINE,
> getName() );
> return;
> }
>
> We should instead use org.*junit*.*Assume* here so these are marked as
> skipped rather than passed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SCM-939) Assume SCM is present
[
https://issues.apache.org/jira/browse/SCM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836081#comment-17836081
]
ASF GitHub Bot commented on SCM-939:
michael-o closed pull request #150: [SCM-939] Towards JUnit4 ... DRAFT !!
URL: https://github.com/apache/maven-scm/pull/150
> Assume SCM is present
> -
>
> Key: SCM-939
> URL: https://issues.apache.org/jira/browse/SCM-939
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.1.0
>
>
> We have a lot of tests that do something like this:
>
> if ( !ScmTestCase.isSystemCmd( SvnScmTestUtils.SVN_COMMAND_LINE ) )
> {
> ScmTestCase.printSystemCmdUnavail( SvnScmTestUtils.SVN_COMMAND_LINE,
> getName() );
> return;
> }
>
> We should instead use org.*junit*.*Assume* here so these are marked as
> skipped rather than passed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Simplify IT for MSITE-723 [maven-site-plugin]
michael-o opened a new pull request, #179: URL: https://github.com/apache/maven-site-plugin/pull/179 We truly generate the file now instead of copying it. 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/MSITE) 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 `[MSITE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSITE-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] (MSITE-723) "About" report generated even though index.apt is available in "generated-site"
[ https://issues.apache.org/jira/browse/MSITE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836104#comment-17836104 ] ASF GitHub Bot commented on MSITE-723: -- michael-o opened a new pull request, #179: URL: https://github.com/apache/maven-site-plugin/pull/179 We truly generate the file now instead of copying it. 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/MSITE) 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 `[MSITE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSITE-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). > "About" report generated even though index.apt is available in > "generated-site" > --- > > Key: MSITE-723 > URL: https://issues.apache.org/jira/browse/MSITE-723 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 2.0, 3.0, 3.4 >Reporter: Andrius Velykis >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5 > > Attachments: mvn-site-index.zip > > > Normally, if there is an apt/index.apt file in the /src/site directory, About > report is not generated, and the following message is displayed: Skipped > "About" report, file "index.html" already exists for the English version. > Expecting the same behaviour, I have a situation, where the index.apt file is > generated automatically (e.g. copied from somewhere) during `pre-site` phase. > maven-site-plugin allows specifying an additional `generatedSiteDirectory` > parameter for these files (see > http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html). > However, in this case, the "About" report is generated and overrides the > copied file from `generatedSiteDirectory` parameter. > I would expect the "About" report to be not generated, if index.apt is > available in the `generatedSiteDirectory`. > I have attached a sample project, which uses `antrun` to copy a file to > /target/generated-site/apt/index.apt. When you run `mvn site`, it will still > display the default "About" page. As an example that `generatedSiteDirectory` > works, I also copy the same file to index-copy.apt and an index-copy.html is > generated correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSITE-723) "About" report generated even though index.apt is available in "generated-site"
[ https://issues.apache.org/jira/browse/MSITE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836135#comment-17836135 ] ASF GitHub Bot commented on MSITE-723: -- michael-o merged PR #179: URL: https://github.com/apache/maven-site-plugin/pull/179 > "About" report generated even though index.apt is available in > "generated-site" > --- > > Key: MSITE-723 > URL: https://issues.apache.org/jira/browse/MSITE-723 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 2.0, 3.0, 3.4 >Reporter: Andrius Velykis >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5 > > Attachments: mvn-site-index.zip > > > Normally, if there is an apt/index.apt file in the /src/site directory, About > report is not generated, and the following message is displayed: Skipped > "About" report, file "index.html" already exists for the English version. > Expecting the same behaviour, I have a situation, where the index.apt file is > generated automatically (e.g. copied from somewhere) during `pre-site` phase. > maven-site-plugin allows specifying an additional `generatedSiteDirectory` > parameter for these files (see > http://maven.apache.org/plugins/maven-site-plugin/site-mojo.html). > However, in this case, the "About" report is generated and overrides the > copied file from `generatedSiteDirectory` parameter. > I would expect the "About" report to be not generated, if index.apt is > available in the `generatedSiteDirectory`. > I have attached a sample project, which uses `antrun` to copy a file to > /target/generated-site/apt/index.apt. When you run `mvn site`, it will still > display the default "About" page. As an example that `generatedSiteDirectory` > works, I also copy the same file to index-copy.apt and an index-copy.html is > generated correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Simplify IT for MSITE-723 [maven-site-plugin]
michael-o merged PR #179: URL: https://github.com/apache/maven-site-plugin/pull/179 -- 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
Re: [PR] Remove duplicate content [maven-toolchains-plugin]
elharo merged PR #28: URL: https://github.com/apache/maven-toolchains-plugin/pull/28 -- 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
Re: [PR] [SCM-939] Towards JUnit4 ... DRAFT !! [maven-scm]
nielsbasjes commented on PR #150: URL: https://github.com/apache/maven-scm/pull/150#issuecomment-2049682493 Thanks @michael-o ! -- 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] (SCM-939) Assume SCM is present
[
https://issues.apache.org/jira/browse/SCM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836171#comment-17836171
]
ASF GitHub Bot commented on SCM-939:
nielsbasjes commented on PR #150:
URL: https://github.com/apache/maven-scm/pull/150#issuecomment-2049682493
Thanks @michael-o !
> Assume SCM is present
> -
>
> Key: SCM-939
> URL: https://issues.apache.org/jira/browse/SCM-939
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.1.0
>
>
> We have a lot of tests that do something like this:
>
> if ( !ScmTestCase.isSystemCmd( SvnScmTestUtils.SVN_COMMAND_LINE ) )
> {
> ScmTestCase.printSystemCmdUnavail( SvnScmTestUtils.SVN_COMMAND_LINE,
> getName() );
> return;
> }
>
> We should instead use org.*junit*.*Assume* here so these are marked as
> skipped rather than passed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SCM-939] Towards JUnit4 ... DRAFT !! [maven-scm]
michael-o commented on PR #150: URL: https://github.com/apache/maven-scm/pull/150#issuecomment-2049742397 > Thanks @michael-o ! No issue, appreciated. There might be better solutions for JUnit 4, but this is fine for me. -- 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] (SCM-939) Assume SCM is present
[
https://issues.apache.org/jira/browse/SCM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836190#comment-17836190
]
ASF GitHub Bot commented on SCM-939:
michael-o commented on PR #150:
URL: https://github.com/apache/maven-scm/pull/150#issuecomment-2049742397
> Thanks @michael-o !
No issue, appreciated. There might be better solutions for JUnit 4, but this
is fine for me.
> Assume SCM is present
> -
>
> Key: SCM-939
> URL: https://issues.apache.org/jira/browse/SCM-939
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 2.1.0
>
>
> We have a lot of tests that do something like this:
>
> if ( !ScmTestCase.isSystemCmd( SvnScmTestUtils.SVN_COMMAND_LINE ) )
> {
> ScmTestCase.printSystemCmdUnavail( SvnScmTestUtils.SVN_COMMAND_LINE,
> getName() );
> return;
> }
>
> We should instead use org.*junit*.*Assume* here so these are marked as
> skipped rather than passed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836195#comment-17836195
]
Michael Osipov commented on MNG-8041:
-
Is this worthy 3.8.9?
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-14
>
>
> This bug affects all released Maven versions.
> Reproducer: [https://github.com/cstamas/MNG-8041]
> Description of the bug: when a Mojo requires Core to collect/resolve given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, DPDR *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request is processed by Resolver, it will contain nodes from unwanted scopes
> (as Maven Core blindly added all of them from POM). Just as detail: if
> Resolver would be asked to create root, it would NOT add these in the first
> place. Due these present, conflict resolver may possibly eliminate other
> nodes (as POM ones "always wins", are the closest to graph root. Finally,
> these winners may be eliminated in subsequent step, for example due scope
> filtering. This results in incomplete resolution scope.
> Example: let's consider example where Mojo asks for "runtime" resolution
> scope. To serve this, Maven will add ALL dependencies present in POM to
> collect request (even those in scopes to be omitted, like "test" scoped
> ones), and will perform "collect" using Resolver. When Resolver returns the
> graph, it will contain nodes (as 1st level was populated by Maven) that MAY
> be contained in deeper nodes of non-test scoped ones (the guice+guava
> example). Next, "conflict resolution" happens, and naturally all the "test"
> scoped 1st level dependencies will "win", rendering removal of others.
> Finally, due "runtime" requested resolution scope, the "test" scoped
> dependencies are (rightfully) filtered out. {*}This obviously leads to
> incomplete runtime build path{*}.
> Or in other words, Maven is wrong here: it adds 1st level dependencies to
> CollectRequest that should not be there in the first place (in example above,
> the "test" scoped ones), that will cause that Resolver "collect" step build a
> graph that has "unwanted" scoped nodes closer to root than actually needed
> runtime dependencies (remember: test nodes will be not affected by filter, as
> they are already present, added by Maven, and test node children are
> collected also as "runtime", just to have "test" scope inherited later in the
> process, hence all the children of "test" node will end up in "test" scope,
> despite "exclude test" is present!), this will cause that in dependency
> conflict resolution step, they will kick out all the rightful runtime
> dependencies, and finally, all these winners are removed due scope filter.
> Implication of this bug is following important fact: the project "runtime"
> resolution scope (as when asked by Mojo) and project "runtime" resolution
> scope (as when used as a dependency on some downstream project) {*}were not
> the same{*}!
> Effects of this bug are explained in "Important Consequences" section of this
> page
> [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
> (that is wrongly written: all that is a consequence of this bug). Also, have
> to note, that when this bug get addressed, it will NOT render "workarounds"
> broken (ie. introduction of another module just to package "runtime"
> classpath using m-assembly-p or alike plugins), just "obsolete", as packaging
> of runtime dependencies will become possible in-situ (in the same module of
> the project).
> Exercises: check out reproducer and execute these commands:
> * {{mvn dependency:tree}} => OK, it shows "dependencies included from all
> scopes" (this is equiv to "test" build scope), guava is in test scope
> * {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
> this bug, guava is missing from runtime resolution scope
> * install the reproducer project into local repository, and create another
> project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
> project as dependency (only one,
Re: [PR] [MNG-8084] Include repository metadata in the API [maven]
gnodet merged PR #1465: URL: https://github.com/apache/maven/pull/1465 -- 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-8084) Make the v4 api usable outside the Maven runtime
[ https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836198#comment-17836198 ] ASF GitHub Bot commented on MNG-8084: - gnodet merged PR #1465: URL: https://github.com/apache/maven/pull/1465 > Make the v4 api usable outside the Maven runtime > > > Key: MNG-8084 > URL: https://issues.apache.org/jira/browse/MNG-8084 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836214#comment-17836214
]
Tamas Cservenak commented on MNG-8041:
--
Nope, see my comment above: all Maven 3 (all! from 3.0 to 3.9.6) releases
behaved like this. IMHO this is only for Maven4.
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-14
>
>
> This bug affects all released Maven versions.
> Reproducer: [https://github.com/cstamas/MNG-8041]
> Description of the bug: when a Mojo requires Core to collect/resolve given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, DPDR *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request is processed by Resolver, it will contain nodes from unwanted scopes
> (as Maven Core blindly added all of them from POM). Just as detail: if
> Resolver would be asked to create root, it would NOT add these in the first
> place. Due these present, conflict resolver may possibly eliminate other
> nodes (as POM ones "always wins", are the closest to graph root. Finally,
> these winners may be eliminated in subsequent step, for example due scope
> filtering. This results in incomplete resolution scope.
> Example: let's consider example where Mojo asks for "runtime" resolution
> scope. To serve this, Maven will add ALL dependencies present in POM to
> collect request (even those in scopes to be omitted, like "test" scoped
> ones), and will perform "collect" using Resolver. When Resolver returns the
> graph, it will contain nodes (as 1st level was populated by Maven) that MAY
> be contained in deeper nodes of non-test scoped ones (the guice+guava
> example). Next, "conflict resolution" happens, and naturally all the "test"
> scoped 1st level dependencies will "win", rendering removal of others.
> Finally, due "runtime" requested resolution scope, the "test" scoped
> dependencies are (rightfully) filtered out. {*}This obviously leads to
> incomplete runtime build path{*}.
> Or in other words, Maven is wrong here: it adds 1st level dependencies to
> CollectRequest that should not be there in the first place (in example above,
> the "test" scoped ones), that will cause that Resolver "collect" step build a
> graph that has "unwanted" scoped nodes closer to root than actually needed
> runtime dependencies (remember: test nodes will be not affected by filter, as
> they are already present, added by Maven, and test node children are
> collected also as "runtime", just to have "test" scope inherited later in the
> process, hence all the children of "test" node will end up in "test" scope,
> despite "exclude test" is present!), this will cause that in dependency
> conflict resolution step, they will kick out all the rightful runtime
> dependencies, and finally, all these winners are removed due scope filter.
> Implication of this bug is following important fact: the project "runtime"
> resolution scope (as when asked by Mojo) and project "runtime" resolution
> scope (as when used as a dependency on some downstream project) {*}were not
> the same{*}!
> Effects of this bug are explained in "Important Consequences" section of this
> page
> [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
> (that is wrongly written: all that is a consequence of this bug). Also, have
> to note, that when this bug get addressed, it will NOT render "workarounds"
> broken (ie. introduction of another module just to package "runtime"
> classpath using m-assembly-p or alike plugins), just "obsolete", as packaging
> of runtime dependencies will become possible in-situ (in the same module of
> the project).
> Exercises: check out reproducer and execute these commands:
> * {{mvn dependency:tree}} => OK, it shows "dependencies included from all
> scopes" (this is equiv to "test" build scope), guava is in test scope
> * {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
> this bug, guava is missing from runtime resolution scope
> * install the reproducer project into local repository, and create another
> project
[jira] [Created] (MGPG-126) Commons IO 2.16.1
Tamas Cservenak created MGPG-126: Summary: Commons IO 2.16.1 Key: MGPG-126 URL: https://issues.apache.org/jira/browse/MGPG-126 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.2.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump commons-io:commons-io from 2.16.0 to 2.16.1 [maven-gpg-plugin]
cstamas merged PR #94: URL: https://github.com/apache/maven-gpg-plugin/pull/94 -- 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] [Closed] (MGPG-126) Commons IO 2.16.1
[ https://issues.apache.org/jira/browse/MGPG-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-126. Resolution: Fixed > Commons IO 2.16.1 > - > > Key: MGPG-126 > URL: https://issues.apache.org/jira/browse/MGPG-126 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-126) Commons IO 2.16.1 (test dependency)
[ https://issues.apache.org/jira/browse/MGPG-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-126: - Summary: Commons IO 2.16.1 (test dependency) (was: Commons IO 2.16.1) > Commons IO 2.16.1 (test dependency) > --- > > Key: MGPG-126 > URL: https://issues.apache.org/jira/browse/MGPG-126 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.redisson:redisson from 3.27.2 to 3.28.0 [maven-resolver]
cstamas merged PR #463: URL: https://github.com/apache/maven-resolver/pull/463 -- 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] (MRESOLVER-534) Redisson 3.28.0
Tamas Cservenak created MRESOLVER-534: - Summary: Redisson 3.28.0 Key: MRESOLVER-534 URL: https://issues.apache.org/jira/browse/MRESOLVER-534 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-534) Redisson 3.28.0
[ https://issues.apache.org/jira/browse/MRESOLVER-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-534: - Assignee: Tamas Cservenak > Redisson 3.28.0 > --- > > Key: MRESOLVER-534 > URL: https://issues.apache.org/jira/browse/MRESOLVER-534 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-534) Redisson 3.28.0
[ https://issues.apache.org/jira/browse/MRESOLVER-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-534. - Resolution: Fixed > Redisson 3.28.0 > --- > > Key: MRESOLVER-534 > URL: https://issues.apache.org/jira/browse/MRESOLVER-534 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-83) Allow to share cache configuration (maven-build-cache-config.xml) between projects
Réda Housni Alaoui created MBUILDCACHE-83: - Summary: Allow to share cache configuration (maven-build-cache-config.xml) between projects Key: MBUILDCACHE-83 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-83 Project: Maven Build Cache Extension Issue Type: New Feature Reporter: Réda Housni Alaoui We have many maven projects that could benefit from this extension. They could share a common cache configuration. Would it make sense to be able to pass an http url instead of a path to locate the configuration file to use? If yes, would it make sense to have a configuration merging algorithm between a remote configuration and a local configuration? See https://github.com/apache/maven-build-cache-extension/blob/0410dc42c8fc3b7d06f982e2e46db41558e72145/src/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java#L142 . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8081:
-
Fix Version/s: 3.9.7
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-84) Allow maven plugins to expose their default cache configuration
Réda Housni Alaoui created MBUILDCACHE-84: - Summary: Allow maven plugins to expose their default cache configuration Key: MBUILDCACHE-84 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-84 Project: Maven Build Cache Extension Issue Type: New Feature Reporter: Réda Housni Alaoui Currently, all plugin default cache configurations are in one file of this extension project: https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml#L90 I think it would be nice to allow each maven plugin to declare its default caching configuration in its own project repository (e.g in a file located in the plugin's jar /META-INF). That would allow to have a growing catalog of default plugin configuration without having to modify https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml for each plugin that could exist. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8081:
-
Fix Version/s: 4.0.0
4.0.0-alpha-14
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-14
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-84) Allow maven plugins to expose their default cache configuration
[ https://issues.apache.org/jira/browse/MBUILDCACHE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Réda Housni Alaoui updated MBUILDCACHE-84: -- Description: Currently, all plugin default cache configurations are in one file of this extension project: https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml#L90 I think it would be nice to allow each maven plugin to declare its default caching configuration in its own project repository (e.g in a file located in the plugin's jar /META-INF). That would allow to have a growing catalog of default plugin configuration without having to modify https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml for each plugin that may exist. was: Currently, all plugin default cache configurations are in one file of this extension project: https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml#L90 I think it would be nice to allow each maven plugin to declare its default caching configuration in its own project repository (e.g in a file located in the plugin's jar /META-INF). That would allow to have a growing catalog of default plugin configuration without having to modify https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml for each plugin that could exist. > Allow maven plugins to expose their default cache configuration > --- > > Key: MBUILDCACHE-84 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-84 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Réda Housni Alaoui >Priority: Major > > Currently, all plugin default cache configurations are in one file of this > extension project: > https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml#L90 > I think it would be nice to allow each maven plugin to declare its default > caching configuration in its own project repository (e.g in a file located in > the plugin's jar /META-INF). > That would allow to have a growing catalog of default plugin configuration > without having to modify > https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml > for each plugin that may exist. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8094) Resolver 1.9.19
Tamas Cservenak created MNG-8094: Summary: Resolver 1.9.19 Key: MNG-8094 URL: https://issues.apache.org/jira/browse/MNG-8094 Project: Maven Issue Type: Dependency upgrade Components: Artifacts and Repositories Reporter: Tamas Cservenak Fix For: 3.9.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-790) The code being documented uses modules but the packages defined in X are in the unnamed module
[
https://issues.apache.org/jira/browse/MJAVADOC-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836242#comment-17836242
]
Gili commented on MJAVADOC-790:
---
Please let me know if you are able to reproduce this problem. An easy way to do
so is to run "mvn clean install" on this project:
https://github.com/cowwoc/requirements.java/tree/v9.0.0
> The code being documented uses modules but the packages defined in X are in
> the unnamed module
> --
>
> Key: MJAVADOC-790
> URL: https://issues.apache.org/jira/browse/MJAVADOC-790
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.6.3
> Environment: Microsoft Windows [Version 10.0.19045.4170]
> Maven 3.9.6
> openjdk version "21.0.1" 2023-10-17 LTS
> OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS)
> OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode,
> sharing)
>Reporter: Gili
>Priority: Major
>
> I thought that https://issues.apache.org/jira/browse/MJAVADOC-555 fixed this
> problem, but I have just run into it again.
> Given:
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
>
>
> attach-javadocs
>
> jar
>
>
> public
> Requirements Jackson Plugin ${project.version} API
> Requirements Jackson Plugin ${project.version}
> API
>
>
> --override-methods
> summary
>
>
>
> https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
>
>
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
>${project.basedir}/../java/target/apidocs
>
>
>
> com.github.cowwoc.requirements.jackson.internal,
> com.github.cowwoc.requirements.jackson.internal.*
>
>
>
>
> {code}
> I get this warning:
> {code:java}
> [INFO] --- javadoc:3.6.3:jar (attach-javadocs) @ jackson ---
> [INFO] No previous run data found, generating javadoc.
> [WARNING] Javadoc Warnings
> [WARNING] warning: The code being documented uses modules but the packages
> defined in
> https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/2.17.0/
> are in the unnamed module.
> [WARNING] 1 warning {code}
> Any idea why this is happening to Jackson's Javadoc but not to other
> non-modules like Guava?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-517) GoalRenderer renderParameterDetails renders in wrong order
Max Philipp Wriedt created MPLUGIN-517:
--
Summary: GoalRenderer renderParameterDetails renders in wrong order
Key: MPLUGIN-517
URL: https://issues.apache.org/jira/browse/MPLUGIN-517
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Reporting Plugin
Affects Versions: 3.12.0, 3.11.0
Reporter: Max Philipp Wriedt
GoalRenderer.java:360
{code:java}
sink.anchor(parameter.getName());
startSection(format("parameter.name", parameter.getName()));
sink.anchor_();
{code}
The closing {{anchor_();}} should be before starting the section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-517) GoalRenderer renderParameterDetails() renders in wrong order
[
https://issues.apache.org/jira/browse/MPLUGIN-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Philipp Wriedt updated MPLUGIN-517:
---
Summary: GoalRenderer renderParameterDetails() renders in wrong order
(was: GoalRenderer renderParameterDetails renders in wrong order)
> GoalRenderer renderParameterDetails() renders in wrong order
>
>
> Key: MPLUGIN-517
> URL: https://issues.apache.org/jira/browse/MPLUGIN-517
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Reporting Plugin
>Affects Versions: 3.11.0, 3.12.0
>Reporter: Max Philipp Wriedt
>Priority: Major
>
> GoalRenderer.java:360
> {code:java}
> sink.anchor(parameter.getName());
> startSection(format("parameter.name", parameter.getName()));
> sink.anchor_();
> {code}
> The closing {{anchor_();}} should be before starting the section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8081] interpolate available properties during default profile selection (Maven 4.x) [maven]
gnodet commented on PR #1446: URL: https://github.com/apache/maven/pull/1446#issuecomment-2049984725 > Thanks @gnodet and @rmannibucau for the approvals! What is the next step? I'm nearly done with http://github.com/apache/maven/pull/1457, so as soon as that one is merged, we'll be able to port this PR to the new model builder easily. -- 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-8081) default profile activation should consider available system and user properties
[
https://issues.apache.org/jira/browse/MNG-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836250#comment-17836250
]
ASF GitHub Bot commented on MNG-8081:
-
gnodet commented on PR #1446:
URL: https://github.com/apache/maven/pull/1446#issuecomment-2049984725
> Thanks @gnodet and @rmannibucau for the approvals! What is the next step?
I'm nearly done with http://github.com/apache/maven/pull/1457, so as soon as
that one is merged, we'll be able to port this PR to the new model builder
easily.
> default profile activation should consider available system and user
> properties
> ---
>
> Key: MNG-8081
> URL: https://issues.apache.org/jira/browse/MNG-8081
> Project: Maven
> Issue Type: Improvement
> Components: Profiles
>Affects Versions: 3.9.6, 4.0.0
>Reporter: Matthew Jason Benson
>Priority: Minor
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-14
>
>
> As discussed in my open PR, my use case is to compare between environment
> variables e.g.:
> {code:java}
>
>
> env.FOO
> ${env.BAR}
>
> {code}
> Limiting the interpolation to user/system properties means that there is no
> mindf*ck resulting from profile activation order, etc., and keeps this
> request nonthreatening.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-84) Allow maven plugins to expose their default cache configuration
[ https://issues.apache.org/jira/browse/MBUILDCACHE-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Réda Housni Alaoui updated MBUILDCACHE-84: -- Description: I think it would be nice to allow each maven plugin to declare its default caching configuration in its own project repository (e.g in a file located in the plugin's jar /META-INF). That would allow to have a growing catalog of default plugin configuration. was: Currently, all plugin default cache configurations are in one file of this extension project: https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml#L90 I think it would be nice to allow each maven plugin to declare its default caching configuration in its own project repository (e.g in a file located in the plugin's jar /META-INF). That would allow to have a growing catalog of default plugin configuration without having to modify https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/site/resources/maven-build-cache-config.xml for each plugin that may exist. > Allow maven plugins to expose their default cache configuration > --- > > Key: MBUILDCACHE-84 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-84 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Réda Housni Alaoui >Priority: Major > > I think it would be nice to allow each maven plugin to declare its default > caching configuration in its own project repository (e.g in a file located in > the plugin's jar /META-INF). > That would allow to have a growing catalog of default plugin configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MGPG-126) Commons IO 2.16.1 (test dependency)
[ https://issues.apache.org/jira/browse/MGPG-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MGPG-126: Assignee: Tamas Cservenak > Commons IO 2.16.1 (test dependency) > --- > > Key: MGPG-126 > URL: https://issues.apache.org/jira/browse/MGPG-126 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-916) Maven Dependency Plugin: Inclusion of main artifact in the output report
Arnab Banerjee created MDEP-916: --- Summary: Maven Dependency Plugin: Inclusion of main artifact in the output report Key: MDEP-916 URL: https://issues.apache.org/jira/browse/MDEP-916 Project: Maven Dependency Plugin Issue Type: New Feature Components: list Affects Versions: 3.6.1 Reporter: Arnab Banerjee While using [Apache Maven Dependency Plugin|https://maven.apache.org/plugins/maven-dependency-plugin/index.html] and using dependency:list, I noticed that the main artifact, which is being analyzed, is NOT getting included in the output report. It would be great to have an user property for the plugin to include the main artifact as well in the report. Following is an example for dependency listing of _*org.apache.httpcomponents.client5:httpclient5*_ [INFO] ---< org.apache.httpcomponents.client5:httpclient5 > [INFO] Building Apache HttpClient 5.4-alpha3-SNAPSHOT [INFO] [ jar ]- [INFO] [INFO] --- maven-dependency-plugin:3.3.0:list (default-cli) @ httpclient5 --- [INFO] [INFO] The following files have been resolved: [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha2:compile -- module org.apache.httpcomponents.core5.httpcore5 [auto] [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha2:compile -- module org.apache.httpcomponents.core5.httpcore5.h2 [auto] [INFO] org.slf4j:slf4j-api:jar:1.7.36:compile -- module org.slf4j [auto] [INFO] org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2:compile (optional) -- module org.conscrypt [auto] [INFO] org.apache.httpcomponents.core5:httpcore5-reactive:jar:5.3-alpha2:test -- module org.apache.httpcomponents.core5.httpcore5.reactive [auto] [INFO] org.reactivestreams:reactive-streams:jar:1.0.4:test -- module org.reactivestreams [auto] [INFO] io.reactivex.rxjava2:rxjava:jar:2.2.21:test -- module io.reactivex.rxjava2 [auto] [INFO] org.apache.logging.log4j:log4j-slf4j-impl:jar:2.23.0:test -- module org.apache.logging.log4j.slf4j.impl [INFO] org.apache.logging.log4j:log4j-api:jar:2.23.0:test -- module org.apache.logging.log4j [INFO] org.apache.logging.log4j:log4j-core:jar:2.23.0:test -- module org.apache.logging.log4j.core [INFO] org.brotli:dec:jar:0.1.2:compile (optional) -- module dec (auto) [INFO] org.junit.jupiter:junit-jupiter:jar:5.10.2:test -- module org.junit.jupiter [INFO] org.junit.jupiter:junit-jupiter-api:jar:5.10.2:test -- module org.junit.jupiter.api [INFO] org.opentest4j:opentest4j:jar:1.3.0:test -- module org.opentest4j [INFO] org.junit.platform:junit-platform-commons:jar:1.10.2:test -- module org.junit.platform.commons [INFO] org.apiguardian:apiguardian-api:jar:1.1.2:test -- module org.apiguardian.api [INFO] org.junit.jupiter:junit-jupiter-params:jar:5.10.2:test -- module org.junit.jupiter.params [INFO] org.junit.jupiter:junit-jupiter-engine:jar:5.10.2:test -- module org.junit.jupiter.engine [INFO] org.junit.platform:junit-platform-engine:jar:1.10.2:test -- module org.junit.platform.engine [INFO] org.hamcrest:hamcrest:jar:2.2:test -- module org.hamcrest [auto] [INFO] org.mockito:mockito-core:jar:4.11.0:test -- module org.mockito [auto] [INFO] net.bytebuddy:byte-buddy:jar:1.12.19:test -- module net.bytebuddy [INFO] net.bytebuddy:byte-buddy-agent:jar:1.12.19:test -- module net.bytebuddy.agent [INFO] org.objenesis:objenesis:jar:3.3:test -- module org.objenesis [auto] [INFO] Expected behavior: We should be able to include "org.apache.httpcomponents.client5:httpclient5" as well as part of the output for reporting/automation purposes. Probably similar to [|https://maven.apache.org/plugins/maven-dependency-plugin/list-mojo.html#includeParents] we can have an option like: "includeSelf" Note: dependency:tree goal gives us complete output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPOM-480] Remove maven-site-plugin:attach-descriptor [maven-apache-parent]
slawekjaranowski opened a new pull request, #207: URL: https://github.com/apache/maven-apache-parent/pull/207 (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
Re: [PR] [MGPG-125] Fix "bestPractices" [maven-gpg-plugin]
bmarwell commented on code in PR #95:
URL: https://github.com/apache/maven-gpg-plugin/pull/95#discussion_r1561581736
##
src/it/sign-release-best-practices-fail/verify.groovy:
##
@@ -0,0 +1,29 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+
+import org.codehaus.plexus.util.FileUtils
+
+var buildLog = new File(basedir, "build.log")
+var logContent = FileUtils.fileRead(buildLog)
Review Comment:
Groovy can do that without plexus utils:
```
String logContent = new File( basedir, "build.log").text
```
##
src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java:
##
@@ -299,11 +300,18 @@ public final void execute() throws
MojoExecutionException, MojoFailureException
// We're skipping the signing stuff
return;
}
-if (bestPractices && (isNotBlank(passphrase) ||
isNotBlank(passphraseServerId))) {
-// Stop propagating worst practices: passphrase MUST NOT be in any
file on disk
-throw new MojoFailureException(
-"Do not store passphrase in any file (disk or SCM
repository), rely on GnuPG agent or provide passphrase in "
-+ passphraseEnvName + " environment variable.");
+if (bestPractices) {
+if (isNotBlank(passphrase) || isNotBlank(passphraseServerId)) {
+// Stop propagating worst practices: passphrase MUST NOT be in
any file on disk
+throw new MojoFailureException(
+"Do not store passphrase in any file (disk or SCM
repository), rely on GnuPG agent or provide passphrase in "
++ passphraseEnvName + " environment
variable.");
+}
+} else {
Review Comment:
As best practices will probably be extended in the future, why not just
refactor out a method here?
```suggestion
if (bestPractices) {
checkForBestPractices();
} else {
```
##
src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java:
##
@@ -299,11 +300,18 @@ public final void execute() throws
MojoExecutionException, MojoFailureException
// We're skipping the signing stuff
return;
}
-if (bestPractices && (isNotBlank(passphrase) ||
isNotBlank(passphraseServerId))) {
-// Stop propagating worst practices: passphrase MUST NOT be in any
file on disk
-throw new MojoFailureException(
-"Do not store passphrase in any file (disk or SCM
repository), rely on GnuPG agent or provide passphrase in "
-+ passphraseEnvName + " environment variable.");
+if (bestPractices) {
+if (isNotBlank(passphrase) || isNotBlank(passphraseServerId)) {
+// Stop propagating worst practices: passphrase MUST NOT be in
any file on disk
+throw new MojoFailureException(
+"Do not store passphrase in any file (disk or SCM
repository), rely on GnuPG agent or provide passphrase in "
++ passphraseEnvName + " environment
variable.");
+}
+} else {
+if (!isNotBlank(passphraseServerId)) {
+// default it programmatically: this is needed to handle
different cases re bestPractices
+passphraseServerId = GPG_PASSPHRASE;
+}
Review Comment:
I feel this is a default case inside an else-if nesting. However, as the
isolated if(bestPractices) improves readability, I'd say: keep it for now.
One solution would be to refactor out a method like `setDefaults()`, but
probably not worth it.
##
src/it/sign-release-best-practices-fail/verify.groovy:
##
@@ -0,0 +1,29 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.
[jira] [Commented] (MDEP-916) Maven Dependency Plugin: Inclusion of main artifact in the output report
[ https://issues.apache.org/jira/browse/MDEP-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836350#comment-17836350 ] Tamas Cservenak commented on MDEP-916: -- This is chicken or egg problem: maven should know is "main artifact being analyzed" built at all, as otherwise it cannot be analyzed (what to analyze?). Ideally, the main artifact should be installed. But if installed, you have alternate means to perform this: example is here https://gist.github.com/cstamas/9b4b6464978a3d4313268dbf30ad55b7 > Maven Dependency Plugin: Inclusion of main artifact in the output report > > > Key: MDEP-916 > URL: https://issues.apache.org/jira/browse/MDEP-916 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: list >Affects Versions: 3.6.1 >Reporter: Arnab Banerjee >Priority: Minor > > While using [Apache Maven Dependency > Plugin|https://maven.apache.org/plugins/maven-dependency-plugin/index.html] > and using dependency:list, I noticed that the main artifact, which is being > analyzed, is NOT getting included in the output report. > It would be great to have an user property for the plugin to include the main > artifact as well in the report. > > Following is an example for dependency listing of > _*org.apache.httpcomponents.client5:httpclient5*_ > > [INFO] ---< org.apache.httpcomponents.client5:httpclient5 > > > [INFO] Building Apache HttpClient 5.4-alpha3-SNAPSHOT > [INFO] [ jar > ]- > [INFO] > [INFO] --- maven-dependency-plugin:3.3.0:list (default-cli) @ httpclient5 --- > [INFO] > [INFO] The following files have been resolved: > [INFO] org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha2:compile -- > module org.apache.httpcomponents.core5.httpcore5 [auto] > [INFO] org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha2:compile > -- module org.apache.httpcomponents.core5.httpcore5.h2 [auto] > [INFO] org.slf4j:slf4j-api:jar:1.7.36:compile -- module org.slf4j [auto] > [INFO] org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2:compile (optional) > -- module org.conscrypt [auto] > [INFO] > org.apache.httpcomponents.core5:httpcore5-reactive:jar:5.3-alpha2:test -- > module org.apache.httpcomponents.core5.httpcore5.reactive [auto] > [INFO] org.reactivestreams:reactive-streams:jar:1.0.4:test -- module > org.reactivestreams [auto] > [INFO] io.reactivex.rxjava2:rxjava:jar:2.2.21:test -- module > io.reactivex.rxjava2 [auto] > [INFO] org.apache.logging.log4j:log4j-slf4j-impl:jar:2.23.0:test -- module > org.apache.logging.log4j.slf4j.impl > [INFO] org.apache.logging.log4j:log4j-api:jar:2.23.0:test -- module > org.apache.logging.log4j > [INFO] org.apache.logging.log4j:log4j-core:jar:2.23.0:test -- module > org.apache.logging.log4j.core > [INFO] org.brotli:dec:jar:0.1.2:compile (optional) -- module dec (auto) > [INFO] org.junit.jupiter:junit-jupiter:jar:5.10.2:test -- module > org.junit.jupiter > [INFO] org.junit.jupiter:junit-jupiter-api:jar:5.10.2:test -- module > org.junit.jupiter.api > [INFO] org.opentest4j:opentest4j:jar:1.3.0:test -- module org.opentest4j > [INFO] org.junit.platform:junit-platform-commons:jar:1.10.2:test -- module > org.junit.platform.commons > [INFO] org.apiguardian:apiguardian-api:jar:1.1.2:test -- module > org.apiguardian.api > [INFO] org.junit.jupiter:junit-jupiter-params:jar:5.10.2:test -- module > org.junit.jupiter.params > [INFO] org.junit.jupiter:junit-jupiter-engine:jar:5.10.2:test -- module > org.junit.jupiter.engine > [INFO] org.junit.platform:junit-platform-engine:jar:1.10.2:test -- module > org.junit.platform.engine > [INFO] org.hamcrest:hamcrest:jar:2.2:test -- module org.hamcrest [auto] > [INFO] org.mockito:mockito-core:jar:4.11.0:test -- module org.mockito > [auto] > [INFO] net.bytebuddy:byte-buddy:jar:1.12.19:test -- module net.bytebuddy > [INFO] net.bytebuddy:byte-buddy-agent:jar:1.12.19:test -- module > net.bytebuddy.agent > [INFO] org.objenesis:objenesis:jar:3.3:test -- module org.objenesis [auto] > [INFO] > > Expected behavior: We should be able to include > "org.apache.httpcomponents.client5:httpclient5" as well as part of the output > for reporting/automation purposes. > Probably similar to > [|https://maven.apache.org/plugins/maven-dependency-plugin/list-mojo.html#includeParents] > we can have an option like: "includeSelf" > > Note: dependency:tree goal gives us complete output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-535) DependenctGraphDumper decorator
Tamas Cservenak created MRESOLVER-535: - Summary: DependenctGraphDumper decorator Key: MRESOLVER-535 URL: https://issues.apache.org/jira/browse/MRESOLVER-535 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 Allow passing in custom decorator to pull decoration from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-535) DependenctGraphDumper decorator
[ https://issues.apache.org/jira/browse/MRESOLVER-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836353#comment-17836353 ] ASF GitHub Bot commented on MRESOLVER-535: -- cstamas opened a new pull request, #464: URL: https://github.com/apache/maven-resolver/pull/464 Ability to pass in any function that is able to "decorate" the print out of the graph. --- https://issues.apache.org/jira/browse/MRESOLVER-535 > DependenctGraphDumper decorator > --- > > Key: MRESOLVER-535 > URL: https://issues.apache.org/jira/browse/MRESOLVER-535 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Allow passing in custom decorator to pull decoration from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-535) DependenctGraphDumper decorator
[ https://issues.apache.org/jira/browse/MRESOLVER-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-535: - Assignee: Tamas Cservenak > DependenctGraphDumper decorator > --- > > Key: MRESOLVER-535 > URL: https://issues.apache.org/jira/browse/MRESOLVER-535 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Allow passing in custom decorator to pull decoration from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836366#comment-17836366
]
ASF GitHub Bot commented on MARTIFACT-60:
-
garydgregory opened a new pull request, #32:
URL: https://github.com/apache/maven-artifact-plugin/pull/32
Sample output from Apache Commons CLI
[INFO] -
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0, 3.5.1
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Priority: Major
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated MARTIFACT-60:
Labels: pull-request-available (was: )
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0, 3.5.1
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Priority: Major
> Labels: pull-request-available
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MARTIFACT-60) artifact:3.5.0:check-buildplan is too chatty by default
[
https://issues.apache.org/jira/browse/MARTIFACT-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836367#comment-17836367
]
Gary D. Gregory commented on MARTIFACT-60:
--
Hi All,
I propose https://github.com/apache/maven-artifact-plugin/pull/32
> artifact:3.5.0:check-buildplan is too chatty by default
> ---
>
> Key: MARTIFACT-60
> URL: https://issues.apache.org/jira/browse/MARTIFACT-60
> Project: Maven Artifact Plugin
> Issue Type: Improvement
> Components: artifact:check-buildplan
>Affects Versions: 3.5.0, 3.5.1
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\java\apache-maven-3.9.6
> Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.8.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary D. Gregory
>Priority: Major
> Labels: pull-request-available
>
> Running the plugin is too chatty by default, for example, I don't need
> everything that's NOT wrong. Just tell me what's wrong or nothing:
> {noformat}
> [INFO] — artifact:3.5.0:check-buildplan (check-buildplan) @ commons-io —
> [INFO] no known issue with
> org.apache.maven.plugins:maven-enforcer-plugin:3.4.1
> [INFO] no known issue with org.apache.rat:apache-rat-plugin:0.16.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-artifact-plugin:3.5.0
> [INFO] no known issue with org.codehaus.mojo:build-helper-maven-plugin:3.5.0
> [INFO] no known issue with org.apache.maven.plugins:maven-antrun-plugin:3.1.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-remote-resources-plugin:3.1.0 (>= 1.7.0)
> [INFO] no known issue with org.codehaus.mojo:buildnumber-maven-plugin:3.2.0
> [INFO] no known issue with
> org.apache.maven.plugins:maven-resources-plugin:3.3.1
> [INFO] no known issue with
> org.apache.maven.plugins:maven-compiler-plugin:3.13.0
> [INFO] no known issue with org.apache.felix:maven-bundle-plugin:5.1.9 (>=
> 5.1.9)
> [INFO] no known issue with org.jacoco:jacoco-maven-plugin:0.8.11
> [INFO] no known issue with
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5
> [INFO] no known issue with org.apache.maven.plugins:maven-jar-plugin:3.3.0
> (>= 3.2.0)
> [INFO] no known issue with org.apache.maven.plugins:maven-site-plugin:3.12.1
> [INFO] no known issue with org.apache.maven.plugins:maven-source-plugin:3.2.1
> (>= 3.2.1)
> [INFO] no known issue with org.cyclonedx:cyclonedx-maven-plugin:2.8.0
> [INFO] no known issue with org.spdx:spdx-maven-plugin:0.7.3
> [INFO] no known issue with org.moditect:moditect-maven-plugin:1.2.1.Final (>=
> 1.0.0.Final)
> [INFO] no known issue with org.apache.maven.plugins:maven-install-plugin:3.1.1
> [INFO] no known issue with org.apache.maven.plugins:maven-deploy-plugin:3.1.1
> {noformat}
> Either say nothing or, if you must, perhaps a single log event:
> "No issues found in 16 plugins." Note that sentences should start with a
> capital letter.
> The current info would be fine at the debug logging level IMO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.apache.maven.plugins:maven-gpg-plugin from 3.2.2 to 3.2.3 [maven-apache-parent]
dependabot[bot] opened a new pull request, #208: URL: https://github.com/apache/maven-apache-parent/pull/208 Bumps [org.apache.maven.plugins:maven-gpg-plugin](https://github.com/apache/maven-gpg-plugin) from 3.2.2 to 3.2.3. Release notes Sourced from https://github.com/apache/maven-gpg-plugin/releases";>org.apache.maven.plugins:maven-gpg-plugin's releases. 3.2.3 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521&version=12354440";>Release Notes - Maven GPG Plugin - Version 3.2.3 https://issues.apache.org/jira/browse/MGPG-123%5D%5BMGPG-124";>[MGPG-123][MGPG-124] - Dependency upgrades (https://redirect.github.com/apache/maven-gpg-plugin/pull/93";>#93) https://github.com/cstamas";>@cstamas https://issues.apache.org/jira/browse/MGPG-120";>[MGPG-120] - New mojo sign-deployed (https://redirect.github.com/apache/maven-gpg-plugin/pull/88";>#88) https://github.com/cstamas";>@cstamas https://issues.apache.org/jira/browse/MGPG-121";>[MGPG-121] - Return the workaround for pseudo security (https://redirect.github.com/apache/maven-gpg-plugin/pull/90";>#90) https://github.com/cstamas";>@cstamas https://issues.apache.org/jira/browse/MGPG-117";>[MGPG-117] - Improve passphrase handling (https://redirect.github.com/apache/maven-gpg-plugin/pull/86";>#86) https://github.com/cstamas";>@cstamas https://issues.apache.org/jira/browse/MGPG-116";>[MGPG-116] - Up max key file size to 64K (https://redirect.github.com/apache/maven-gpg-plugin/pull/85";>#85) https://github.com/cstamas";>@cstamas 📦 Dependency updates ... (truncated) Commits https://github.com/apache/maven-gpg-plugin/commit/89b91a40617f911ce77cc3190842d46b1f470f45";>89b91a4 [maven-release-plugin] prepare release maven-gpg-plugin-3.2.3 https://github.com/apache/maven-gpg-plugin/commit/fc2efa3097fa620ce5d5167a9d8ab9018a4247a5";>fc2efa3 [MGPG-123][MGPG-124] Dependency upgrades (https://redirect.github.com/apache/maven-gpg-plugin/issues/93";>#93) https://github.com/apache/maven-gpg-plugin/commit/50222d351ac12e746ce9921a957654e5e24a55de";>50222d3 [MGPG-120] New mojo sign-deployed (https://redirect.github.com/apache/maven-gpg-plugin/issues/88";>#88) https://github.com/apache/maven-gpg-plugin/commit/a6c3a094ea1e3b29fc3711f450f57e6e292fabed";>a6c3a09 [MGPG-122] Bump org.apache.maven.plugins:maven-invoker-plugin from 3.6.0 to 3... https://github.com/apache/maven-gpg-plugin/commit/78f5e370ee5f02f1b613540d8d7204cab919d99d";>78f5e37 [MGPG-121] Return the workaround for pseudo security (https://redirect.github.com/apache/maven-gpg-plugin/issues/90";>#90) https://github.com/apache/maven-gpg-plugin/commit/582df745e6ec01e414be255fae0a8b262255c641";>582df74 [MGPG-117] Improve passphrase handling (https://redirect.github.com/apache/maven-gpg-plugin/issues/86";>#86) https://github.com/apache/maven-gpg-plugin/commit/0adc6b8e50e09880495290aeb4a0dc953d1b7134";>0adc6b8 [MGPG-118] Bump commons-io:commons-io from 2.15.1 to 2.16.0 (https://redirect.github.com/apache/maven-gpg-plugin/issues/87";>#87) https://github.com/apache/maven-gpg-plugin/commit/ef57091a7ffce55afe7b68bbd8b7592a6831687f";>ef57091 [MGPG-116] Up max key file size to 64K (https://redirect.github.com/apache/maven-gpg-plugin/issues/85";>#85) https://github.com/apache/maven-gpg-plugin/commit/944be4e628ac721f654b4bbabb454206355144ae";>944be4e [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-gpg-plugin/compare/maven-gpg-plugin-3.2.2...maven-gpg-plugin-3.2.3";>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
Re: [PR] [MPH-183] Effective POM path to source [maven-help-plugin]
Giovds commented on code in PR #37:
URL: https://github.com/apache/maven-help-plugin/pull/37#discussion_r1562100440
##
src/main/java/org/apache/maven/plugins/help/DefaultInputLocationFormatter.java:
##
@@ -0,0 +1,42 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.plugins.help;
+
+import org.apache.maven.model.InputLocation;
+import org.apache.maven.model.InputSource;
+import org.codehaus.plexus.util.StringUtils;
+
+/**
+ * Maven 3.x-based implementation of {@link InputLocation.StringFormatter}.
Review Comment:
Agreed, we should probably change the name of the class and edit the JDocs.
We would like to backport it to Maven 3, but initially want to make it work for
Maven 4 first without breaking other versions.
--
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] (MPH-183) Effective-pom + verbose should show import path to BOM dependencyManagement
[
https://issues.apache.org/jira/browse/MPH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836433#comment-17836433
]
ASF GitHub Bot commented on MPH-183:
Giovds commented on code in PR #37:
URL: https://github.com/apache/maven-help-plugin/pull/37#discussion_r1562100440
##
src/main/java/org/apache/maven/plugins/help/DefaultInputLocationFormatter.java:
##
@@ -0,0 +1,42 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.plugins.help;
+
+import org.apache.maven.model.InputLocation;
+import org.apache.maven.model.InputSource;
+import org.codehaus.plexus.util.StringUtils;
+
+/**
+ * Maven 3.x-based implementation of {@link InputLocation.StringFormatter}.
Review Comment:
Agreed, we should probably change the name of the class and edit the JDocs.
We would like to backport it to Maven 3, but initially want to make it work for
Maven 4 first without breaking other versions.
> Effective-pom + verbose should show import path to BOM dependencyManagement
> ---
>
> Key: MPH-183
> URL: https://issues.apache.org/jira/browse/MPH-183
> Project: Maven Help Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.0
>Reporter: Robert Scholte
>Assignee: Maarten Mulders
>Priority: Major
> Attachments: mph-183-it.zip
>
>
> The popular spring-boot makes a lot of use of BOMs. Using BOMs is a good
> practice, but right now it is very hard to determine where
> dependencyManagement dependencies and especially their versions are coming
> from.
> Instead of only showing only the final location (from the BOM POM), it should
> also show the import path from the current project to that specific pom
> (where is the BOM POM imported?).
> This way it will be easier to figure out which dependency in which POM needs
> to be upgraded: it's the version in the POM declaring the import of the BOM
> POM, not the version in the imported BOM POM.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPLUGIN-517) GoalRenderer renderParameterDetails() renders in wrong order
[
https://issues.apache.org/jira/browse/MPLUGIN-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPLUGIN-517:
--
Assignee: Michael Osipov
> GoalRenderer renderParameterDetails() renders in wrong order
>
>
> Key: MPLUGIN-517
> URL: https://issues.apache.org/jira/browse/MPLUGIN-517
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Reporting Plugin
>Affects Versions: 3.11.0, 3.12.0
>Reporter: Max Philipp Wriedt
>Assignee: Michael Osipov
>Priority: Major
>
> GoalRenderer.java:360
> {code:java}
> sink.anchor(parameter.getName());
> startSection(format("parameter.name", parameter.getName()));
> sink.anchor_();
> {code}
> The closing {{anchor_();}} should be before starting the section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-517) GoalRenderer renderParameterDetails() renders in wrong order
[
https://issues.apache.org/jira/browse/MPLUGIN-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPLUGIN-517:
---
Fix Version/s: 3.12.1
> GoalRenderer renderParameterDetails() renders in wrong order
>
>
> Key: MPLUGIN-517
> URL: https://issues.apache.org/jira/browse/MPLUGIN-517
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Reporting Plugin
>Affects Versions: 3.11.0, 3.12.0
>Reporter: Max Philipp Wriedt
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.12.1
>
>
> GoalRenderer.java:360
> {code:java}
> sink.anchor(parameter.getName());
> startSection(format("parameter.name", parameter.getName()));
> sink.anchor_();
> {code}
> The closing {{anchor_();}} should be before starting the section.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
