[PR] Bump com.ibm.icu:icu4j from 73.2 to 74.1 [maven-doxia-converter]
dependabot[bot] opened a new pull request, #52: URL: https://github.com/apache/maven-doxia-converter/pull/52 Bumps [com.ibm.icu:icu4j](https://github.com/unicode-org/icu) from 73.2 to 74.1. Release notes Sourced from https://github.com/unicode-org/icu/releases";>com.ibm.icu:icu4j's releases. ICU 74.1 Draft, building binaries, working on the release page. Watch for an announcement around oct31/nov01. ICU 74 RC We are pleased to announce the release candidate for Unicode® ICU 74. It updates to http://blog.unicode.org/2023/09/announcing-unicode-standard-version-151.html";>Unicode 15.1, and to https://cldr.unicode.org/index/downloads/cldr-44";>CLDR 44 locale data with various additions and corrections. ICU 74 and CLDR 44 are major releases, including a new version of Unicode and major locale data improvements. They subsume the changes for the https://blog.unicode.org/2023/06/icu-732-cldr-431-released-gb18030.html";>ICU 73.2 and CLDR 43.1 maintenance releases. For details, please see https://icu.unicode.org/download/74";>https://icu.unicode.org/download/74. Please test this release candidate on your platforms and report bugs and regressions by Wednesday, 2023-oct-26, via the https://icu.unicode.org/contacts";>icu-support mailing list, and/or please https://icu.unicode.org/bugs";>find/submit error reports. Please do not use this release candidate in production. The preliminary API reference documents are published on https://unicode-org.github.io/icu-docs/";>unicode-org.github.io/icu-docs/ – follow the “Dev” links there. Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. (ICU locale data was generated from the CLDR tag: https://github.com/unicode-org/cldr/releases/tag/release-44-beta2";>https://github.com/unicode-org/cldr/releases/tag/release-44-beta2) Commits See full diff in https://github.com/unicode-org/icu/commits";>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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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 at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1326) Improve (documentation on) MavenReport interface/AbstractMavenReport class
[
https://issues.apache.org/jira/browse/MSHARED-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781180#comment-17781180
]
ASF GitHub Bot commented on MSHARED-1326:
-
kriegaex commented on PR #19:
URL:
https://github.com/apache/maven-reporting-api/pull/19#issuecomment-1786288822
> I believe that the last one is logically wrong.
I do not think so, because it dependes on the context and the assumptions
under which users read the documentation. My context is obviously different
from yours, which is why you think it is logically wrong. Maybe it is also a
grammatical question to some degree. I prefer "report base (...) directory" to
"base report (...) directory", as the latter seems to be bad English. It is a
base directory. What kind of base directory? A report base directory, not a
base directory for anything else. Which is why I would order the terms that way.
As for "a lot (of medicine) helps a lot" or combining the terms, making the
result an even more unweildy "shared base report output directory" or "shared
report base output directory" as the lesser evil, I am not sure if that might
not be too subtle for most plugin developers to grasp. In such cases, a little
bit of explanation usually helps, why I usually just expand the description,
maybe even adding an instructive example. Precise and to the point is good, but
sometimes too terse.
I leave the decision up to you, but you asked "WDYT?", so these are my two
cents.
> Improve (documentation on) MavenReport interface/AbstractMavenReport class
> --
>
> Key: MSHARED-1326
> URL: https://issues.apache.org/jira/browse/MSHARED-1326
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-reporting-api
>Affects Versions: maven-reporting-impl-4.0.0-M11,
> maven-reporting-api-4.0.0-M8
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-api-4.0.0-M9,
> maven-reporting-impl-4.0.0-M12
>
>
> Based on a
> [discussion|https://lists.apache.org/thread/6yxlvbhb7odfylfgjgzbvmvxg0vry20b]
> with [~kriegaex], there are few conceptional or documentational issues with
> the {{MavenReport}} interface:
> * {{#getOutputName()}} does not clearly say that is actually an optional base
> *path* and base name (base location) of the report item from a reporting
> output directory. It needs at least a doc update and maybe even a rename to
> {{#getOutputPath()}}/{{#getOutputPathLocation()}}?
> * Both {{#setReportOutputDirectory(File outputDirectory)}} and
> {{#getReportOutputDirectory()}} documentation imply tha this directory solely
> refers to this single report, but that is not correct. It refers to root
> directory which contains all possibly generated reports. A shared directory,
> not exclusive one. Consider your report generates in a subdir, then these do
> *not* refer to it, but to its parent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1326] Improve (documentation on) MavenReport interface [maven-reporting-api]
kriegaex commented on PR #19: URL: https://github.com/apache/maven-reporting-api/pull/19#issuecomment-1786288822 > I believe that the last one is logically wrong. I do not think so, because it dependes on the context and the assumptions under which users read the documentation. My context is obviously different from yours, which is why you think it is logically wrong. Maybe it is also a grammatical question to some degree. I prefer "report base (...) directory" to "base report (...) directory", as the latter seems to be bad English. It is a base directory. What kind of base directory? A report base directory, not a base directory for anything else. Which is why I would order the terms that way. As for "a lot (of medicine) helps a lot" or combining the terms, making the result an even more unweildy "shared base report output directory" or "shared report base output directory" as the lesser evil, I am not sure if that might not be too subtle for most plugin developers to grasp. In such cases, a little bit of explanation usually helps, why I usually just expand the description, maybe even adding an instructive example. Precise and to the point is good, but sometimes too terse. I leave the decision up to you, but you asked "WDYT?", so these are my two cents. -- 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] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
[
https://issues.apache.org/jira/browse/MJAVADOC-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781176#comment-17781176
]
Alexander Kriegisch edited comment on MJAVADOC-560 at 10/31/23 1:07 AM:
Thanks to all of you who commented before me, trying to get to to the bottom of
this. It was quite instructive to read those comments.
Wow, that is really subtle and was not understandable for me when reading the
docs:
* {{javadoc:javadoc}} puts the javadocs into {{target/site/apidocs}} by
default, but
* {{javadoc:jar}} puts them into {{target/apidocs}}.
I really thought, that they would always end up in {{target/apidocs}} when
using the mojo stand-alone and in {{target/site/apidocs}} when creating a Maven
site only. I even modeled my own plugin after this assumption, reading the
Maven Javadoc documentation as a template. Actually, I am disappointed that the
real behaviour is different. I think, it would have made sense if a stand-alone
mojo report has another structure and output directory than a collection of
reports like a Maven site. But of course, that is arguable.
When changing any behaviour and documentation for plugin version 4 and Doxia 2,
please do not forget that for many years, users will still continue to use the
current version in their existing projects, shying away from upgrading many
dependencies, which, as I have experienced, can be a quite non-trivial
challenge in case of Doxia 2. Therefore, I plead for more precise documentation
in the currently maintained version, too.
was (Author: kriegaex):
Thanks to all of you who commented before me, trying to get to to the bottom of
this. It was quite instructive to read those comments.
Wow, that is really subtle and was not understandable for me when reading the
docs:
* {{javadoc:javadoc}} puts the javadocs into {{target/site/apidocs}} by
default, but
* {{javadoc:jar}} puths them into {{target/apidocs}}.
I really thought, that they would always end up in {{target/apidocs}} when
using the mojo stand-alone and in {{target/site/apidocs}} when creating a Maven
site only. I even modeled my own plugin after this assumption, reading the
Maven Javadoc documentation as a template. Actually, I am disappointed that the
real behaviour is different. I think,it would have made sense if a stand-alone
mojo report has another structure and output directory than a collection of
reports like a Maven site. But of course, that is arguable.
When changing any behaviour and documentation for plugin version 4 and Doxia 2,
please do not forget that for many years, users will also use the current
version in their existing projects. Therefore, I plead for more precise
documentation in the currently maintained version, too.
> Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc
> documentation
> ---
>
> Key: MJAVADOC-560
> URL: https://issues.apache.org/jira/browse/MJAVADOC-560
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0
>
>
> Looking at the documentation for javadoc:javadoc at
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I
> see three problems:
> # The documentation lists both *outputDirectory* and *reportOutputDirectory*
> parameters, having the same description. It's not clear what each one is used
> for or what happens if one property is changed without the other.
> # The default value of *outputDirectory* is listed as
> *${project.build.directory}/apidocs* but the value that is actually used is
> *${project.reporting.outputDirectory}/apidocs* (the value of
> *reportOutputDirectory*).
> # It was extremely difficult to find any documentation on
> *${project.reporting.outputDirectory}***, such as what its default value is.
> I eventually found [https://maven.apache.org/pom.html#Reporting] but Google
> does not link directly to this page/section because it doesn't contain an
> explicit reference to *${project.reporting}*.
> Suggested fix(es):
> # Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
> confusion.
> # Update the documentation so it lists the correct default value for
> *outputDirectory*.
> # Link directly from mention of *${project.reporting.outputDirectory}* to
> [https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
[
https://issues.apache.org/jira/browse/MJAVADOC-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781176#comment-17781176
]
Alexander Kriegisch edited comment on MJAVADOC-560 at 10/31/23 1:05 AM:
Thanks to all of you who commented before me, trying to get to to the bottom of
this. It was quite instructive to read those comments.
Wow, that is really subtle and was not understandable for me when reading the
docs:
* {{javadoc:javadoc}} puts the javadocs into {{target/site/apidocs}} by
default, but
* {{javadoc:jar}} puths them into {{target/apidocs}}.
I really thought, that they would always end up in {{target/apidocs}} when
using the mojo stand-alone and in {{target/site/apidocs}} when creating a Maven
site only. I even modeled my own plugin after this assumption, reading the
Maven Javadoc documentation as a template. Actually, I am disappointed that the
real behaviour is different. I think,it would have made sense if a stand-alone
mojo report has another structure and output directory than a collection of
reports like a Maven site. But of course, that is arguable.
When changing any behaviour and documentation for plugin version 4 and Doxia 2,
please do not forget that for many years, users will also use the current
version in their existing projects. Therefore, I plead for more precise
documentation in the currently maintained version, too.
was (Author: kriegaex):
Thanks to all of you who commented before me, trying to get to to the bottom of
this. It was quite instructive to read those comments.
Wow, that is really subtle and was not understandable for me when reading the
docs: {{javadoc:javadoc}} puts the javadocs into {{target/site/apidocs}} by
default, but {{javadoc:jar}} puths them into {{target/apidocs}}. I really
thought, that they would always end up in {{target/apidocs}} when using the
mojo stand-alone and in {{target/site/apidocs}} when creating a Maven site
only. I even modeled my own plugin after this assumption, reading the Maven
Javadoc documentation as a template. Actually, I am disappointed that the real
behaviour is different. I think,it would have made sense if a stand-alone mojo
report has another structure and output directory than a collection of reports
like a Maven site. But of course, that is arguable.
When changing any behaviour and documentation for plugin version 4 and Doxia 2,
please do not forget that for many years, users will also use the current
version in their existing projects. Therefore, I plead for more precise
documentation in the currently maintained version, too.
> Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc
> documentation
> ---
>
> Key: MJAVADOC-560
> URL: https://issues.apache.org/jira/browse/MJAVADOC-560
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0
>
>
> Looking at the documentation for javadoc:javadoc at
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I
> see three problems:
> # The documentation lists both *outputDirectory* and *reportOutputDirectory*
> parameters, having the same description. It's not clear what each one is used
> for or what happens if one property is changed without the other.
> # The default value of *outputDirectory* is listed as
> *${project.build.directory}/apidocs* but the value that is actually used is
> *${project.reporting.outputDirectory}/apidocs* (the value of
> *reportOutputDirectory*).
> # It was extremely difficult to find any documentation on
> *${project.reporting.outputDirectory}***, such as what its default value is.
> I eventually found [https://maven.apache.org/pom.html#Reporting] but Google
> does not link directly to this page/section because it doesn't contain an
> explicit reference to *${project.reporting}*.
> Suggested fix(es):
> # Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
> confusion.
> # Update the documentation so it lists the correct default value for
> *outputDirectory*.
> # Link directly from mention of *${project.reporting.outputDirectory}* to
> [https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-560) Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc documentation
[
https://issues.apache.org/jira/browse/MJAVADOC-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781176#comment-17781176
]
Alexander Kriegisch commented on MJAVADOC-560:
--
Thanks to all of you who commented before me, trying to get to to the bottom of
this. It was quite instructive to read those comments.
Wow, that is really subtle and was not understandable for me when reading the
docs: {{javadoc:javadoc}} puts the javadocs into {{target/site/apidocs}} by
default, but {{javadoc:jar}} puths them into {{target/apidocs}}. I really
thought, that they would always end up in {{target/apidocs}} when using the
mojo stand-alone and in {{target/site/apidocs}} when creating a Maven site
only. I even modeled my own plugin after this assumption, reading the Maven
Javadoc documentation as a template. Actually, I am disappointed that the real
behaviour is different. I think,it would have made sense if a stand-alone mojo
report has another structure and output directory than a collection of reports
like a Maven site. But of course, that is arguable.
When changing any behaviour and documentation for plugin version 4 and Doxia 2,
please do not forget that for many years, users will also use the current
version in their existing projects. Therefore, I plead for more precise
documentation in the currently maintained version, too.
> Clarify outputDirectory, reportOutputDirectory in javadoc:javadoc
> documentation
> ---
>
> Key: MJAVADOC-560
> URL: https://issues.apache.org/jira/browse/MJAVADOC-560
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0
>
>
> Looking at the documentation for javadoc:javadoc at
> [https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html] I
> see three problems:
> # The documentation lists both *outputDirectory* and *reportOutputDirectory*
> parameters, having the same description. It's not clear what each one is used
> for or what happens if one property is changed without the other.
> # The default value of *outputDirectory* is listed as
> *${project.build.directory}/apidocs* but the value that is actually used is
> *${project.reporting.outputDirectory}/apidocs* (the value of
> *reportOutputDirectory*).
> # It was extremely difficult to find any documentation on
> *${project.reporting.outputDirectory}***, such as what its default value is.
> I eventually found [https://maven.apache.org/pom.html#Reporting] but Google
> does not link directly to this page/section because it doesn't contain an
> explicit reference to *${project.reporting}*.
> Suggested fix(es):
> # Drop one of the two parameters, ideally *reportOutputDirectory*, to avoid
> confusion.
> # Update the documentation so it lists the correct default value for
> *outputDirectory*.
> # Link directly from mention of *${project.reporting.outputDirectory}* to
> [https://maven.apache.org/pom.html#Reporting]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINDEXER-206) Search Backend SMO and RR handle different Artifact.extension
[ https://issues.apache.org/jira/browse/MINDEXER-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781166#comment-17781166 ] Tamas Cservenak commented on MINDEXER-206: -- Maybe the solution is to reveal backend expectations instead? As in case of SMO we are really exposed to vendor (wrong or correct) expectations. > Search Backend SMO and RR handle different Artifact.extension > - > > Key: MINDEXER-206 > URL: https://issues.apache.org/jira/browse/MINDEXER-206 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > > The two backends should not force caller to construct Query differently, but > handle their own implementation specifics silently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINDEXER-206) Search Backend SMO and RR handle different Artifact.extension
[
https://issues.apache.org/jira/browse/MINDEXER-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781163#comment-17781163
]
Tamas Cservenak commented on MINDEXER-206:
--
Counter arguments:
* RR backend is really about (resolver level) files, so packaging here does not
makes sense
* SMO service provider requires and forces use of {{p}} for packaging, in fact,
they force it wrongfully, see {{takari-jar}} packaging.
In short, unsure is this issue is really an issue at all...
> Search Backend SMO and RR handle different Artifact.extension
> -
>
> Key: MINDEXER-206
> URL: https://issues.apache.org/jira/browse/MINDEXER-206
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 7.1.1
>
>
> The two backends should not force caller to construct Query differently, but
> handle their own implementation specifics silently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MINDEXER-207) RR backend should handle 404 gracefully
[ https://issues.apache.org/jira/browse/MINDEXER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-207: Assignee: Tamas Cservenak > RR backend should handle 404 gracefully > --- > > Key: MINDEXER-207 > URL: https://issues.apache.org/jira/browse/MINDEXER-207 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINDEXER-207) RR backend should handle 404 gracefully
[ https://issues.apache.org/jira/browse/MINDEXER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781140#comment-17781140 ] ASF GitHub Bot commented on MINDEXER-207: - cstamas merged PR #335: URL: https://github.com/apache/maven-indexer/pull/335 > RR backend should handle 404 gracefully > --- > > Key: MINDEXER-207 > URL: https://issues.apache.org/jira/browse/MINDEXER-207 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-207) RR backend should handle 404 gracefully
[ https://issues.apache.org/jira/browse/MINDEXER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-207. Resolution: Fixed > RR backend should handle 404 gracefully > --- > > Key: MINDEXER-207 > URL: https://issues.apache.org/jira/browse/MINDEXER-207 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MINDEXER-207] Handle HTTP 404 gracefully [maven-indexer]
cstamas merged PR #335: URL: https://github.com/apache/maven-indexer/pull/335 -- 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] (MINDEXER-207) RR backend should handle 404 gracefully
[ https://issues.apache.org/jira/browse/MINDEXER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781137#comment-17781137 ] ASF GitHub Bot commented on MINDEXER-207: - cstamas opened a new pull request, #335: URL: https://github.com/apache/maven-indexer/pull/335 --- https://issues.apache.org/jira/browse/MINDEXER-207 > RR backend should handle 404 gracefully > --- > > Key: MINDEXER-207 > URL: https://issues.apache.org/jira/browse/MINDEXER-207 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-207) RR backend should handle 404 gracefully
Tamas Cservenak created MINDEXER-207: Summary: RR backend should handle 404 gracefully Key: MINDEXER-207 URL: https://issues.apache.org/jira/browse/MINDEXER-207 Project: Maven Indexer Issue Type: Bug Reporter: Tamas Cservenak Fix For: 7.1.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.9 [maven-surefire]
dependabot[bot] commented on PR #680: URL: https://github.com/apache/maven-surefire/pull/680#issuecomment-1786077594 OK, I won't notify you about version 2.x.x again, unless you re-open this PR. -- 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] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.9 [maven-surefire]
dependabot[bot] closed pull request #680: Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.9 URL: https://github.com/apache/maven-surefire/pull/680 -- 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] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.9 [maven-surefire]
slachiewicz commented on PR #680: URL: https://github.com/apache/maven-surefire/pull/680#issuecomment-1786077534 @dependabot ignore this major version -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MPMD-370) Remove remaining uses of FileReader
[ https://issues.apache.org/jira/browse/MPMD-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPMD-370: Issue Type: Task (was: Bug) > Remove remaining uses of FileReader > > > Key: MPMD-370 > URL: https://issues.apache.org/jira/browse/MPMD-370 > Project: Maven PMD Plugin > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.21.1, 3.21.2 > > > This depends on default system encoding and seems likely to be buggy on some > platforms. PMD seems to write files in ISO-8859-1, at least some of the time, > but careful analysis of the file being read might be required to fix each > case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMD-382.
---
Fix Version/s: 3.21.2
(was: waiting-for-feedback)
Resolution: Fixed
Fixed with
[8f66ebdb0cf8429e989b0ccb9c2b3fc75c4c1a4c|https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=8f66ebdb0cf8429e989b0ccb9c2b3fc75c4c1a4c].
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.21.2
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution pmd of
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched
> braces in the pattern.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginMa
[jira] [Updated] (MSHARED-1330) Incremental builds fail on filtered read-only resources
[
https://issues.apache.org/jira/browse/MSHARED-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
G.Vaysman updated MSHARED-1330:
---
Description:
Under certain SCM's, such as Perforce, files under ./src are read-only. With
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a
dependency, filtered resources end up as read-only in ./target. Since filtered
resources are always updated in target, this fails with exception below. This
worked in maven-resources-plugin 2.7, but seems to break, at least, starting
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has
broken the maven-resource-plugin contract for the resources:resources (see
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make
sure src/main/resources/license.txt is read-only. Execute mvn install twice
(without "clean") . It fails on both Windows and Linux.
Further, a kind of semi-independent issue is the following: if a module
contains multiple resources, some to be filtered and others not, a typical
Maven pattern is (abridged):
{{ }}
{{ }}
{{ true}}
{{ ... }}
{{ }}
{{ }}
{{ false}}
{{ ... }}
{{ }}
{{ }}
This causes both filtered and unfiltered resources go through maven-filtering,
and it breaks incremental builds on unfiltered resources as well.
Error:
{{Caused by: java.io.FileNotFoundException:
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{ at java.io.RandomAccessFile.open0 (Native Method)}}
{{ at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:260)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:215)}}
{{ at org.apache.maven.shared.filtering.FilteringUtils.copyFile
(FilteringUtils.java:348)}}
{{ at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:104)}}
{{ at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:268)}}
{{ at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:343)}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210) }}
was:
Under certain SCM's, such as Perforce, files under ./src are read-only. With
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a
dependency, filtered resources end up as read-only in ./target. Since filtered
resources are always updated in target, this fails with exception below. This
worked in maven-resources-plugin 2.7, but seems to break, at least, starting
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has
broken the maven-resource-plugin contract for the resources:resources (see
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make
sure src/main/resources/license.txt is read-only. Execute mvn install twice
(without "clean") . It fails on both Windows and Linux.
Suggestion: please, consider passing Boolean _filtering_ all the way to
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only
one.
Error:
{{Caused by: java.io.FileNotFoundException:
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{ at java.io.RandomAccessFile.open0 (Native Method)}}
{{ at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:260)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:215)}}
{{ at org.apache.maven.shared.filtering.FilteringUtils.copyFile
(FilteringUtils.java:348)}}
{{ at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:104)}}
{{ at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:268)}}
{{ at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:343)}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210) }}
> Incremental builds fail on filtered read-only resources
> -
>
> Key: MSHARED-1330
> URL: https://issues.apache.org/jira/browse/MSHARED-1330
> Project:
[PR] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.9 [maven-surefire]
dependabot[bot] opened a new pull request, #680: URL: https://github.com/apache/maven-surefire/pull/680 Bumps org.slf4j:slf4j-simple from 1.7.36 to 2.0.9. [](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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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 at: us...@infra.apache.org
[PR] Bump org.junit:junit-bom from 5.9.3 to 5.10.0 [maven-surefire]
dependabot[bot] opened a new pull request, #679: URL: https://github.com/apache/maven-surefire/pull/679 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.9.3 to 5.10.0. Release notes Sourced from https://github.com/junit-team/junit5/releases";>org.junit:junit-bom's releases. JUnit 5.10.0 = Platform 1.10.0 + Jupiter 5.10.0 + Vintage 5.10.0 See http://junit.org/junit5/docs/5.10.0/release-notes/";>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.0-RC2...r5.10.0";>https://github.com/junit-team/junit5/compare/r5.10.0-RC2...r5.10.0 JUnit 5.10.0-RC2 = Platform 1.10.0-RC2+ Jupiter 5.10.0-RC2 + Vintage 5.10.0-RC2 See http://junit.org/junit5/docs/5.10.0-RC2/release-notes/";>Release Notes. JUnit 5.10.0-RC1 = Platform 1.10.0-RC1 + Jupiter 5.10.0-RC1 + Vintage 5.10.0-RC1 See http://junit.org/junit5/docs/5.10.0-RC1/release-notes/";>Release Notes. JUnit 5.10.0-M1 = Platform 1.10.0-M1 + Jupiter 5.10.0-M1 + Vintage 5.10.0-M1 See http://junit.org/junit5/docs/5.10.0-M1/release-notes/";>Release Notes. Commits https://github.com/junit-team/junit5/commit/7f619ca7ac9ecd1b20cc01c44a4df98f5fb67804";>7f619ca Release 5.10 https://github.com/junit-team/junit5/commit/9899de4a92520fb1b76cd1d4f2c9cd9150ebcfd1";>9899de4 Update Gradle Enterprise plugin to 3.14 https://github.com/junit-team/junit5/commit/45b970fad4ea35ae46f40c8794611d47f8f28087";>45b970f Replace soon-to-be-deprecated usages of project.buildDir https://github.com/junit-team/junit5/commit/463ae360d86837b955731df7d7fe56e9f7c155dd";>463ae36 Prune Release Notes for 5.10 GA https://github.com/junit-team/junit5/commit/893c64b47575df1d6499fb2064c81160c02e5c14";>893c64b Back to snapshots for further development https://github.com/junit-team/junit5/commit/e6ff0c53ba851e48eaf26acc39988c5c4b469580";>e6ff0c5 Release 5.10.0-RC2 https://github.com/junit-team/junit5/commit/b08a76b59f468df1dffeaae84a9bac4aa9163043";>b08a76b Add 5.10.0-RC2 release notes https://github.com/junit-team/junit5/commit/2c278c7536c0c66eb2fc04e3c8665561bae0f0a7";>2c278c7 Revert "Prune Release Notes for 5.10 GA" https://github.com/junit-team/junit5/commit/acb6e65442b39c4372d8187f240f8f4f32da56d3";>acb6e65 Provide access to source element annotations for TempDirFactory https://github.com/junit-team/junit5/commit/73818a193b7020a5c7bb3b11b1f178d8fe206462";>73818a1 Bump org.gradle.toolchains:foojay-resolver from 0.5.0 to 0.6.0 Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.9.3...r5.10.0";>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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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 at: us...@infra.apache.org
[PR] Bump org.eclipse.aether:aether-util from 1.0.0.v20140518 to 1.1.0 [maven-surefire]
dependabot[bot] opened a new pull request, #678: URL: https://github.com/apache/maven-surefire/pull/678 Bumps org.eclipse.aether:aether-util from 1.0.0.v20140518 to 1.1.0. [](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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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 at: us...@infra.apache.org
[PR] Bump org.testng:testng from 5.10 to 5.11 [maven-surefire]
dependabot[bot] opened a new pull request, #677: URL: https://github.com/apache/maven-surefire/pull/677 Bumps org.testng:testng from 5.10 to 5.11. [](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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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 at: us...@infra.apache.org
[jira] [Created] (MDEP-891) Used undeclared dependencies found for class which is used by and indirect class
Karl Heinz Marbaise created MDEP-891:
Summary: Used undeclared dependencies found for class which is
used by and indirect class
Key: MDEP-891
URL: https://issues.apache.org/jira/browse/MDEP-891
Project: Maven Dependency Plugin
Issue Type: Bug
Components: analyze-only
Affects Versions: 3.6.1, 3.6.0
Reporter: Karl Heinz Marbaise
Fix For: waiting-for-feedback
Attachments: SO-mvn-question-main.zip
Based on an example described on
[StackOverflow|https://stackoverflow.com/questions/77360885/maven-dependency-plugin-3-6-started-to-find-new-used-undeclared-dependencies]
with the example project https://github.com/DmitryTen/SO-mvn-question which
can be used as reproducer (attached that example to the issue).
The failure starts happening with {{Maven Dependency Plugin:3.6.0}}:
{code}
[INFO] --- dependency:3.6.0:analyze-only (analyze-dependencies) @ test ---
[ERROR] Used undeclared dependencies found:
[ERROR]org.springframework:spring-web:jar:5.3.5:compile
[INFO] -
{code}
If we change the version of the plugin to 3.5.0:
{code}
[INFO] --- dependency:3.5.0:analyze-only (analyze-dependencies) @ test ---
[INFO] No dependency problems found
[INFO] Copying org.example:test:pom:1.0-SNAPSHOT to project local repository
[INFO] Copying org.example:test:jar:1.0-SNAPSHOT to project local repository
[INFO] Copying org.example:test:pom:consumer:1.0-SNAPSHOT to project local
repository
[INFO]
--
{code}
After a bit more diving into it, it looks like the upgrade of the
{{maven-dependency-analyzer:1.3.2}} in release 3.6.0 of the
{{maven-dependency-plugin}}
(https://issues.apache.org/jira/projects/MDEP/versions/12352921) caused that
issue. If I use an older version of {{maven-dependency-plugin}} for example
3.5.0 and upgrade there the {{maven-dependency-analyzer:1.3.1}} it will fail
with the same output. The version {{maven-dependency-analyzer:1.3.0}} will work
fine.
I have taken a look into the code of the classes:
The class {{StandaloneVaultConfig}} which is created in the example project
uses {{AppRoleAuthentication}} which is part of
{{org.springframework.vault:spring-vault-core}}. The usage of classes from
{{org.springframework:spring-web:jar:5.3.5:compile}} happening in the class
{{AppRoleAuthentication}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSHARED-1330) Incremental builds fail on filtered read-only resources
[
https://issues.apache.org/jira/browse/MSHARED-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
G.Vaysman updated MSHARED-1330:
---
Description:
Under certain SCM's, such as Perforce, files under ./src are read-only. With
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a
dependency, filtered resources end up as read-only in ./target. Since filtered
resources are always updated in target, this fails with exception below. This
worked in maven-resources-plugin 2.7, but seems to break, at least, starting
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has
broken the maven-resource-plugin contract for the resources:resources (see
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make
sure src/main/resources/license.txt is read-only. Execute mvn install twice
(without "clean") . It fails on both Windows and Linux.
Suggestion: please, consider passing Boolean _filtering_ all the way to
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only
one.
Error:
{{Caused by: java.io.FileNotFoundException:
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{ at java.io.RandomAccessFile.open0 (Native Method)}}
{{ at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:260)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:215)}}
{{ at org.apache.maven.shared.filtering.FilteringUtils.copyFile
(FilteringUtils.java:348)}}
{{ at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:104)}}
{{ at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:268)}}
{{ at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:343)}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210) }}
was:
Under certain SCM's, such as Perforce, files under ./src are read-only. With
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a
dependency, filtered resources end up as read-only in ./target. Since filtered
resources are always updated in target, this fails with exception below. This
worked in maven-resources-plugin 2.7, but seems to break, at least, starting
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has
broken the maven-resource-plugin contract for the resources:resources (see
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make
sure src/main/resources/license.txt is read-only. Execute mvn install twice
(without "clean") . It fails on both Windows and Linux.
Suggestion: please, consider passing Boolean filtering all the way to
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only
one.Error:
{{Caused by: java.io.FileNotFoundException:
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{ at java.io.RandomAccessFile.open0 (Native Method)}}
{{ at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:260)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:215)}}
{{ at org.apache.maven.shared.filtering.FilteringUtils.copyFile
(FilteringUtils.java:348)}}
{{ at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:104)}}
{{ at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:268)}}
{{ at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:343)}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210) }}
> Incremental builds fail on filtered read-only resources
> -
>
> Key: MSHARED-1330
> URL: https://issues.apache.org/jira/browse/MSHARED-1330
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
>Reporter: G.Vaysman
>Priority: Major
> Attachments: create-license.zip
>
>
> Under certain SCM's, such as Perforce, files under ./src are read-only. With
> the latest maven-resource
[jira] [Created] (MSHARED-1330) Incremental builds fail on filtered read-only resources
G.Vaysman created MSHARED-1330:
--
Summary: Incremental builds fail on filtered read-only resources
Key: MSHARED-1330
URL: https://issues.apache.org/jira/browse/MSHARED-1330
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Reporter: G.Vaysman
Attachments: create-license.zip
Under certain SCM's, such as Perforce, files under ./src are read-only. With
the latest maven-resources-plugin (3.3.1) which has maven-filtering 3.3.1 as a
dependency, filtered resources end up as read-only in ./target. Since filtered
resources are always updated in target, this fails with exception below. This
worked in maven-resources-plugin 2.7, but seems to break, at least, starting
from maven-resources-plugin 3.0.0. Additionally note, that deprecating certain
maven-filtering methods (copyFile, etc) that take the Boolean _overwrite_ has
broken the maven-resource-plugin contract for the resources:resources (see
[https://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html).]
I am attaching a very simple project that demonstrates it. When unzipping, make
sure src/main/resources/license.txt is read-only. Execute mvn install twice
(without "clean") . It fails on both Windows and Linux.
Suggestion: please, consider passing Boolean filtering all the way to
FilteringUtils.copyFilePermissions(), and if true, do not apply the read-only
one.Error:
{{Caused by: java.io.FileNotFoundException:
D:\tmp\create-license\target\classes\license.txt (Access is denied)}}
{{ at java.io.RandomAccessFile.open0 (Native Method)}}
{{ at java.io.RandomAccessFile.open (RandomAccessFile.java:346)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:260)}}
{{ at java.io.RandomAccessFile. (RandomAccessFile.java:215)}}
{{ at org.apache.maven.shared.filtering.FilteringUtils.copyFile
(FilteringUtils.java:348)}}
{{ at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:104)}}
{{ at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:268)}}
{{ at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:343)}}
{{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)}}
{{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210) }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780992#comment-17780992
]
Alexey Loubyansky edited comment on MRESOLVER-391 at 10/30/23 3:50 PM:
---
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mentioned `dependency-scope-maven-plugin`, this and other issues referenced
from this issue wouldn't have been created if users did mean to instruct the
resolver to do what it actually did. Meaning, from the perspective of users who
created these Jira issues their instructions have been misinterpreted. There is
nothing wrong with that in principle, this happens "everywhere every time". But
let's look into what the complaint is actually about.
The issue is that, while resolving version conflicts between transitive runtime
and test dependencies, the resolver will not necessarily prioritize the runtime
versions. It's not about semantic versioning or some other compatibility hints.
It's simply about runtime transitive dependencies not being prioritized. This
leads to tests being compiled and run against a classpath that has been
manipulated by the resolver in a non-intuitive way, which may cause all the
issues described in this and other similar Jira issues. These issues appear in
user projects and have to be fixed either directly in user projects by
performing analysis and adjusting the POM or in the resolver implementation by
prioritizing the runtime transitive dependencies when resolving conflicts.
Let's explore what the option of adjusting user POMs actually means. Let's
suppose that I have a project with 50 direct dependencies (runtime + test) that
builds and runs w/o a problem. I need to update one of those direct
dependencies (a dependabot PR, a CVE fix, etc), while applying this fix I run
into this issue and I am thinking how I should fix my project config. I have a
couple of options:
1) add the overridden version of the runtime transitive dependency to the
dependencyManagement config;
2) add the overridden runtime transitive dependency as a direct runtime
dependency.
Probably either could work as a temporary workaround but none of the above is a
good long term fix. Because at some point I will be bumping the version of that
direct dependency again and the question will be what should happen to the
workaround I applied on the previous update? Assuming I will remember what I
actually did and why. It's really easy to mess it up in a big project
maintained by a team of developers applying all sorts of changes. It's a user
problem but it is a problem that could be avoided by fixing this issue in the
resolver. Let's imagine I did remember exactly what I did and why. I suppose
the changes I applied to dependency configuration as a workaround should be
reverted, the new version of the dependency I want to update should be applied
and the analysis to catch transitive runtime version overrides should be re-run
and possibly a new dependency config adjustment should be applied?
Because if I don't do that then the workaround I applied previously will remain
in my POM and will evolve on its own with version updates (from dependabot for
example) and so on.
Is this the expected workflow or am I missing something? Thanks.
was (Author: aloubyansky):
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mention
Re: [I] Mvnd fails to clean after first install was successfull [maven-mvnd]
ppalaga commented on issue #900: URL: https://github.com/apache/maven-mvnd/issues/900#issuecomment-1785206966 This kind of issues has to do with caching plugin class loaders that happen to require some files from target folders. @popcristianvlad do you know which plugin depends on XXX-encryption.jar? You could use `-Dmvnd.pluginRealmEvictPattern=mvn:org.acme:my-plugin` to avoid caching that broken plugin. See also `mvnd --help` form more info about `mvnd.pluginRealmEvictPattern` -- 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] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781014#comment-17781014
]
Sebastian Ratz edited comment on MPMD-382 at 10/30/23 1:26 PM:
---
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html],
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341|https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341]
must be sanitized as they could contain '{'.
was (Author: sratz):
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341|https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341]
must be sanitized as they could contain '{'.
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.Li
[jira] [Comment Edited] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781014#comment-17781014
]
Sebastian Ratz edited comment on MPMD-382 at 10/30/23 1:26 PM:
---
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341|https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341]
must be sanitized as they could contain '{'.
was (Author: sratz):
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341|https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L34]
must be sanitized as they could contain '{'.
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.Lif
[jira] [Comment Edited] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781014#comment-17781014
]
Sebastian Ratz edited comment on MPMD-382 at 10/30/23 1:26 PM:
---
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L341|https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L34]
must be sanitized as they could contain '{'.
was (Author: sratz):
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L34]
must be sanitized as they could contain '{'.
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMa
[jira] [Commented] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781014#comment-17781014
]
Sebastian Ratz commented on MPMD-382:
-
This particular case has nothing to do with any XML.
In this case, had something like
{code:java}
void foo throws Exception { // PMD {
}{code}
resulting in
{code:xml}
{code}
and it was bad luck / coincidence that the user message contained a literal {
Anyways, all values passed to
[https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReportRenderer.html,]
e.g.
[https://github.com/apache/maven-pmd-plugin/blob/a7fcb381afcb5b35da6c1bcbccdfcb89465e6e08/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L34]
must be sanitized as they could contain '{'.
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.
Re: [PR] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-pmd-plugin]
dependabot[bot] commented on PR #136: URL: https://github.com/apache/maven-pmd-plugin/pull/136#issuecomment-1785149171 OK, I won't notify you about version 4.x.x again, unless you re-open this PR. -- 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] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-pmd-plugin]
dependabot[bot] closed pull request #136: Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 URL: https://github.com/apache/maven-pmd-plugin/pull/136 -- 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] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-pmd-plugin]
slawekjaranowski commented on PR #136: URL: https://github.com/apache/maven-pmd-plugin/pull/136#issuecomment-1785149079 @dependabot ignore this major version -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780992#comment-17780992
]
Alexey Loubyansky commented on MRESOLVER-391:
-
> There is no "production part" of "test" graph.
I should really have used *runtime* instead of {*}production{*}.
> Graph is this or that, not both, should not be assumed "overlapping".
I agree with that. I don't think though that how a graph is resolved currently
is how it should be done.
> When one asks resolver to collect (or resolve), resolver will perform based
> on input. And the result is either this or that, but not both.
Right, also agreed.
> Hence, this issue should be more like a "discussion" to decide what is right
> behavior of resolver in these cases
No problem with that either.
> for sure there are some edge cases (like silent version bump from 1.x to
> 2.x), but still, it does happen per user instruction (who authors POM)
Well, kind of... This needs to be clarified though.
The mentioned `dependency-scope-maven-plugin`, this and other issues referenced
from this issue wouldn't have been created if users did mean to instruct the
resolver to do what it actually did. Meaning, from the perspective of users who
created these Jira issues their instructions have been misinterpreted. There is
nothing wrong with that in principle, this happens "everywhere every time". But
let's look into what the complaint is actually about.
The issue is that, while resolving version conflicts between transitive runtime
and test dependencies, the resolver will not necessarily prioritize the runtime
versions. It's not about semantic versioning or some other compatibility hints.
It's simply about runtime transitive dependencies not being prioritized. This
leads to tests being compiled and run against a classpath that has been
manipulated by the resolver in a non-intuitive way, which may cause all the
issues described in this and other similar Jira issues. These issues appear in
user projects and have to be fixed either directly in user projects by
performing analysis and adjusting the POM or in the resolver implementation by
prioritizing the runtime transitive dependencies when resolving conflicts.
Let's explore what the option of adjusting user POMs actually means. Let's
suppose that I have a project with 50 direct dependencies (runtime + test) that
builds and runs w/o a problem. I need to update one of those direct
dependencies (a dependabot PR, a CVE fix, etc), while applying this fix I run
into this issue and I am thinking how I should fix my project config. I have a
couple of options:
1) add the overridden version of the runtime transitive dependency to the
dependencyManagement config;
2) add the overridden runtime transitive dependency as a direct runtime
transitive dependency.
Probably either could work as a temporary workaround but none of the above is a
good long term fix. Because at some point I will be bumping the version of that
direct dependency again and the question will be what should happen to the
workaround I applied on the previous update? Assuming I will remember what I
actually did and why. It's really easy to mess it up in a big project
maintained by a team of developers applying all sorts of changes. It's a user
problem but it is a problem that could be avoided by fixing this issue in the
resolver. Let's imagine I did remember exactly what I did and why. I suppose
the changes I applied to dependency configuration as a workaround should be
reverted, the new version of the dependency I want to update should be applied
and the analysis to catch transitive runtime version overrides should be re-run
and possibly a new dependency config adjustment should be applied?
Because if I don't do that then the workaround I applied previously will remain
in my POM and will evolve on its own with version updates (from dependabot for
example) and so on.
Is this the expected workflow or am I missing something? Thanks.
> Scope mediation improvements
>
>
> Key: MRESOLVER-391
> URL: https://issues.apache.org/jira/browse/MRESOLVER-391
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Original issue description was: "As per MNG-5988: if an artifact in "test"
> scope is found nearer, but in scope "compile" is found deeper in graph, the
> "test" scope wins. This at runtime may lead to CNFEx."
> This is completely wrong premise, and it contains following false assumptions:
> * The "test" classpath is superset of "runtime" classpath. Is not.
> * (derived from that above) To get "runtime" classpath collect via resolver
> "test" classpath and cherry-pick non-"test" (or filter out "test") scoped
[jira] [Commented] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780968#comment-17780968
]
Michael Osipov commented on MPMD-382:
-
[~sratz], can you provide the XML file in question which is failing for you?
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution pmd of
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched
> braces in the pattern.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:133)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> a
[PR] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-pmd-plugin]
dependabot[bot] opened a new pull request, #136: URL: https://github.com/apache/maven-pmd-plugin/pull/136 Bumps [org.codehaus.plexus:plexus-xml](https://github.com/codehaus-plexus/plexus-xml) from 3.0.0 to 4.0.2. Release notes Sourced from https://github.com/codehaus-plexus/plexus-xml/releases";>org.codehaus.plexus: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 4.0.0 Use spotless (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/8";>#8) https://github.com/gnodet";>@gnodet Fix site generation (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/15";>#15) https://github.com/gnodet";>@gnodet Switch build ci workflow to master branch (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/14";>#14) https://github.com/gnodet";>@gnodet Fix SCM urls (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/13";>#13) https://github.com/gnodet";>@gnodet MXParser tokenization fails when PI is before first tag (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/7";>#7) (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/12";>#12) https://github.com/gnodet";>@gnodet Deprecate Xpp3DomUtils (fixes https://redirect.github.com/codehaus-plexus/plexus-xml/issues/6";>#6) (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/9";>#9) https://github.com/gnodet";>@gnodet Use a ArrayDeque (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/5";>#5) https://github.com/gnodet";>@gnodet Upgrade plugins and clean build warnings (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/4";>#4) https://github.com/gnodet";>@gnodet Switch to junit 5 (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/2";>#2) https://github.com/gnodet";>@gnodet Fix parsing an UTF-8 file without BOM and ISO-8859-1 encoding (https://redirect.github.com/codehaus-plexus/plexus-xml/pull/1";>#1) https://github.com/gnodet";>@gnodet 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 https://github.com/codehaus-plexus/plexus-xml/commit/cac55e8c167b168c6c36dd4a057dedfadec03c0e";>cac55e8 [maven-release-plugin] prepare release plexus-xml-4.0.0 https://github.com/codehaus-plexus/plexus-xml/commit/17787e5ff7dea8acf347fd3f92bd855e110d6dfe";>17787e5 Reformat using spotless Additional commits viewable in https://github.com/codehaus-plexus/plexus-xml/compare/plexus-xml-3.0.0...plexus-xml-4.0.2";>compare view [ on a multi-module project consisting of 100+ modules. On linux, everything works fine. I can run `mvnd clean install` countless times, all looking good. I even notice a 10% improvement in the total execution time. On windows, however, the behavior is different. After I run a successful `mvnd clean install`, running a simple `mvnd clean` fails because some of the .jar files from some modules cannot be deleted. In order to recover from it, I have two options: - stop the mvnd and try again - run the `mvnd clean` on the specific module that fails I mention that I didn't modify mvnd.properties. The exception I receive when executing `mvnd clean` is: > [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 49.345 s (Wall Clock) [INFO] Finished at: 2023-10-30T10:29:46+02:00 [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:3.2.0:clean (default-clean) on project XXX-encryption: Failed to clean project: Failed to delete C:\XXX\XXX\XXX\target\XXX-encryption.jar -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:3.2.0:clean (default-clean) on project XXX-encryption: Failed to clean project: Failed to delete C:\XXX\XXX\XXX\target\XXX-encryption.jar at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:333) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) 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:75) 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:105) at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:209) at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run (SmartBuilderImpl.java:81) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:624) at java.lang.Thread.run (Thread.java:748) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to clean project: Failed to delete C:\XXX\XXX\XXX\target\XXX-encryption.jar at org.apache.maven.plugins.clean.CleanMojo.execute (CleanMojo.java:288) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316) 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:75) 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:105) at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:209) at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run (SmartBuilderImpl.java:81) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511) at java.util.concurrent.FutureTask.run (FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.r
[jira] [Commented] (MPMD-382) Regression in report rendering
[
https://issues.apache.org/jira/browse/MPMD-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780955#comment-17780955
]
Sebastian Ratz commented on MPMD-382:
-
We are running into the same issue in our code base. Stack trace:
{noformat}
Caused by: java.lang.IllegalArgumentException: Unmatched braces in the pattern.
at org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern
(AbstractMavenReportRenderer.java:714)
at org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText
(AbstractMavenReportRenderer.java:512)
at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell
(AbstractMavenReportRenderer.java:312)
at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell
(AbstractMavenReportRenderer.java:287)
at org.apache.maven.reporting.AbstractMavenReportRenderer.tableRow
(AbstractMavenReportRenderer.java:335)
at
org.apache.maven.plugins.pmd.PmdReportRenderer.renderSuppressedViolations
(PmdReportRenderer.java:341)
at org.apache.maven.plugins.pmd.PmdReportRenderer.renderBody
(PmdReportRenderer.java:132)
at org.apache.maven.reporting.AbstractMavenReportRenderer.render
(AbstractMavenReportRenderer.java:82)
at org.apache.maven.plugins.pmd.PmdReport.executeReport (PmdReport.java:308)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at org.apache.maven.reporting.AbstractMavenReport.execute
(AbstractMavenReport.java:166)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
...
{noformat}
> Regression in report rendering
> --
>
> Key: MPMD-382
> URL: https://issues.apache.org/jira/browse/MPMD-382
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Krystian Panek
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> recent release of the plugin does not work for me - 3.21.0
> but the version before works - 3.20.0
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd (pmd) on project
> acme.core: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.21.0:pmd failed: Unmatched braces
> in the pattern.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> 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:75)
> 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.MojoExecutor.executeForkedExecutions
> (MojoExecutor.java:448)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:311)
> 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:75)
> 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:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.m
[jira] [Updated] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-391: -- Description: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * The "test" classpath is superset of "runtime" classpath. Is not. * (derived from that above) To get "runtime" classpath collect via resolver "test" classpath and cherry-pick non-"test" (or filter out "test") scoped nodes. This is not how it works. * A collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime..."). There is no "production part" of "test" graph. Graph is this or that, not both, should not be assumed "overlapping". When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). was: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * The "test" classpath is superset of "runtime" classpath. Is not. * (derived from that above) To get "runtime" classpath collect via resolver "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped nodes. This is not how it works. * A collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime..."). There is no "production part" of "test" graph. Graph is this or that, not both, should not be assumed "overlapping". When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there
[jira] [Updated] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-391: -- Description: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * The "test" classpath is superset of "runtime" classpath. Is not. * (derived from that above) To get "runtime" classpath collect via resolver "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped nodes. This is not how it works. * A collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime..."). There is no "production part" of "test" graph. Graph is this or that, not both, should not be assumed "overlapping". When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). was: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * "test" classpath is superset of "runtime" classpath * (derived from that above) to get "runtime" classpath collect via resolver "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped nodes * a collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime...") When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not
[jira] [Updated] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-391: -- Description: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * "test" classpath is superset of "runtime" classpath * (derived from that above) to get "runtime" classpath collect via resolver "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped nodes * a collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime...") When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). was: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * "test" classpath is superset of "runtime" classpath * (derived from that above) to get "runtime" classpath collect via resolver "test" classpath and cherrty-pick (or filter out) "test" scoped nodes * a collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime...") When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * "test" classpath is superset of "runtime" classpath > * (derived from that above) to get "runtime" classpath collect via resolver > "test" classpath and cherrty-pick non-"test" (or filter out "test") scoped > nodes > * a collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime...") > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-391: -- Description: Original issue description was: "As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx." This is completely wrong premise, and it contains following false assumptions: * "test" classpath is superset of "runtime" classpath * (derived from that above) to get "runtime" classpath collect via resolver "test" classpath and cherrty-pick (or filter out) "test" scoped nodes * a collected graph can contain both, "test" and "runtime" classpath (implied with "test scope wins but at runtime...") When one asks resolver to collect (or resolve), resolver will perform based on input. And the result is either this or that, but not both. In fact, the collected "dirty tree" (graph) cannot even represent both "test" or "runtime" at the same time! The reproducers in this issue are actually precise examples showing why it is impossible. Hence, this issue should be more like a "discussion" to decide what is right behavior of resolver in these cases, as for sure there are some edge cases (like silent version bump from 1.x to 2.x), but still, it does happen per user instruction (who authors POM), and Resolver does not want to delve into "compatibility calculation" space, where it can decide is a change "compatible" or not (like semver and alike). was:As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope "compile" is found deeper in graph, the "test" scope wins. This at runtime may lead to CNFEx. > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * "test" classpath is superset of "runtime" classpath > * (derived from that above) to get "runtime" classpath collect via resolver > "test" classpath and cherrty-pick (or filter out) "test" scoped nodes > * a collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime...") > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [I] mvnd 0.9.0 "destroys" the console [maven-mvnd]
aalmiray commented on issue #884: URL: https://github.com/apache/maven-mvnd/issues/884#issuecomment-1784859147 JReleaser can certainly help. As @johanjanssen mentioned the use of tags is tricky. I know for a fact that M and RC are treated specially, don't know about BETA and ALPHA. Moreover, as Johan has states he'll no longer support the choco package someone else must take on the task. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.codehaus.plexus:plexus-utils from 1.0.4 to 3.0.24 in /surefire-its/src/test/resources/plexus-conflict [maven-surefire]
dependabot[bot] opened a new pull request, #676: URL: https://github.com/apache/maven-surefire/pull/676 Bumps [org.codehaus.plexus:plexus-utils](https://github.com/codehaus-plexus/plexus-utils) from 1.0.4 to 3.0.24. Commits See full diff in https://github.com/codehaus-plexus/plexus-utils/commits/plexus-utils-3.0.24";>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 show ignore conditions` will show all of the ignore conditions of the specified dependency - `@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) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-surefire/network/alerts). -- 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] (SUREFIRE-2206) Downgrade plexus-xml to 3.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780911#comment-17780911 ] ASF GitHub Bot commented on SUREFIRE-2206: -- slawekjaranowski merged PR #675: URL: https://github.com/apache/maven-surefire/pull/675 > Downgrade plexus-xml to 3.0.0 > - > > Key: SUREFIRE-2206 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2206 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: version-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2206) Downgrade plexus-xml to 3.0.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed SUREFIRE-2206. - Resolution: Fixed > Downgrade plexus-xml to 3.0.0 > - > > Key: SUREFIRE-2206 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2206 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: version-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2206] Downgrade plexus-xml to 3.0.0 [maven-surefire]
slawekjaranowski merged PR #675: URL: https://github.com/apache/maven-surefire/pull/675 -- 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-391) Scope mediation improvements
[
https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780907#comment-17780907
]
Alexey Loubyansky commented on MRESOLVER-391:
-
[~cstamas] right, I think the problem in this case is in "how the winner is
selected".
As a developer, I want to make sure my tests are using a classpath that is as
close to the production one as possible. I want to be able to modify it for
tests to add alternative implementations of some services or interfaces - true.
But I want to be in control of that when that happens, by adding those
dependencies as direct dependencies with versions I set explicitly, for example.
Of course, there are tools I can configure and run to make sure I (or rather
the Maven resolver) don't accidentally re-arrange *the production part of my
test classpath* that *I don't expect to be re-arranged* when bumping some
library versions (e.g. following a dependabot updates, etc). I am arguing these
tools should not be needed, they are a workaround for an issue that needs to be
fixed.
[~perdjesk] mentioned
[https://github.com/basepom/maven-plugins/blob/main/dependency-scope/README-hubspot.md.]
Here is a quote from it's readme explaining why it was developed and what it
solves:
{noformat}
This plugin aims to mitigate a particular pesky problem with Maven which is
that if you declare a dependency with test scope, that will take precedence
over a transitive dependency with compile scope.
This plugin attempts to mitigate this problem by verifying that test-scoped
dependencies don't appear elsewhere in your dependency tree at scope runtime or
compile.{noformat}
It's a safety measure. I believe most of the users aren't aware of this issue
until they start running into unexpected behavior in production that they don't
observe in their tests. It's not intuitive and even with the tools that help
with analysis, applying fixes by adding *the original transitive compile
dependency versions* to the dependencyManagement or as direct dependencies is
cumbersome and complicates maintenance of the project from that point on
(basically, until the next round of version updates, since then I'd have to
re-do the analysis by reverting the previous "compensations" in
dependencyManagement and apply a new more relevant one).
> Scope mediation improvements
>
>
> Key: MRESOLVER-391
> URL: https://issues.apache.org/jira/browse/MRESOLVER-391
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope
> "compile" is found deeper in graph, the "test" scope wins. This at runtime
> may lead to CNFEx.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] mvnd 0.9.0 "destroys" the console [maven-mvnd]
johanjanssen commented on issue #884: URL: https://github.com/apache/maven-mvnd/issues/884#issuecomment-1784740197 I think Chocolatey doesn't support beta/milestone version information in their tags. So to solve this I think I would need to create a new Chocolatey package with a different id, something like mvnd-beta. Or are there other ways? Next to that I already indicated that I want to stop maintaining the Chocolatey package, as I don't use them myself anymore. So if someone wants to take over, let me know. I'm happy to maintain it until the end of the year, but after that I won't do it anymore. -- 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: [I] mvnd 0.9.0 "destroys" the console [maven-mvnd]
OLibutzki commented on issue #884: URL: https://github.com/apache/maven-mvnd/issues/884#issuecomment-1784710330 Afaik, @johanjanssen provided the choco packages so far. Maybe he can help? -- 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] Fix CVE-2021-26291: Bump Maven from 3.2.5 to 3.9.5 [maven-compiler-plugin]
yotamc-ms closed pull request #206: Fix CVE-2021-26291: Bump Maven from 3.2.5 to 3.9.5 URL: https://github.com/apache/maven-compiler-plugin/pull/206 -- 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-716) The stale file detection does not work
[
https://issues.apache.org/jira/browse/MJAVADOC-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780880#comment-17780880
]
ASF GitHub Bot commented on MJAVADOC-716:
-
michael-o commented on PR #144:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/144#issuecomment-1784650346
> I think so.
Can you rebase and merge?
> The stale file detection does not work
> --
>
> Key: MJAVADOC-716
> URL: https://issues.apache.org/jira/browse/MJAVADOC-716
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Priority: Major
>
> I always end up with {{Configuration changed, re-generating javadoc.}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAVADOC-716] Fix stale files detection failing because of the newline [maven-javadoc-plugin]
michael-o commented on PR #144: URL: https://github.com/apache/maven-javadoc-plugin/pull/144#issuecomment-1784650346 > I think so. Can you rebase and merge? -- 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
