Re: [PR] [MNG-8179] Upgrade Parent to 43 [maven]
slawekjaranowski commented on PR #1610: URL: https://github.com/apache/maven/pull/1610#issuecomment-190324 failed build on jenkins was for branch ... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8179) Upgrade Parent to 43
[ https://issues.apache.org/jira/browse/MNG-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864942#comment-17864942 ] ASF GitHub Bot commented on MNG-8179: - slawekjaranowski commented on PR #1610: URL: https://github.com/apache/maven/pull/1610#issuecomment-190324 failed build on jenkins was for branch ... > Upgrade Parent to 43 > > > Key: MNG-8179 > URL: https://issues.apache.org/jira/browse/MNG-8179 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 3.9.9 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8179] Upgrade Parent to 43 [maven]
slawekjaranowski merged PR #1610: URL: https://github.com/apache/maven/pull/1610 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-8179) Upgrade Parent to 43
[ https://issues.apache.org/jira/browse/MNG-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MNG-8179. Resolution: Fixed > Upgrade Parent to 43 > > > Key: MNG-8179 > URL: https://issues.apache.org/jira/browse/MNG-8179 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 3.9.9 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-99) Project checksum fails to identify moved files in certain cases
Amir Hadadi created MBUILDCACHE-99: -- Summary: Project checksum fails to identify moved files in certain cases Key: MBUILDCACHE-99 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-99 Project: Maven Build Cache Extension Issue Type: Bug Affects Versions: 1.2.0 Reporter: Amir Hadadi Input files checksum is calculated by sorting all files and using their content (but not their path) to update a checksum. Let's say that there are 2 files named A,B and B gets renamed to C. Since the order of the files didn't change and the contents of the files didn't change, the input files checksum remains the same. The solution is to include the normalized file path in the file checksum calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] The project builder should be given the correct system properties [maven-project-info-reports-plugin]
michael-o commented on PR #75: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/75#issuecomment-263809 Let me know how to process with my proposed patch. I would create a release today for this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] [MBUILDCACHE-99] Project checksum fails to identify moved files in certain cases [maven-build-cache-extension]
amirhadadi opened a new pull request, #161: URL: https://github.com/apache/maven-build-cache-extension/pull/161 Input files checksum is calculated by sorting all files and using their content (but not their path) to update a checksum. This means that if a file is moved or renamed in a way that doesn't change its location in the list of sorted files, the input files checksum will not change. This change adds the file's path to the checksum. Following this checklist to help us incorporate your contribution quickly and easily: - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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] (MBUILDCACHE-99) Project checksum fails to identify moved files in certain cases
[ https://issues.apache.org/jira/browse/MBUILDCACHE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated MBUILDCACHE-99: -- Labels: pull-request-available (was: ) > Project checksum fails to identify moved files in certain cases > --- > > Key: MBUILDCACHE-99 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-99 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Amir Hadadi >Priority: Major > Labels: pull-request-available > > Input files checksum is calculated by sorting all files and using their > content (but not their path) to update a checksum. > Let's say that there are 2 files named A,B and B gets renamed to C. Since the > order of the files didn't change and the contents of the files didn't change, > the input files checksum remains the same. > The solution is to include the normalized file path in the file checksum > calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-99) Project checksum fails to identify moved files in certain cases
[ https://issues.apache.org/jira/browse/MBUILDCACHE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864961#comment-17864961 ] ASF GitHub Bot commented on MBUILDCACHE-99: --- amirhadadi opened a new pull request, #161: URL: https://github.com/apache/maven-build-cache-extension/pull/161 Input files checksum is calculated by sorting all files and using their content (but not their path) to update a checksum. This means that if a file is moved or renamed in a way that doesn't change its location in the list of sorted files, the input files checksum will not change. This change adds the file's path to the checksum. Following this checklist to help us incorporate your contribution quickly and easily: - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) > Project checksum fails to identify moved files in certain cases > --- > > Key: MBUILDCACHE-99 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-99 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Amir Hadadi >Priority: Major > > Input files checksum is calculated by sorting all files and using their > content (but not their path) to update a checksum. > Let's say that there are 2 files named A,B and B gets renamed to C. Since the > order of the files didn't change and the contents of the files didn't change, > the input files checksum remains the same. > The solution is to include the normalized file path in the file checksum > calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8052] New Lifecycle API [maven]
gnodet closed pull request #1411: [MNG-8052] New Lifecycle API URL: https://github.com/apache/maven/pull/1411 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8052) Define a new lifecycle for Maven 4
[
https://issues.apache.org/jira/browse/MNG-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864964#comment-17864964
]
ASF GitHub Bot commented on MNG-8052:
-
gnodet closed pull request #1411: [MNG-8052] New Lifecycle API
URL: https://github.com/apache/maven/pull/1411
> Define a new lifecycle for Maven 4
> --
>
> Key: MNG-8052
> URL: https://issues.apache.org/jira/browse/MNG-8052
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The idea would be to redefine a maven lifecycle as being defined by:
> {{Lifecycle}}:
> * id: unique identifier
> * set of Phase
> {{Step}}:
> * optional name
> * optional mojo execution
> * list of predecessors and successors for the current project
> * list of predecessors and successors for dependencies
> * list of predecessors and successors for child modules
> Default lifecycle could be defined by a set of empty steps:
> * {{initialize}}
> * {{{}resources{}}}: requires {{initialize}}
> * {{{}sources{}}}: requires {{initialize}}
> * {{{}compile{}}}: requires {{sources}}
> * {{{}ready{}}}: requires {{resources, compile}}
> * {{{}build{}}}: requires {{ready}}
> * {{{}test{}}}: requires {{compile}}
> * {{{}package{}}}: requires {{build, test}}
> * {{{}integration-test{}}}: requires {{package}}
> * {{{}verify{}}}: requires {{test, integration-test}}
> and a set of steps bound to plugin executions
> * {{m-resources-p}} required by {{resources}}
> * {{m-compiler-p}} required by {{{}compile{}}}, requires {{sources}} and
> dependencies at {{ready}}
> * {{m-surefire-p}} required by {{test}}
> * {{m-jar-p}} required by {{build}}
> * {{m-failsafe-p}} required by {{integration-test}}
> The {{build}} phase would be introduced to have packaged artifacts without
> running any tests. The {{ready}} phase would be introduced to allow (if
> needed) a small difference between being {{{}compile{}}}'d and being
> {{{}package{}}}'d: simple jars can be used as dependencies when they are only
> compiled (using target/classes), but if you use a custom package (for example
> {{{}m-shade-p{}}}), you cannot use the compiled classes directly, but you
> need the processed classes. In such a case, the {{m-shade-p}} should be
> required by {{ready}} and should require {{{}m-jar-p{}}}.
> This would allow:
> * injecting a given plugin into an existing chain: a custom generation step
> is modelled with: {{m-generator-plugin}} required by {{sources}}
> * a post packaging phase would be defined with: {{my-plugin}}: requires
> {{m-jar-p}}, required by {{packaging}}
> * running {{mvn build}} to build all jars without running any tests
> * running {{mvn -amd test}} (or something similar) would allow building the
> given project with the full graph (i.e. with all dependencies at {{ready}}
> phase
> * this immediately gives a full graph that can be built concurrently down to
> the mojo level
> * the ability to add predecessors onto children' modules phases allow
> defining aggregate goals more easily
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MPMD-400] (doc) Fix doc URL for PMD 7.3.0 [maven-pmd-plugin]
adangel opened a new pull request, #160: URL: https://github.com/apache/maven-pmd-plugin/pull/160 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPMD-400) Upgrade to PMD 7.3.0
[ https://issues.apache.org/jira/browse/MPMD-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864973#comment-17864973 ] ASF GitHub Bot commented on MPMD-400: - adangel opened a new pull request, #160: URL: https://github.com/apache/maven-pmd-plugin/pull/160 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). > Upgrade to PMD 7.3.0 > > > Key: MPMD-400 > URL: https://issues.apache.org/jira/browse/MPMD-400 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.24.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] (doc) Update release notes for 3.23.0 and 3.24.0 [maven-pmd-plugin]
adangel opened a new pull request, #161: URL: https://github.com/apache/maven-pmd-plugin/pull/161 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864977#comment-17864977 ] ASF GitHub Bot commented on MNG-8180: - cstamas opened a new pull request, #1611: URL: https://github.com/apache/maven/pull/1611 Resolver handles transparently the repository metadata, and in case of plugins it peeks into META-INF/maven/plugin.xml of given artifact JAR to figure out needed metadata bits (prefix, name, etc). But, this was done "blindly", while it is expected that GA of JAR artifact without classifier (requirement for maven plugins) and GA in embedded plugin metadata must be same. Decision here is to fail hard, prevent this being installed and deployed, as this is most probably wrong (unsure what maven-indexer or even Sonatype search would do in this case). --- https://issues.apache.org/jira/browse/MNG-8180 > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-383) PMD should fail when there is a processing error
[
https://issues.apache.org/jira/browse/MPMD-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864978#comment-17864978
]
Andreas Dangel commented on MPMD-383:
-
OP is running the check goal:
{quote}[2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
(pmd-check) < :pmd @ mod-config-client-cst <<<
{quote}
Currently this parameter is defined in PmdReport (see
[https://github.com/apache/maven-pmd-plugin/blob/4f5ba977ae3f2f2f24a6c860b543e881b13de005/src/main/java/org/apache/maven/plugins/pmd/PmdReport.java#L153-L159])
{quote}I do not expect a reporting goal to fail here.
{quote}
Maybe, maybe not. If there are processing errors during PMD analysis, then the
report most likely is {*}incomplete{*}. That means, it might miss violations in
one or more files. You could define, that an incomplete report is an error and
shouldn't be considered further (fail immediately).
You could also define, that an incomplete report is better than no report at
all and continue and fail later (e.g. in check).
>From the end user perspective, the user wants to know, if he can trust the PMD
>report (no processing errors, it is complete) or not (there are processing
>errors, potentially incomplete report). And if the PMD result is a potentially
>incomplete report, fail the build. Whether this happens immediately or later
>probably doesn't matter.
Failing the build later (in check) has the potential advantage, that the
processing errors can be displayed in the rendered report (which is happening
in
[https://github.com/apache/maven-pmd-plugin/blob/4f5ba977ae3f2f2f24a6c860b543e881b13de005/src/main/java/org/apache/maven/plugins/pmd/PmdReportRenderer.java#L391]
already). However, this is only possible, if "skipPmdError" is true (as
otherwise the report wouldn't be generated at all, e.g. mvn site would fail as
well).
> PMD should fail when there is a processing error
>
>
> Key: MPMD-383
> URL: https://issues.apache.org/jira/browse/MPMD-383
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Thomas Nikolay
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: image-2023-07-28-13-34-28-717.png
>
>
> We had the case that PMD can't process some processing error but the build
> does not fail.
>
> {noformat}
> [2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
> mod-config-client-cst ---
> [2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
> [2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
> GK-SAP-ApacheLoggerDeniedRule cause: missing value
> [2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
> [2023-07-28T10:59:45.672Z] [WARNING]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
> [2023-07-28T10:59:45.948Z] [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [2023-07-28T10:59:46.210Z] [INFO]
> [2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
> (pmd-check) < :pmd @ mod-config-client-cst <<<
> {noformat}
>
> My expectation would be that the build failed when there a processing errors.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-383) PMD should fail when there is a processing error
[
https://issues.apache.org/jira/browse/MPMD-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864990#comment-17864990
]
Michael Osipov commented on MPMD-383:
-
[~adangel], I agree with you. fail fast, even in a report.
> PMD should fail when there is a processing error
>
>
> Key: MPMD-383
> URL: https://issues.apache.org/jira/browse/MPMD-383
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Thomas Nikolay
>Priority: Critical
> Fix For: waiting-for-feedback
>
> Attachments: image-2023-07-28-13-34-28-717.png
>
>
> We had the case that PMD can't process some processing error but the build
> does not fail.
>
> {noformat}
> [2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
> mod-config-client-cst ---
> [2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
> [2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
> GK-SAP-ApacheLoggerDeniedRule cause: missing value
> [2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
> [2023-07-28T10:59:45.672Z] [WARNING]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
> [2023-07-28T10:59:45.948Z] [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [2023-07-28T10:59:46.210Z] [INFO]
> [2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
> (pmd-check) < :pmd @ mod-config-client-cst <<<
> {noformat}
>
> My expectation would be that the build failed when there a processing errors.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPMD-383) PMD should fail when there is a processing error
[
https://issues.apache.org/jira/browse/MPMD-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPMD-383:
Fix Version/s: (was: waiting-for-feedback)
> PMD should fail when there is a processing error
>
>
> Key: MPMD-383
> URL: https://issues.apache.org/jira/browse/MPMD-383
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Thomas Nikolay
>Priority: Critical
> Attachments: image-2023-07-28-13-34-28-717.png
>
>
> We had the case that PMD can't process some processing error but the build
> does not fail.
>
> {noformat}
> [2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
> mod-config-client-cst ---
> [2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
> [2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
> GK-SAP-ApacheLoggerDeniedRule cause: missing value
> [2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
> [2023-07-28T10:59:45.672Z] [WARNING]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
> [2023-07-28T10:59:45.948Z] [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [2023-07-28T10:59:46.210Z] [INFO]
> [2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
> (pmd-check) < :pmd @ mod-config-client-cst <<<
> {noformat}
>
> My expectation would be that the build failed when there a processing errors.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-383) PMD should fail when there is a processing error
[
https://issues.apache.org/jira/browse/MPMD-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864992#comment-17864992
]
Michael Osipov commented on MPMD-383:
-
We also have
https://github.com/apache/maven-pmd-plugin/blob/4f5ba977ae3f2f2f24a6c860b543e881b13de005/src/main/java/org/apache/maven/plugins/pmd/PmdReport.java#L184-L194C21
> PMD should fail when there is a processing error
>
>
> Key: MPMD-383
> URL: https://issues.apache.org/jira/browse/MPMD-383
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Thomas Nikolay
>Priority: Critical
> Attachments: image-2023-07-28-13-34-28-717.png
>
>
> We had the case that PMD can't process some processing error but the build
> does not fail.
>
> {noformat}
> [2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
> mod-config-client-cst ---
> [2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
> [2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
> GK-SAP-ApacheLoggerDeniedRule cause: missing value
> [2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
> [2023-07-28T10:59:45.672Z] [WARNING]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
> [2023-07-28T10:59:45.948Z] [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [2023-07-28T10:59:46.210Z] [INFO]
> [2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
> (pmd-check) < :pmd @ mod-config-client-cst <<<
> {noformat}
>
> My expectation would be that the build failed when there a processing errors.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864993#comment-17864993 ] ASF GitHub Bot commented on MNG-8180: - cstamas opened a new pull request, #1612: URL: https://github.com/apache/maven/pull/1612 Resolver handles transparently the repository metadata, and in case of plugins it peeks into META-INF/maven/plugin.xml of given artifact JAR to figure out needed metadata bits (prefix, name, etc). But, this was done "blindly", while it is expected that GA of JAR artifact without classifier (requirement for maven plugins) and GA in embedded plugin metadata must be same. Decision here is to fail hard, prevent this being installed and deployed, as this is most probably wrong (unsure what maven-indexer or even Sonatype search would do in this case). --- https://issues.apache.org/jira/browse/MNG-8180 > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8180: - Fix Version/s: 4.0.0-beta-4 3.9.9 (was: 4.0.x-candidate) (was: 3.9.x-candidate) > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8180: - Description: Resolver will generate plugin metadata based on contents of META-INF/maven/plugins.xml file, that for example in case of shaded JAR may be totally off. Circumvention: exclude this file from JAR. All Maven 3.9.x and 4.x are affected. Solution: the Artifact (checked for: has no classifier and is backed by JAR, the requirements for maven-plugin JAR) and the embedded plugin metadata MUST BE aligned (artifact GA == metadata GA). In this case all is happening as before, happy path. In case of artifact GA != metadata GA we HARD FAIL the build, as deploying "formally adhering to maven plugin JAR with rogue metadata" may be very misleading. Most probably the origin of "rogue" plugin metadata is by shading (like in case of Tika), or by some other rogue resource, or even someone "reinventing" the plugin metadata for some other purposes. Maven should simply prevent install/deploy of artifacts like these, and users should fix the artifact (in case of shading, exclude that resource, in other cases figure out from where it comes and eliminate it). More context: in Maven3 this is most we can do, as repository metadata generation happens in maven-resolver-provider module that does not and cannot depend on maven-core (is "pure" resolver), hence notion of packaging, project, build etc is not available. In Maven4 with new API we MAY do something more. was: Resolver will generate plugin metadata based on contents of META-INF/maven/plugins.xml file, that for example in case of shaded JAR may be totally off. Circumvention: exclude this file from JAR. All Maven 3.9.x and 4.x are affected. > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8180: - Description: Resolver will generate plugin metadata based on contents of META-INF/maven/plugins.xml file, that for example in case of shaded JAR may be totally off. Circumvention: exclude this file from JAR. All Maven 3.9.x and 4.x are affected. Solution: the Artifact (checked for: has no classifier and is backed by JAR, the requirements for maven-plugin JAR) and the embedded plugin metadata MUST BE aligned (artifact GA == metadata GA). In this case all is happening as before, happy path. In case of artifact GA != metadata GA we HARD FAIL the build, as deploying "formally adhering to maven plugin JAR with rogue metadata" may be very misleading. Most probably the origin of "rogue" plugin metadata is by shading (like in case of Tika), or by some other rogue resource, or even someone "reinventing" the plugin metadata for some other purposes. Maven should simply prevent install/deploy of artifacts like these, and users should fix the artifact (in case of shading, exclude that resource, in other cases figure out from where it comes and eliminate it). More context: in Maven3 this is most we can do, as repository metadata generation happens in maven-resolver-provider module that does not and cannot depend on maven-core (is "pure" resolver), hence notion of packaging, project, build etc is not available. In Maven4 with new API we MAY do something more later. The two PRs against 3.9.x and 4.0.0 are currently identical. was: Resolver will generate plugin metadata based on contents of META-INF/maven/plugins.xml file, that for example in case of shaded JAR may be totally off. Circumvention: exclude this file from JAR. All Maven 3.9.x and 4.x are affected. Solution: the Artifact (checked for: has no classifier and is backed by JAR, the requirements for maven-plugin JAR) and the embedded plugin metadata MUST BE aligned (artifact GA == metadata GA). In this case all is happening as before, happy path. In case of artifact GA != metadata GA we HARD FAIL the build, as deploying "formally adhering to maven plugin JAR with rogue metadata" may be very misleading. Most probably the origin of "rogue" plugin metadata is by shading (like in case of Tika), or by some other rogue resource, or even someone "reinventing" the plugin metadata for some other purposes. Maven should simply prevent install/deploy of artifacts like these, and users should fix the artifact (in case of shading, exclude that resource, in other cases figure out from where it comes and eliminate it). More context: in Maven3 this is most we can do, as repository metadata generation happens in maven-resolver-provider module that does not and cannot depend on maven-core (is "pure" resolver), hence notion of packaging, project, build etc is not available. In Maven4 with new API we MAY do something more. > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, buil
Re: [PR] [MNG-8052] Fully concurrent builder for Maven 4 [maven]
cstamas commented on PR #1429: URL: https://github.com/apache/maven/pull/1429#issuecomment-591740 Can you point me where "concurrent" is enabled by def? I cannot find that spot -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8052) Define a new lifecycle for Maven 4
[
https://issues.apache.org/jira/browse/MNG-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864998#comment-17864998
]
ASF GitHub Bot commented on MNG-8052:
-
cstamas commented on PR #1429:
URL: https://github.com/apache/maven/pull/1429#issuecomment-591740
Can you point me where "concurrent" is enabled by def? I cannot find that
spot
> Define a new lifecycle for Maven 4
> --
>
> Key: MNG-8052
> URL: https://issues.apache.org/jira/browse/MNG-8052
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> The idea would be to redefine a maven lifecycle as being defined by:
> {{Lifecycle}}:
> * id: unique identifier
> * set of Phase
> {{Step}}:
> * optional name
> * optional mojo execution
> * list of predecessors and successors for the current project
> * list of predecessors and successors for dependencies
> * list of predecessors and successors for child modules
> Default lifecycle could be defined by a set of empty steps:
> * {{initialize}}
> * {{{}resources{}}}: requires {{initialize}}
> * {{{}sources{}}}: requires {{initialize}}
> * {{{}compile{}}}: requires {{sources}}
> * {{{}ready{}}}: requires {{resources, compile}}
> * {{{}build{}}}: requires {{ready}}
> * {{{}test{}}}: requires {{compile}}
> * {{{}package{}}}: requires {{build, test}}
> * {{{}integration-test{}}}: requires {{package}}
> * {{{}verify{}}}: requires {{test, integration-test}}
> and a set of steps bound to plugin executions
> * {{m-resources-p}} required by {{resources}}
> * {{m-compiler-p}} required by {{{}compile{}}}, requires {{sources}} and
> dependencies at {{ready}}
> * {{m-surefire-p}} required by {{test}}
> * {{m-jar-p}} required by {{build}}
> * {{m-failsafe-p}} required by {{integration-test}}
> The {{build}} phase would be introduced to have packaged artifacts without
> running any tests. The {{ready}} phase would be introduced to allow (if
> needed) a small difference between being {{{}compile{}}}'d and being
> {{{}package{}}}'d: simple jars can be used as dependencies when they are only
> compiled (using target/classes), but if you use a custom package (for example
> {{{}m-shade-p{}}}), you cannot use the compiled classes directly, but you
> need the processed classes. In such a case, the {{m-shade-p}} should be
> required by {{ready}} and should require {{{}m-jar-p{}}}.
> This would allow:
> * injecting a given plugin into an existing chain: a custom generation step
> is modelled with: {{m-generator-plugin}} required by {{sources}}
> * a post packaging phase would be defined with: {{my-plugin}}: requires
> {{m-jar-p}}, required by {{packaging}}
> * running {{mvn build}} to build all jars without running any tests
> * running {{mvn -amd test}} (or something similar) would allow building the
> given project with the full graph (i.e. with all dependencies at {{ready}}
> phase
> * this immediately gives a full graph that can be built concurrently down to
> the mojo level
> * the ability to add predecessors onto children' modules phases allow
> defining aggregate goals more easily
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7569) Plugin descriptor model should contain all elements understood by PluginDescriptorBuilder and correctly specify mandatory attributes
[
https://issues.apache.org/jira/browse/MNG-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7569:
-
Fix Version/s: 4.0.0-alpha-3
> Plugin descriptor model should contain all elements understood by
> PluginDescriptorBuilder and correctly specify mandatory attributes
>
>
> Key: MNG-7569
> URL: https://issues.apache.org/jira/browse/MNG-7569
> Project: Maven
> Issue Type: Improvement
> Components: Plugin API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Labels: plugin-descriptor-1.1
> Fix For: 4.0.0-alpha-3, 4.0.0
>
>
> The plugin descriptor schema at
> https://maven.apache.org/ref/3.8.6/maven-plugin-api/plugin.html currently
> does not list all elements which are understood by PluginDescriptorBuilder
> * v4Api (Boolean)
> Also none of the elements are currently marked as required but in fact the
> {{PluginDescriptorBuilder}} unconditionally dereferences some elements. All
> those should be marked as required in the underlying model (also to generate
> a proper XSD).
> In addition the {{configuration}} element need to be classified as type
> {{DOM}} to generate a proper XSD (compare with
> https://github.com/codehaus-plexus/modello/issues/264).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7758) o.e.aether.resolution.ArtifactResolutionException incorrectly examined when multiple repositories are involved
[
https://issues.apache.org/jira/browse/MNG-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7758:
-
Fix Version/s: 4.0.0-beta-4
> o.e.aether.resolution.ArtifactResolutionException incorrectly examined when
> multiple repositories are involved
> --
>
> Key: MNG-7758
> URL: https://issues.apache.org/jira/browse/MNG-7758
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies, Performance
>Affects Versions: 3.8.8, 3.9.1, 4.0.0-alpha-5
>Reporter: Michael Osipov
>Assignee: Slawomir Jaranowski
>Priority: Critical
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
> Attachments: 1.png, 2.png, Exception hierarchy.png
>
>
> Consider you have three repos defined in your build (could be POM or
> settings), evaluated in following order:
> 1. repo A: serves custom artifacts with group id {{com.example}}, due to repo
> partitioning in Nexus rejects requests to all other group ids with 403
> 1. repo B: serves third party artifacts without any restriction from a Nexus
> repo
> 1. repo C: serves Central mirror, last one quried, no restrictions
> Note that order is important! Now add a non-existing dependency to your POM
> and receive the following behavior:
> {{ArtifactResolutionException}} will contain an {{ArtifactResult}} with three
> exceptions:
> - {{TransferException}} with nested {{AuthorizationException}},
> - {{ArtifactNotFoundException}},
> - {{ArtifactNotFoundException}}.
> {{ArtifactResolutionException#getCause()}} will be populated with the
> {{TransferException}} so will
> {{org.eclipse.aether.resolution.ArtifactResult.isMissing()}} take the first
> exception only into account. E.g., {{DefaultArtifactDescriptorReader}} will
> do {{if (e.getCause() instanceof ArtifactNotFoundException)}} which is
> deceiving.
> Here is a sample for a non-existing artifact:
> {noformat}
> [INFO] --- maven-site-plugin:4.0.0-M7-SNAPSHOT:site (default-site) @
> mskins-222 ---
> [INFO] Configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.2
> [WARNING] index report is declared twice in default reportSet
> [INFO] 15 reports configured for maven-project-info-reports-plugin:3.4.2:
> index, summary, dependency-info, modules, team, scm, issue-management,
> mailing-lists, dependency-management, dependencies, dependency-convergence,
> ci-management, plugin-management, plugins, distribution-management
> [INFO] Rendering site for default locale
> Downloading from lda-public:
> https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/org/apache/apache/29/apache-29-site.xml
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.214 s
> [INFO] Finished at: 2023-04-02T12:51:02+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M7-SNAPSHOT:site
> (default-site) on project mskins-222: SiteToolException: The site descriptor
> cannot be resolved from the repository: Unable to locate site descriptor:
> Could not transfer artifact org.apache:apache:xml:site:29 from/to lda-public
> (https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/):
> authorization failed for
> https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/org/apache/apache/29/apache-29-site.xml,
> status: 403 Forbidden -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {noformat}
> for a dependency:
> {noformat}
> [INFO] org.apache.maven.cli.event.ExecutionEventLogger -
>
> [ERROR] org.apache.maven.cli.MavenCli - Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M7-SNAPSHOT:site
> (default-site) on project mskins-222: Failed to get report for
> org.apache.maven.plugins:maven-project-plugin: Plugin
> org.apache.maven.plugins:maven-project-plugin:3.4.2 or one of its
> dependencies could not be resolved: Failed to read artifact descriptor for
> org.apache.maven.plugins:maven-project-plugin:jar:3.4.2: Could not transfer
> artifact org.apache.maven.plugins:maven-project-plugin:pom:3.4.2 from/to
> lda-publ
[jira] [Updated] (MNG-8134) Provide a @Resolution annotation that can be used to inject dependencies resolution/collection in mojos
[ https://issues.apache.org/jira/browse/MNG-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8134: - Fix Version/s: 4.0.0-beta-4 > Provide a @Resolution annotation that can be used to inject dependencies > resolution/collection in mojos > --- > > Key: MNG-8134 > URL: https://issues.apache.org/jira/browse/MNG-8134 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > > See > https://github.com/apache/maven-plugin-tools/pull/286#discussion_r1620871349 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8066) Maven hangs on self-referencing exceptions
[
https://issues.apache.org/jira/browse/MNG-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8066:
-
Fix Version/s: 4.0.0-beta-4
> Maven hangs on self-referencing exceptions
> --
>
> Key: MNG-8066
> URL: https://issues.apache.org/jira/browse/MNG-8066
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: François Guillot
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> If the code executed by Maven throws a self-referencing exception, such as
> {code:java}
> RuntimeException selfReferencingException = new RuntimeException("BOOM self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> {code}
> For instance, if this code is added to an `AbstractExecutionListener`, which
> is added to the running build:
> {code:java}
> import org.apache.maven.execution.AbstractExecutionListener;
> import org.apache.maven.execution.ExecutionListener;
> import org.apache.maven.execution.ExecutionEvent;
> public class FailingExecutionListener extends AbstractExecutionListener {
> private final ExecutionListener delegate;
> public FailingExecutionListener(ExecutionListener delegate) {
> this.delegate = delegate;
> }
> @Override
> public void sessionStarted(ExecutionEvent event) {
> if (delegate != null) {
> delegate.sessionStarted(event);
> }
> RuntimeException selfReferencingException = new RuntimeException("BOOM
> self");
> selfReferencingException.initCause(new Exception("BOOM cause",
> selfReferencingException));
> throw selfReferencingException;
> }
> }
> {code}
> Maven hangs at the end of the build, in `DefaultExceptionHandler`.
> The code in `DefaultExceptionHandler#getMessage` iterates on a given
> throwable and its causes. It checks if the cause is not the same throwable,
> but doesn't protect against a 'two-level' recursion like shown above.
> Note that when printing a stacktrace, Java itself protects against this via
> the use of a
> {code:java}
> Set dejaVu = Collections.newSetFromMap(new IdentityHashMap<>());
> {code}
> and stops the recursion if encountering an already seen throwable.
> A way to fix this would be to replace the offending cause with a replacement
> with no cause, such as in
> {code:java}
> private static Throwable patchCircularCause(Throwable current, Throwable
> parent) {
> try {
> Field causeField = Throwable.class.getDeclaredField("cause");
> causeField.setAccessible(true);
> Throwable replacement = new Throwable("[CIRCULAR REFERENCE: " +
> current + "]");
> replacement.setStackTrace(current.getStackTrace());
> causeField.set(parent, replacement);
> return replacement;
> } catch (NoSuchFieldException | IllegalAccessException e) {
> // Couldn't replace the cause, let's return the actual exception.
> return current;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attribute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8116:
-
Fix Version/s: 4.0.0-beta-4
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attribute
> -
>
> Key: MNG-8116
> URL: https://issues.apache.org/jira/browse/MNG-8116
> Project: Maven
> Issue Type: Bug
> Components: Plugin Requests
>Affects Versions: 3.9.6
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> Originally discovered via a Jetty bug report see
> https://github.com/jetty/jetty.project/issues/11732
> The bean to configured have the following overloading method naming:
> * public void setExtraClasspath(String extraClasspath)
> * public void setExtraClasspath(List extraClasspath)
> The plugin configuration:
>
> ${basedir}/config
>
> even forcing the implementation attribute doesn't help
>
>implementation="java.lang.String">${basedir}/config
>
> The fix is implemented via the PR
> https://github.com/eclipse/sisu.plexus/pull/52
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7902) Sort plugins in validation report
[ https://issues.apache.org/jira/browse/MNG-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7902: - Fix Version/s: 4.0.0-beta-4 > Sort plugins in validation report > - > > Key: MNG-7902 > URL: https://issues.apache.org/jira/browse/MNG-7902 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Michael Keppler >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > Attachments: image-2023-10-07-13-33-27-762.png > > > Please don't ever output the content of a Set for consumption by humans > without sorting it first. The order is otherwise "random". Sorting (case > insensitive) makes the same output easier to read, especially when trying to > find one specific entry (e.g. "Did we fix plugin foo already?") > !image-2023-10-07-13-33-27-762.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8135:
-
Fix Version/s: 4.0.0-beta-4
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name, arch or version has capital letters, it won't activate the
> profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8150) Make SimplexTransferListener handle absent source/target files
[ https://issues.apache.org/jira/browse/MNG-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8150: - Fix Version/s: 4.0.0-beta-4 > Make SimplexTransferListener handle absent source/target files > -- > > Key: MNG-8150 > URL: https://issues.apache.org/jira/browse/MNG-8150 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.9.7 >Reporter: Pavlo Shevchenko >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > See the discussion: > [https://github.com/apache/maven/pull/1471/files#r1632930409] > The `TransferResource#file` may be `null`. The current implementation of the > `SimplexTransferListener` cannot handle this case and will break with an NPE. > > The fix should be merged to `master` and backported to `maven-3.9.x` branches. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8136) Update to Eclipse Sisu 0.9.0.M3
[ https://issues.apache.org/jira/browse/MNG-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8136: - Fix Version/s: 4.0.0-beta-4 > Update to Eclipse Sisu 0.9.0.M3 > --- > > Key: MNG-8136 > URL: https://issues.apache.org/jira/browse/MNG-8136 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8140) When a model is discarded (by model builder) for whatever reason, show why it happened
[
https://issues.apache.org/jira/browse/MNG-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8140:
-
Fix Version/s: 4.0.0-beta-4
> When a model is discarded (by model builder) for whatever reason, show why it
> happened
> --
>
> Key: MNG-8140
> URL: https://issues.apache.org/jira/browse/MNG-8140
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> Currently, when a model is discarded as "invalid", Maven 3.x shows this line
> in console:
> {noformat}
> [WARNING] The POM for org.openjfx:javafx-controls:jar:22.0.1 is invalid,
> transitive dependencies (if any) will not be available, enable debug logging
> for more details{noformat}
> And then when user uses {{-X}} and battles himself thru a TON of debug logs,
> will find the cause WHY the model was discarded (despite it was all there
> even in non-debug session).
> I want to know from first hand (and as soon as possible) WHY a model was
> discarded, so we should modify this output to:
> * do not "redirect" me at debug output
> * immediately tell me why
> Note: Maven4 already have the CLI switch {{-sadp}} "strict artifact
> descriptor policy" that will FAIL the build when it hits an "invalid" model,
> as users usually don't want invalid models in their builds (is most often
> usually some dev mistake, like using property for version/classifier while
> not defining that property). This issue affects Maven4 as well, as if the
> switch is used, build will fail due "invalid model", but user is still left
> in dark WHY.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8151) Merge DependencyCollector into DependencyResolver
[ https://issues.apache.org/jira/browse/MNG-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8151: - Fix Version/s: 4.0.0-beta-4 > Merge DependencyCollector into DependencyResolver > - > > Key: MNG-8151 > URL: https://issues.apache.org/jira/browse/MNG-8151 > Project: Maven > Issue Type: Improvement > Components: API >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8142) If JDK profile activator gets "invalid" JDK version for whatever reason, it chokes but does not tell why
[
https://issues.apache.org/jira/browse/MNG-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8142:
-
Fix Version/s: 4.0.0-beta-4
> If JDK profile activator gets "invalid" JDK version for whatever reason, it
> chokes but does not tell why
>
>
> Key: MNG-8142
> URL: https://issues.apache.org/jira/browse/MNG-8142
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> The JDK profile activator uses property {{java.version}} to determine is
> profile active or not, but if you look at MNG-3746 you can see that Maven
> _allows overriding that property_ by user, but also, today some "weird
> formatted" version may pop up in the wild.
> The JDK profile activator is not prepared for these cases, and will just
> throw (NumberFormatEx), without telling why it did belly up.
> Improve the message why it throw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8141) Model Builder should report if not sure about "fully correct" outcome
[ https://issues.apache.org/jira/browse/MNG-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8141: - Fix Version/s: 4.0.0-beta-4 > Model Builder should report if not sure about "fully correct" outcome > - > > Key: MNG-8141 > URL: https://issues.apache.org/jira/browse/MNG-8141 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4 > > > ModelBuilder is component building models (POM + interpolating + parent > inheritance and many many more things), but it should not rely that built > model "was validated", as it MAY NOT been validated: for "furthest" models it > builds, like a parent of a some-level-dependency we use MIN level of > validation (minimal validation). > Still, while the model builder builds, it relies on several aspects of the > model, and it should ensure that the "output" (built model) is correct. Model > Builder hence must be changed in way, that IF it detects any issue _during > building_ of the model, and IF it appears with even slightest possibility > that it cannot deliver "correct output", it must add WARNs to model building > result with proper messages. > One typical case is when model building injects activated profiles (as they > can deliver properties and extra plugins and what not) and activation code > detects a "problem", like for example duplicated profile IDs being used (this > IS catched by validation, but not on MIN level!), hence, model builder cannot > guarantee that built model IS correct. > This change is really only to make Maven emit WARNINGs if project being built > has some "far POMs" (like parent pom of a dependency of a first level > dependency, as in reproducer). If model builder cannot be "100% sure" it > built model correctly, it should be reported. Moreover, WARNs of model > building result were simply neglected so fat (lost). Having warnings like > these would reveal "invalid parent POM" early, as it is case in issue > MNG-8131 for example. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8153) Some classes from the Maven 3 API are missing
[ https://issues.apache.org/jira/browse/MNG-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8153: - Fix Version/s: 4.0.0-beta-4 > Some classes from the Maven 3 API are missing > - > > Key: MNG-8153 > URL: https://issues.apache.org/jira/browse/MNG-8153 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8152) Implement @SessionScoped and @MojoExecutionScoped from the DI API
[ https://issues.apache.org/jira/browse/MNG-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8152: - Fix Version/s: 4.0.0-beta-4 > Implement @SessionScoped and @MojoExecutionScoped from the DI API > - > > Key: MNG-8152 > URL: https://issues.apache.org/jira/browse/MNG-8152 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8160) Recreate the transformed artifact if it has been deleted
[ https://issues.apache.org/jira/browse/MNG-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8160: - Fix Version/s: 4.0.0-beta-4 > Recreate the transformed artifact if it has been deleted > > > Key: MNG-8160 > URL: https://issues.apache.org/jira/browse/MNG-8160 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8178) Profile activation based on OS properties is broken for "mvn site"
[
https://issues.apache.org/jira/browse/MNG-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8178:
-
Fix Version/s: 4.0.0-beta-4
> Profile activation based on OS properties is broken for "mvn site"
> --
>
> Key: MNG-8178
> URL: https://issues.apache.org/jira/browse/MNG-8178
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.7, 3.9.8
>Reporter: Christian Kohlschütter
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.0, 3.9.9, 4.0.0-beta-4
>
>
> MNG-5726 introduced a breaking change that makes "mvn site" fail when
> profiles based on OS activation are used.
> From commit f860a8693d38292c8ce9ee3b6a883559e7a94796
> maven-model-builder/src/main/java/org/apache/mavqen/model/profile/activation/OperatingSystemProfileActivator.java:
>
> {code:java}
> String actualOsName =
> context.getSystemProperties().get("os.name").toLowerCase(Locale.ENGLISH);
> String actualOsArch =
> context.getSystemProperties().get("os.arch").toLowerCase(Locale.ENGLISH);
> String actualOsVersion =
> context.getSystemProperties().get("os.version").toLowerCase(Locale.ENGLISH);{code}
> context.getSystemProperties() may be empty (or not contain any of these three
> keys), which makes toLowerCase(Locale) fail with a NullPointerException.
> Steps to reproduce:
>
> {code:java}
> git clone https://github.com/kohlschutter/junixsocket.git
> git checkout 65602a9054eb232635678e1aa2f682969aaa059f
> ./scripts/build-site
> {code}
> Output:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M11:site (default-site) on
> project junixsocket: Failed to render reports: Error generating
> maven-project-info-reports-plugin:3.6.1:modules report: Unable to read local
> module POM: Some problems were encountered while processing the POMs:
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-x86_64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 243, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 261, column 18
> [ERROR] [ERROR] Failed to determine activation for profile arch-amd64-Linux:
> Cannot invoke "String.toLowerCase(java.util.Locale)" because the return value
> of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 280, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-Linux: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 299, column 18
> [ERROR] [ERROR] Failed to determine activation for profile arch-amd64-NetBSD:
> Cannot invoke "String.toLowerCase(java.util.Locale)" because the return value
> of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 318, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-amd64-OpenBSD: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 337, column 18: 6
> problems were encountered while building the effective model for
> com.kohlschutter.junixsocket:junixsocket-native:2.10.1-SNAPSHOT
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-x86_64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 243, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 261, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
[jira] [Updated] (MNG-8164) Session#collectDependencies(Project) does not obey exclusions
[ https://issues.apache.org/jira/browse/MNG-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8164: - Fix Version/s: 4.0.0-beta-4 > Session#collectDependencies(Project) does not obey exclusions > - > > Key: MNG-8164 > URL: https://issues.apache.org/jira/browse/MNG-8164 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8164) Session#collectDependencies(Project) does not obey exclusions
[ https://issues.apache.org/jira/browse/MNG-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865000#comment-17865000 ] Tamas Cservenak commented on MNG-8164: -- https://github.com/apache/maven/commit/5b4e17736b9f22906cb82c52ee37df8f72bab22e > Session#collectDependencies(Project) does not obey exclusions > - > > Key: MNG-8164 > URL: https://issues.apache.org/jira/browse/MNG-8164 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8179) Upgrade Parent to 43
[ https://issues.apache.org/jira/browse/MNG-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8179: - Fix Version/s: 4.0.0-beta-4 > Upgrade Parent to 43 > > > Key: MNG-8179 > URL: https://issues.apache.org/jira/browse/MNG-8179 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 3.9.9, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865002#comment-17865002 ] ASF GitHub Bot commented on MNG-8180: - tballison merged PR #1855: URL: https://github.com/apache/tika/pull/1855 > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865003#comment-17865003 ] ASF GitHub Bot commented on MNG-8180: - tballison commented on PR #1855: URL: https://github.com/apache/tika/pull/1855#issuecomment-634049 Thank you so much @cstamas !!! > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8180: Assignee: Tamas Cservenak > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8179) Upgrade Parent to 43
[ https://issues.apache.org/jira/browse/MNG-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8179: - Component/s: Bootstrap & Build > Upgrade Parent to 43 > > > Key: MNG-8179 > URL: https://issues.apache.org/jira/browse/MNG-8179 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap & Build >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 3.9.9, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8178) Profile activation based on OS properties is broken for "mvn site"
[
https://issues.apache.org/jira/browse/MNG-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8178:
-
Component/s: Core
> Profile activation based on OS properties is broken for "mvn site"
> --
>
> Key: MNG-8178
> URL: https://issues.apache.org/jira/browse/MNG-8178
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.7, 3.9.8
>Reporter: Christian Kohlschütter
>Assignee: Guillaume Nodet
>Priority: Blocker
> Fix For: 4.0.0, 3.9.9, 4.0.0-beta-4
>
>
> MNG-5726 introduced a breaking change that makes "mvn site" fail when
> profiles based on OS activation are used.
> From commit f860a8693d38292c8ce9ee3b6a883559e7a94796
> maven-model-builder/src/main/java/org/apache/mavqen/model/profile/activation/OperatingSystemProfileActivator.java:
>
> {code:java}
> String actualOsName =
> context.getSystemProperties().get("os.name").toLowerCase(Locale.ENGLISH);
> String actualOsArch =
> context.getSystemProperties().get("os.arch").toLowerCase(Locale.ENGLISH);
> String actualOsVersion =
> context.getSystemProperties().get("os.version").toLowerCase(Locale.ENGLISH);{code}
> context.getSystemProperties() may be empty (or not contain any of these three
> keys), which makes toLowerCase(Locale) fail with a NullPointerException.
> Steps to reproduce:
>
> {code:java}
> git clone https://github.com/kohlschutter/junixsocket.git
> git checkout 65602a9054eb232635678e1aa2f682969aaa059f
> ./scripts/build-site
> {code}
> Output:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M11:site (default-site) on
> project junixsocket: Failed to render reports: Error generating
> maven-project-info-reports-plugin:3.6.1:modules report: Unable to read local
> module POM: Some problems were encountered while processing the POMs:
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-x86_64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 243, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 261, column 18
> [ERROR] [ERROR] Failed to determine activation for profile arch-amd64-Linux:
> Cannot invoke "String.toLowerCase(java.util.Locale)" because the return value
> of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 280, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-Linux: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 299, column 18
> [ERROR] [ERROR] Failed to determine activation for profile arch-amd64-NetBSD:
> Cannot invoke "String.toLowerCase(java.util.Locale)" because the return value
> of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 318, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-amd64-OpenBSD: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 337, column 18: 6
> problems were encountered while building the effective model for
> com.kohlschutter.junixsocket:junixsocket-native:2.10.1-SNAPSHOT
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-x86_64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 243, column 18
> [ERROR] [ERROR] Failed to determine activation for profile
> arch-aarch64-MacOSX: Cannot invoke "String.toLowerCase(java.util.Locale)"
> because the return value of "java.util.Map.get(Object)" is null @
> com.kohlschutter.junixsocket:junixsocket:2.10.1-SNAPSHOT,
> /Users/ck/Entwicklung/workspace/junixsocket/pom.xml, line 261, column 18
> [ERROR] [ERROR] Failed to determine activ
[jira] [Updated] (MNG-8153) Some classes from the Maven 3 API are missing
[ https://issues.apache.org/jira/browse/MNG-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8153: - Component/s: Core > Some classes from the Maven 3 API are missing > - > > Key: MNG-8153 > URL: https://issues.apache.org/jira/browse/MNG-8153 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8164) Session#collectDependencies(Project) does not obey exclusions
[ https://issues.apache.org/jira/browse/MNG-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8164: - Component/s: API > Session#collectDependencies(Project) does not obey exclusions > - > > Key: MNG-8164 > URL: https://issues.apache.org/jira/browse/MNG-8164 > Project: Maven > Issue Type: Bug > Components: API >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8134) Provide a @Resolution annotation that can be used to inject dependencies resolution/collection in mojos
[ https://issues.apache.org/jira/browse/MNG-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8134: - Component/s: API > Provide a @Resolution annotation that can be used to inject dependencies > resolution/collection in mojos > --- > > Key: MNG-8134 > URL: https://issues.apache.org/jira/browse/MNG-8134 > Project: Maven > Issue Type: Task > Components: API >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > > See > https://github.com/apache/maven-plugin-tools/pull/286#discussion_r1620871349 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8160) Recreate the transformed artifact if it has been deleted
[ https://issues.apache.org/jira/browse/MNG-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8160: - Component/s: Core > Recreate the transformed artifact if it has been deleted > > > Key: MNG-8160 > URL: https://issues.apache.org/jira/browse/MNG-8160 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8152) Implement @SessionScoped and @MojoExecutionScoped from the DI API
[ https://issues.apache.org/jira/browse/MNG-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8152: - Component/s: API > Implement @SessionScoped and @MojoExecutionScoped from the DI API > - > > Key: MNG-8152 > URL: https://issues.apache.org/jira/browse/MNG-8152 > Project: Maven > Issue Type: Improvement > Components: API >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1673845738
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
Which for example?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865011#comment-17865011
]
ASF GitHub Bot commented on MNG-8180:
-
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1673845738
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
Which for example?
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1673952590
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
IAPMEx? But lets have NPE and other fail the build as well, as below it is
in comment, IOEx, PlexusXMLEx etc are and were swallowed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865047#comment-17865047
]
ASF GitHub Bot commented on MNG-8180:
-
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1673952590
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
IAPMEx? But lets have NPE and other fail the build as well, as below it is
in comment, IOEx, PlexusXMLEx etc are and were swallowed.
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865058#comment-17865058 ] Hudson commented on MNG-8180: - SUCCESS: Integrated in Jenkins build Tika » tika-main-jdk11 #1673 (See [https://ci-builds.apache.org/job/Tika/job/tika-main-jdk11/1673/]) Circumvention for MNG-8180 Maven bug (#1855) (github: [https://github.com/apache/tika/commit/a7bde13d471c4b6057fe9090b59a89132e5995e0]) * (edit) tika-grpc/pom.xml > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674022110
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
But why catch and rethrow?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865066#comment-17865066
]
ASF GitHub Bot commented on MNG-8180:
-
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674022110
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
But why catch and rethrow?
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-383) PMD should fail when there is a processing error
[
https://issues.apache.org/jira/browse/MPMD-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865067#comment-17865067
]
Thomas Nikolay commented on MPMD-383:
-
I agree with the arguments of [~adangel]
> PMD should fail when there is a processing error
>
>
> Key: MPMD-383
> URL: https://issues.apache.org/jira/browse/MPMD-383
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Affects Versions: 3.21.0
>Reporter: Thomas Nikolay
>Priority: Critical
> Attachments: image-2023-07-28-13-34-28-717.png
>
>
> We had the case that PMD can't process some processing error but the build
> does not fail.
>
> {noformat}
> [2023-07-28T10:59:44.102Z] [INFO] --- maven-pmd-plugin:3.20.0:pmd (pmd) @
> mod-config-client-cst ---
> [2023-07-28T10:59:44.692Z] [INFO] PMD version: 6.53.0
> [2023-07-28T10:59:45.672Z] [WARNING] Removed misconfigured rule:
> GK-SAP-ApacheLoggerDeniedRule cause: missing value
> [2023-07-28T10:59:45.672Z] [WARNING] There are 3 PMD processing errors:
> [2023-07-28T10:59:45.672Z] [WARNING]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/cst/client/AppInfoProviderImpl_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/test/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST_Test.java
> [2023-07-28T10:59:45.948Z]
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java:
> PMDException: Error while processing
> /var/lib/hudson-slave/workspace/hmr.MAIN.00-FEATURE-BRANCHES/pos/config/mod-config-client-cst/src/main/java/com/gk_software/pos/api/model/config/component/client/print/additional_printout/Trigger_CFH_CST.java
> [2023-07-28T10:59:45.948Z] [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [2023-07-28T10:59:46.210Z] [INFO]
> [2023-07-28T10:59:46.210Z] [INFO] <<< maven-pmd-plugin:3.20.0:check
> (pmd-check) < :pmd @ mod-config-client-cst <<<
> {noformat}
>
> My expectation would be that the build failed when there a processing errors.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674024201
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
As other catch below catches all?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865068#comment-17865068
]
ASF GitHub Bot commented on MNG-8180:
-
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674024201
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
As other catch below catches all?
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674028547
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
I might be missing something, intent is "throw all unexpected ones" (or,
swallow all expected ones, like IOEx, XML parsing and Plexus XML ones, these
are all checked ones).
Also, the newly introduced IAPMEx is "unexpected" as well. All "unexpected"
ones fails the build, while all the "expected" ones are swalled as were since
1.9.0.
--
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] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674028547
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
I might be missing something, intent is "throw all unexpected ones" (or,
swallow all expected ones, like IOEx, XML parsing and Plexus XML ones, these
are all checked ones).
Also, the newly introduced IAPMEx is "unexpected" as well. All "unexpected"
ones will fail the build, while all the "expected" ones are swallowed, as were
since 1.9.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865071#comment-17865071
]
ASF GitHub Bot commented on MNG-8180:
-
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674028547
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
I might be missing something, intent is "throw all unexpected ones" (or,
swallow all expected ones, like IOEx, XML parsing and Plexus XML ones, these
are all checked ones).
Also, the newly introduced IAPMEx is "unexpected" as well. All "unexpected"
ones fails the build, while all the "expected" ones are swalled as were since
1.9.0.
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865072#comment-17865072
]
ASF GitHub Bot commented on MNG-8180:
-
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674028547
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
I might be missing something, intent is "throw all unexpected ones" (or,
swallow all expected ones, like IOEx, XML parsing and Plexus XML ones, these
are all checked ones).
Also, the newly introduced IAPMEx is "unexpected" as well. All "unexpected"
ones will fail the build, while all the "expected" ones are swallowed, as were
since 1.9.0.
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674039426
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
Then I would just rethrow `InvalidArtifactPluginMetadataException`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865073#comment-17865073
]
ASF GitHub Bot commented on MNG-8180:
-
michael-o commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674039426
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
Then I would just rethrow `InvalidArtifactPluginMetadataException`.
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump org.apache.maven:maven-parent from 42 to 43 [maven-resolver]
cstamas commented on PR #531: URL: https://github.com/apache/maven-resolver/pull/531#issuecomment-2223145657 @dependabot rebase -- 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] [MRESOLVER-499] IPC Named locks [maven-resolver]
cstamas merged PR #435: URL: https://github.com/apache/maven-resolver/pull/435 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-499) IPC Named Locks
[ https://issues.apache.org/jira/browse/MRESOLVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-499. - Resolution: Fixed > IPC Named Locks > --- > > Key: MRESOLVER-499 > URL: https://issues.apache.org/jira/browse/MRESOLVER-499 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > Create IPC named locks implementation. Depends on MRESOLVER-421. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-499) IPC Named Locks
[ https://issues.apache.org/jira/browse/MRESOLVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865109#comment-17865109 ] ASF GitHub Bot commented on MRESOLVER-499: -- cstamas merged PR #435: URL: https://github.com/apache/maven-resolver/pull/435 > IPC Named Locks > --- > > Key: MRESOLVER-499 > URL: https://issues.apache.org/jira/browse/MRESOLVER-499 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > > Create IPC named locks implementation. Depends on MRESOLVER-421. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-583) Bump org.apache.maven:maven-parent from 42 to 43
Tamas Cservenak created MRESOLVER-583: - Summary: Bump org.apache.maven:maven-parent from 42 to 43 Key: MRESOLVER-583 URL: https://issues.apache.org/jira/browse/MRESOLVER-583 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven:maven-parent from 42 to 43 [maven-resolver]
cstamas merged PR #531: URL: https://github.com/apache/maven-resolver/pull/531 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-583) Bump org.apache.maven:maven-parent from 42 to 43
[ https://issues.apache.org/jira/browse/MRESOLVER-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-583. - Resolution: Fixed > Bump org.apache.maven:maven-parent from 42 to 43 > > > Key: MRESOLVER-583 > URL: https://issues.apache.org/jira/browse/MRESOLVER-583 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-583) Bump org.apache.maven:maven-parent from 42 to 43
[ https://issues.apache.org/jira/browse/MRESOLVER-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-583: - Assignee: Tamas Cservenak > Bump org.apache.maven:maven-parent from 42 to 43 > > > Key: MRESOLVER-583 > URL: https://issues.apache.org/jira/browse/MRESOLVER-583 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-579) JDK transport: Using insecure flag resets ALPN and SNI
[ https://issues.apache.org/jira/browse/MRESOLVER-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-579: -- Summary: JDK transport: Using insecure flag resets ALPN and SNI (was: Apache transport: Using insecure flag resets ALPN and SNI) > JDK transport: Using insecure flag resets ALPN and SNI > -- > > Key: MRESOLVER-579 > URL: https://issues.apache.org/jira/browse/MRESOLVER-579 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 2.0.0 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven:maven-parent from 42 to 43 [maven-indexer]
cstamas commented on PR #376: URL: https://github.com/apache/maven-indexer/pull/376#issuecomment-2223261190 @dependabot rebase -- 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] (MINDEXER-237) Bump org.apache.maven:maven-parent from 42 to 43
Tamas Cservenak created MINDEXER-237: Summary: Bump org.apache.maven:maven-parent from 42 to 43 Key: MINDEXER-237 URL: https://issues.apache.org/jira/browse/MINDEXER-237 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven:maven-parent from 42 to 43 [maven-indexer]
cstamas merged PR #376: URL: https://github.com/apache/maven-indexer/pull/376 -- 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] [Assigned] (MINDEXER-237) Bump org.apache.maven:maven-parent from 42 to 43
[ https://issues.apache.org/jira/browse/MINDEXER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MINDEXER-237: Assignee: Tamas Cservenak > Bump org.apache.maven:maven-parent from 42 to 43 > > > Key: MINDEXER-237 > URL: https://issues.apache.org/jira/browse/MINDEXER-237 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINDEXER-237) Bump org.apache.maven:maven-parent from 42 to 43
[ https://issues.apache.org/jira/browse/MINDEXER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-237. Resolution: Fixed > Bump org.apache.maven:maven-parent from 42 to 43 > > > Key: MINDEXER-237 > URL: https://issues.apache.org/jira/browse/MINDEXER-237 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-238) Bump org.jsoup:jsoup from 1.17.2 to 1.18.1
Tamas Cservenak created MINDEXER-238: Summary: Bump org.jsoup:jsoup from 1.17.2 to 1.18.1 Key: MINDEXER-238 URL: https://issues.apache.org/jira/browse/MINDEXER-238 Project: Maven Indexer Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 7.1.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.jsoup:jsoup from 1.17.2 to 1.18.1 [maven-indexer]
cstamas merged PR #377: URL: https://github.com/apache/maven-indexer/pull/377 -- 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] [Experiment] Leave out dep from depMgmt [maven]
cstamas opened a new pull request, #1613: URL: https://github.com/apache/maven/pull/1613 As dep is "stronger" anyway, on conflict resolution will win. -- 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] [3.9.x] [Experiment] Leave out dep from depMgmt [maven]
cstamas opened a new pull request, #1614: URL: https://github.com/apache/maven/pull/1614 As dep is "stronger" anyway, on conflict resolution will win. Following this checklist to help us incorporate your contribution quickly and easily: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MINDEXER-238) Bump org.jsoup:jsoup from 1.17.2 to 1.18.1
[ https://issues.apache.org/jira/browse/MINDEXER-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-238. Assignee: Tamas Cservenak Resolution: Fixed > Bump org.jsoup:jsoup from 1.17.2 to 1.18.1 > -- > > Key: MINDEXER-238 > URL: https://issues.apache.org/jira/browse/MINDEXER-238 > Project: Maven Indexer > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674345933
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
K, I will merge this PR as is, and later we can refine.
--
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] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas merged PR #1612: URL: https://github.com/apache/maven/pull/1612 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[
https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865150#comment-17865150
]
ASF GitHub Bot commented on MNG-8180:
-
cstamas commented on code in PR #1611:
URL: https://github.com/apache/maven/pull/1611#discussion_r1674345933
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/PluginsMetadataGenerator.java:
##
@@ -135,14 +136,34 @@ private PluginInfo extractPluginInfo(Artifact artifact) {
String artifactId =
root.getChild("artifactId").getValue();
String goalPrefix =
root.getChild("goalPrefix").getValue();
String name = root.getChild("name").getValue();
-return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+// sanity check: plugin descriptor extracted from
artifact must have same GA
+if (Objects.equals(artifact.getGroupId(), groupId)
+&&
Objects.equals(artifact.getArtifactId(), artifactId)) {
+return new PluginInfo(groupId, artifactId,
goalPrefix, name);
+} else {
+throw new
InvalidArtifactPluginMetadataException(
+"Artifact " + artifact.getGroupId() +
":"
++ artifact.getArtifactId()
++ " JAR (to be
installed/deployed) contains Maven Plugin metadata for plugin "
++ groupId + ":" + artifactId +
"; coordinates are conflicting. "
++ "Most probably your JAR
contains rogue Maven Plugin metadata, "
++ "possible causes may be:
shaded in Maven Plugin or some rogue resource)");
+}
}
}
+} catch (RuntimeException e) {
Review Comment:
K, I will merge this PR as is, and later we can refine.
> Resolver will blindly assume it is deploying a plugin by presence of
> META-INF/maven/plugins.xml in JAR
> --
>
> Key: MNG-8180
> URL: https://issues.apache.org/jira/browse/MNG-8180
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7,
> 3.9.8
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.9, 4.0.0-beta-4
>
>
> Resolver will generate plugin metadata based on contents of
> META-INF/maven/plugins.xml file, that for example in case of shaded JAR may
> be totally off.
> Circumvention: exclude this file from JAR.
> All Maven 3.9.x and 4.x are affected.
> Solution: the Artifact (checked for: has no classifier and is backed by JAR,
> the requirements for maven-plugin JAR) and the embedded plugin metadata MUST
> BE aligned (artifact GA == metadata GA). In this case all is happening as
> before, happy path. In case of artifact GA != metadata GA we HARD FAIL the
> build, as deploying "formally adhering to maven plugin JAR with rogue
> metadata" may be very misleading. Most probably the origin of "rogue" plugin
> metadata is by shading (like in case of Tika), or by some other rogue
> resource, or even someone "reinventing" the plugin metadata for some other
> purposes. Maven should simply prevent install/deploy of artifacts like these,
> and users should fix the artifact (in case of shading, exclude that resource,
> in other cases figure out from where it comes and eliminate it).
> More context: in Maven3 this is most we can do, as repository metadata
> generation happens in maven-resolver-provider module that does not and cannot
> depend on maven-core (is "pure" resolver), hence notion of packaging,
> project, build etc is not available. In Maven4 with new API we MAY do
> something more later. The two PRs against 3.9.x and 4.0.0 are currently
> identical.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8180] Fail install/deploy if rogue Maven Plugin metadata found [maven]
cstamas merged PR #1611: URL: https://github.com/apache/maven/pull/1611 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8180. Resolution: Fixed > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865151#comment-17865151 ] ASF GitHub Bot commented on MNG-8180: - cstamas merged PR #1611: URL: https://github.com/apache/maven/pull/1611 > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-417) Create HTTP test suite a la "TCK"
[ https://issues.apache.org/jira/browse/MRESOLVER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-417: -- Fix Version/s: (was: 2.0.1) > Create HTTP test suite a la "TCK" > - > > Key: MRESOLVER-417 > URL: https://issues.apache.org/jira/browse/MRESOLVER-417 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Now that we have 3 (4 w/ Wagon) HTTP capable resolver transports, we need > some common reusable across HTTP Transports test suite, probably w/ "tunable" > features. > Requirements aside of "most basic functionality": > * MRESOLVER-396 Back off > * MRESOLVER-393 Retain last modified (on files) > * MRESOLVER-382 Setting outgoing interface > * MRESOLVER-361 Unreliable TCP and retries > * MRESOLVER-347 and MRESOLVER-348 Pool controls, reuse connection, max TTL > * MRESOLVER-339 and MRESOLVER-315 Preemptive auth > * MRESOLVER-341 Preemptive PUT auth > * MRESOLVER-328 SSL insecure mode > * MRESOLVER-326 Retries on certain errors > The test should use _standard Resolver configuration with different > transports_ as described on page > https://maven.apache.org/resolver/configuration.html > Hence, testing of Wagon is out of scope, as it uses totally different, > ancient Plexus-XML based configuration, does not obey standard resolver > configuration properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8180) Resolver will blindly assume it is deploying a plugin by presence of META-INF/maven/plugins.xml in JAR
[ https://issues.apache.org/jira/browse/MNG-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865152#comment-17865152 ] ASF GitHub Bot commented on MNG-8180: - cstamas merged PR #1612: URL: https://github.com/apache/maven/pull/1612 > Resolver will blindly assume it is deploying a plugin by presence of > META-INF/maven/plugins.xml in JAR > -- > > Key: MNG-8180 > URL: https://issues.apache.org/jira/browse/MNG-8180 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, > 3.9.8 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.9, 4.0.0-beta-4 > > > Resolver will generate plugin metadata based on contents of > META-INF/maven/plugins.xml file, that for example in case of shaded JAR may > be totally off. > Circumvention: exclude this file from JAR. > All Maven 3.9.x and 4.x are affected. > Solution: the Artifact (checked for: has no classifier and is backed by JAR, > the requirements for maven-plugin JAR) and the embedded plugin metadata MUST > BE aligned (artifact GA == metadata GA). In this case all is happening as > before, happy path. In case of artifact GA != metadata GA we HARD FAIL the > build, as deploying "formally adhering to maven plugin JAR with rogue > metadata" may be very misleading. Most probably the origin of "rogue" plugin > metadata is by shading (like in case of Tika), or by some other rogue > resource, or even someone "reinventing" the plugin metadata for some other > purposes. Maven should simply prevent install/deploy of artifacts like these, > and users should fix the artifact (in case of shading, exclude that resource, > in other cases figure out from where it comes and eliminate it). > More context: in Maven3 this is most we can do, as repository metadata > generation happens in maven-resolver-provider module that does not and cannot > depend on maven-core (is "pure" resolver), hence notion of packaging, > project, build etc is not available. In Maven4 with new API we MAY do > something more later. The two PRs against 3.9.x and 4.0.0 are currently > identical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865159#comment-17865159
]
Michael Osipov commented on MRELEASE-1151:
--
[~basil], can you test on your end with PR #202 merged?
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1151) Maven Release Plugin fails to adjust version (regression in 3.1.0)
[
https://issues.apache.org/jira/browse/MRELEASE-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865160#comment-17865160
]
Basil Crow commented on MRELEASE-1151:
--
{quote}can you test on your end with PR #202 merged?{quote}
I have already done so, and I have already described the results of this
testing in my preceding comment.
> Maven Release Plugin fails to adjust version (regression in 3.1.0)
> --
>
> Key: MRELEASE-1151
> URL: https://issues.apache.org/jira/browse/MRELEASE-1151
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0
> Environment: Ubuntu 22.04.4 LTS x86_64
>Reporter: Basil Crow
>Priority: Blocker
>
> h3. Steps to reproduce
> # Run {{git clone [https://github.com/jenkinsci/text-finder-plugin.git]}}
> # Using Java 17 and Maven 3.9.8, run {{mvn release:prepare
> -DpushChanges=false}}
> h3. Expected results
> {panel:title=Note}
> These are the _actual_ results with Maven Release Plugin 3.0.1.
> {panel}
> The {{[maven-release-plugin] prepare release}} commit adjusts
> {{${scmTag}}} to e.g. {{text-finder-1.29}} *and*
> adjusts {{${revision}${changelist}}} to e.g.
> {{{}1.29{}}}.
> h3. Actual results
> Starting with Maven Release Plugin 3.1.0, the {{[maven-release-plugin]
> prepare release}} commit still adjusts {{${scmTag}}} to e.g.
> {{{}text-finder-1.29{}}}, but it *fails to adjust*
> {{${revision}${changelist}}} to e.g.
> {{1.29}} as expected. After this, the release subsequently
> fails.
> h3. Evaluation
> This regression is caused by the changes to {{AbstractRewritePomsPhase}} made
> in MRELEASE-1109. When these changes are reverted, the issue is resolved.
> h3. Note
> This caused the weekly Jenkins core release to fail on July 2, 2024. We have
> downgraded Maven Release Plugin to 3.0.1 in order to restore stability to our
> releases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
