[GitHub] [maven] cstamas opened a new pull request, #747: Update parent POM 36
cstamas opened a new pull request, #747: URL: https://github.com/apache/maven/pull/747 Update parent POM to v 36. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] cstamas opened a new pull request, #748: Update parent POM 36 (3.9.x)
cstamas opened a new pull request, #748: URL: https://github.com/apache/maven/pull/748 Update parent POM to v 36. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7491) Update parent POM to 36
Tamás Cservenák created MNG-7491: Summary: Update parent POM to 36 Key: MNG-7491 URL: https://issues.apache.org/jira/browse/MNG-7491 Project: Maven Issue Type: Dependency upgrade Components: Bootstrap & Build Reporter: Tamás Cservenák Fix For: 3.9.0, 4.0.0 Update parent POM from 35 to 36. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] eforx commented on issue #649: Maven goal is sometimes skipped
eforx commented on issue #649: URL: https://github.com/apache/maven-mvnd/issues/649#issuecomment-1143239548 I will provide simple source code. -- 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] (MNG-7491) Update parent POM to 36
[ https://issues.apache.org/jira/browse/MNG-7491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7491: --- Assignee: Tamás Cservenák > Update parent POM to 36 > --- > > Key: MNG-7491 > URL: https://issues.apache.org/jira/browse/MNG-7491 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap & Build >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0 > > > Update parent POM from 35 to 36. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MNG-7485) Failed To Load JANSI Native Library
[
https://issues.apache.org/jira/browse/MNG-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7485:
Fix Version/s: wontfix-candidate
> Failed To Load JANSI Native Library
> ---
>
> Key: MNG-7485
> URL: https://issues.apache.org/jira/browse/MNG-7485
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.8.5
>Reporter: Mark
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> Hi All
> Wondering if anyone else has experienced a similar issue. I have recently
> upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error
> as such:
> {color:#505f79}Failed to load native
> library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure
> that the directory is mounted on a partition without the noexec flag, or set
> the jansi.tmpdir system property to point to a proper location. osinfo:
> Linux/x86_64{color}
> {color:#505f79}java.lang.UnsatisfiedLinkError:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from
> shared object: Operation not permitted{color}
> {color:#505f79}Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0){color}
> {color:#505f79}Maven home: /opt/apache-maven-3.8.5{color}
> {color:#505f79}Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> /opt/jdk1.8.0_251/jre{color}
> {color:#505f79}Default locale: en_US, platform encoding: UTF-8{color}
> {color:#505f79}OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64",
> arch: "amd64", family: "unix"{color}
> {color:#505f79}java version "1.8.0_251"{color}
> {color:#505f79}Java(TM) SE Runtime Environment (build 1.8.0_251-b08){color}
> {color:#505f79}Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed
> mode){color}
> I have also tried installing JANSI through yum and that does not seem to
> resolve it. sudo yum -y install jansi-native
> Any help or guidance on how to resolve this would be greatly appreciated.
> CentOS Linux release 7.9.2009 (Core)
> apache-maven-3.8.5
> jdk1.8.0_251
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7485) Failed To Load JANSI Native Library
[
https://issues.apache.org/jira/browse/MNG-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544778#comment-17544778
]
Michael Osipov commented on MNG-7485:
-
Default install of CentOS 7 does not have a separate mountpoint for /tmp:
{noformat}
[root@deblndw013x2v ~]# mount | grep tmp
devtmpfs on /dev type devtmpfs
(rw,nosuid,seclabel,size=928784k,nr_inodes=232196,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,seclabel,size=188080k,mode=700)
{noformat}
> Failed To Load JANSI Native Library
> ---
>
> Key: MNG-7485
> URL: https://issues.apache.org/jira/browse/MNG-7485
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.8.5
>Reporter: Mark
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> Hi All
> Wondering if anyone else has experienced a similar issue. I have recently
> upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error
> as such:
> {color:#505f79}Failed to load native
> library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure
> that the directory is mounted on a partition without the noexec flag, or set
> the jansi.tmpdir system property to point to a proper location. osinfo:
> Linux/x86_64{color}
> {color:#505f79}java.lang.UnsatisfiedLinkError:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from
> shared object: Operation not permitted{color}
> {color:#505f79}Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0){color}
> {color:#505f79}Maven home: /opt/apache-maven-3.8.5{color}
> {color:#505f79}Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> /opt/jdk1.8.0_251/jre{color}
> {color:#505f79}Default locale: en_US, platform encoding: UTF-8{color}
> {color:#505f79}OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64",
> arch: "amd64", family: "unix"{color}
> {color:#505f79}java version "1.8.0_251"{color}
> {color:#505f79}Java(TM) SE Runtime Environment (build 1.8.0_251-b08){color}
> {color:#505f79}Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed
> mode){color}
> I have also tried installing JANSI through yum and that does not seem to
> resolve it. sudo yum -y install jansi-native
> Any help or guidance on how to resolve this would be greatly appreciated.
> CentOS Linux release 7.9.2009 (Core)
> apache-maven-3.8.5
> jdk1.8.0_251
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544781#comment-17544781 ] Enrico Horn commented on SCM-990: - I tried -pl and it actually also doesnt work. The base path is still the submodule. FileRepositoryBuilder.findGitDir is the suggestion I already made in the bug report. > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resources-plugin] olamy opened a new pull request, #29: add release drafter
olamy opened a new pull request, #29: URL: https://github.com/apache/maven-resources-plugin/pull/29 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/MRESOURCES) 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 `[MRESOURCES-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MRESOURCES-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
[GitHub] [maven-resources-plugin] olamy merged pull request #29: add release drafter
olamy merged PR #29: URL: https://github.com/apache/maven-resources-plugin/pull/29 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-javadoc-plugin] gnodet opened a new pull request, #144: [MJAVADOC-716] Fix stale files detection failing because of the newline
gnodet opened a new pull request, #144: URL: https://github.com/apache/maven-javadoc-plugin/pull/144 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/MJAVADOC) 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 `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-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 -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. 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] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544846#comment-17544846 ] Michael Osipov commented on SCM-990: True, stupid me. That seems to be a bug indeed. > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544854#comment-17544854 ] Michael Osipov commented on SCM-990: Can you please explicitly document what you did. Maybe even a sample project. > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544856#comment-17544856 ] Michael Osipov commented on SCM-990: Hmmm: https://github.com/apache/maven-scm/blob/b04525fa0716e6de7a65bf9970284efa0e49b177/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/command/JGitUtils.java#L100-L107 Which command fails? > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request, #66: Bump groovy from 3.0.9 to 3.0.11
dependabot[bot] opened a new pull request, #66: URL: https://github.com/apache/maven-artifact-transfer/pull/66 Bumps [groovy](https://github.com/apache/groovy) from 3.0.9 to 3.0.11. Commits See full diff in https://github.com/apache/groovy/commits";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] closed pull request #64: Bump groovy from 3.0.9 to 3.0.10
dependabot[bot] closed pull request #64: Bump groovy from 3.0.9 to 3.0.10 URL: https://github.com/apache/maven-artifact-transfer/pull/64 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #64: Bump groovy from 3.0.9 to 3.0.10
dependabot[bot] commented on PR #64: URL: https://github.com/apache/maven-artifact-transfer/pull/64#issuecomment-1143550960 Superseded by #66. -- 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-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544891#comment-17544891
]
Gary D. Gregory commented on MNG-7316:
--
Hi [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? We can recode it to avoid reflection,
great, if not, we need a long term solution instead of my reflection into the
gut of Maven hack.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544891#comment-17544891
]
Gary D. Gregory edited comment on MNG-7316 at 6/1/22 12:59 PM:
---
Hi, [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? If you can recode it to avoid
reflection, great, if not, we need a long-term solution instead of my
reflection into the guts of Maven hack.
was (Author: garydgregory):
Hi, [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? If you can recode it to avoid
reflection, great, if not, we need a long-term solution instead of my
reflection into the gut of Maven hack.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544891#comment-17544891
]
Gary D. Gregory edited comment on MNG-7316 at 6/1/22 12:59 PM:
---
Hi, [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? If you can recode it to avoid
reflection, great, if not, we need a long-term solution instead of my
reflection into the gut of Maven hack.
was (Author: garydgregory):
Hi, [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? We can recode it to avoid reflection,
great, if not, we need a long-term solution instead of my reflection into the
gut of Maven hack.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544891#comment-17544891
]
Gary D. Gregory edited comment on MNG-7316 at 6/1/22 12:59 PM:
---
Hi, [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? We can recode it to avoid reflection,
great, if not, we need a long-term solution instead of my reflection into the
gut of Maven hack.
was (Author: garydgregory):
Hi [~chtompki] Any chance you can look at recoding the Apache Commons Maven
plugin before 3.8.6 goes out the door? We can recode it to avoid reflection,
great, if not, we need a long term solution instead of my reflection into the
gut of Maven hack.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-plugin-tools] dependabot[bot] commented on pull request #94: Bump assertj-core from 3.22.0 to 3.23.0
dependabot[bot] commented on PR #94: URL: https://github.com/apache/maven-plugin-tools/pull/94#issuecomment-1143637824 Superseded by #95. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request, #95: Bump assertj-core from 3.22.0 to 3.23.1
dependabot[bot] opened a new pull request, #95: URL: https://github.com/apache/maven-plugin-tools/pull/95 Bumps [assertj-core](https://github.com/assertj/assertj-core) from 3.22.0 to 3.23.1. Commits https://github.com/assertj/assertj-core/commit/0256688fcf02d7c1c1940b1226a24fb5680ac3a3";>0256688 [maven-release-plugin] prepare release assertj-core-3.23.1 https://github.com/assertj/assertj-core/commit/6529933700533de4e8f8191d9b6f4ef371667f1d";>6529933 Downgrade junit-jupiter from 5.9.0-M1 to 5.8.2 https://github.com/assertj/assertj-core/commit/d9cd2da03acd4d68a5599b61fdd9abd5da0cc7be";>d9cd2da [maven-release-plugin] prepare for next development iteration https://github.com/assertj/assertj-core/commit/6f19754e579527b935c9e62d5cb5b0900fa1e6a1";>6f19754 [maven-release-plugin] prepare release assertj-core-3.23.0 https://github.com/assertj/assertj-core/commit/c592c18a59a1ef4f681f1eb08b2571fa77757e43";>c592c18 Expose ComparisonStrategy::areEqual in AbstractAssert (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2633";>#2633) https://github.com/assertj/assertj-core/commit/69c66a9bb66f8b8a39535eb769e8c97d0d8c6648";>69c66a9 Bump maven-invoker-plugin from 3.2.2 to 3.3.0 (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2636";>#2636) https://github.com/assertj/assertj-core/commit/795f5278bebb2703eda7b11569403c2bed650d5a";>795f527 Fix test https://github.com/assertj/assertj-core/commit/b44460623b9c0e83c2b311c1fc6b7bffa1a077b9";>b444606 Bump hibernate-core from 6.0.1.Final to 6.0.2.Final (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2626";>#2626) https://github.com/assertj/assertj-core/commit/793241125ee85ac832a6ee12fc77456256c5";>7932411 Fix typos in Javadoc of ObjectEnumerableAssert (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2624";>#2624) https://github.com/assertj/assertj-core/commit/b746e6aeb4b9bd7246797c3fc18059977aac6ab3";>b746e6a [mvn] Update maven wrapper to 3.1.1 (https://github-redirect.dependabot.com/assertj/assertj-core/issues/2622";>#2622) Additional commits viewable in https://github.com/assertj/assertj-core/compare/assertj-core-3.22.0...assertj-core-3.23.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-tools] dependabot[bot] closed pull request #94: Bump assertj-core from 3.22.0 to 3.23.0
dependabot[bot] closed pull request #94: Bump assertj-core from 3.22.0 to 3.23.0 URL: https://github.com/apache/maven-plugin-tools/pull/94 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SUREFIRE-2090) Xref link to source code with specified line number doesn't work. Missing "L" in anchor
Lau Brino created SUREFIRE-2090: --- Summary: Xref link to source code with specified line number doesn't work. Missing "L" in anchor Key: SUREFIRE-2090 URL: https://issues.apache.org/jira/browse/SUREFIRE-2090 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 3.0.0-M6 Reporter: Lau Brino Steps to reproduce: # Have a Java Maven project setup # In pom.xml, configure maven-surefire-report-plugin together with maven-jxr-plugin:3.2.0 in section # have a failed test in you project. # generate html surefire report with xrefs to source code # in that report locate failed test with link to test source code Expected behavior: Clicking on the link bring you to the exact line is test source where the test failed. Actual behavior: The link works, but the line number is ignored. The link on surefire report looks like this .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#121 However correct URL looks like this .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#L121 (notice the "L" right after #) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[
https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544943#comment-17544943
]
Enrico Horn commented on SCM-990:
-
Sorry, I dont have a sample project.
We are using the buildnumber-plugin in our build like this:
org.codehaus.mojo
buildnumber-maven-plugin
${buildnumber-maven-plugin.version}
create
false
false
true
jgit
org.apache.maven.scm
maven-scm-provider-jgit
${maven-scm-provider-jgit.version}
This calls the info command.
> Jgit Provider cannot resolve Repository in multi-module Maven Project
> -
>
> Key: SCM-990
> URL: https://issues.apache.org/jira/browse/SCM-990
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-jgit
>Reporter: Enrico Horn
>Priority: Major
>
> The JGit providers info command (and probably others) uses fielset.basedir as
> git working directory. When running maven command in a submodule this will
> result in the following error:
>
> Cannot get the revision information from the scm repository :
> [ERROR] Exception while executing SCM command. JGit resolve failure!
> repository not found:
>
> What it should do instead is act like the git binary and search for the git
> directory in parent directories if none found in the current one. Jgit has
> the API FileRepositoryBuilder.findGitDir to do that.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544963#comment-17544963 ] Michael Osipov commented on SCM-990: That snippet must run at the execution root. Is that the case? > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-enforcer] dependabot[bot] opened a new pull request, #160: Bump assertj-core from 3.23.0 to 3.23.1
dependabot[bot] opened a new pull request, #160: URL: https://github.com/apache/maven-enforcer/pull/160 Bumps [assertj-core](https://github.com/assertj/assertj-core) from 3.23.0 to 3.23.1. Commits https://github.com/assertj/assertj-core/commit/0256688fcf02d7c1c1940b1226a24fb5680ac3a3";>0256688 [maven-release-plugin] prepare release assertj-core-3.23.1 https://github.com/assertj/assertj-core/commit/6529933700533de4e8f8191d9b6f4ef371667f1d";>6529933 Downgrade junit-jupiter from 5.9.0-M1 to 5.8.2 https://github.com/assertj/assertj-core/commit/d9cd2da03acd4d68a5599b61fdd9abd5da0cc7be";>d9cd2da [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/assertj/assertj-core/compare/assertj-core-3.23.0...assertj-core-3.23.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544970#comment-17544970 ] Enrico Horn commented on SCM-990: - This snippet worked fine before I set jgit as scm provider. Its part of the root project's definition. > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SCM-990) Jgit Provider cannot resolve Repository in multi-module Maven Project
[ https://issues.apache.org/jira/browse/SCM-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544996#comment-17544996 ] Michael Osipov commented on SCM-990: Please try the maven-scm-plugin. It could also be a bug in the Buildnumber plugin. > Jgit Provider cannot resolve Repository in multi-module Maven Project > - > > Key: SCM-990 > URL: https://issues.apache.org/jira/browse/SCM-990 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Reporter: Enrico Horn >Priority: Major > > The JGit providers info command (and probably others) uses fielset.basedir as > git working directory. When running maven command in a submodule this will > result in the following error: > > Cannot get the revision information from the scm repository : > [ERROR] Exception while executing SCM command. JGit resolve failure! > repository not found: > > What it should do instead is act like the git binary and search for the git > directory in parent directories if none found in the current one. Jgit has > the API FileRepositoryBuilder.findGitDir to do that. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #160: Bump assertj-core from 3.23.0 to 3.23.1
slawekjaranowski merged PR #160: URL: https://github.com/apache/maven-enforcer/pull/160 -- 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] (MNG-7471) Resolver 1.8.0 introduces binary breakage in plugin using Resolver
[
https://issues.apache.org/jira/browse/MNG-7471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7471:
---
Assignee: Tamás Cservenák
> Resolver 1.8.0 introduces binary breakage in plugin using Resolver
> --
>
> Key: MNG-7471
> URL: https://issues.apache.org/jira/browse/MNG-7471
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.9.0-candidate
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> With Maven 3.9.0-SNAPSHOT (post MNG-7453 done) there is a binary breakage
> introduced for plugins using Resolver, as proven by new IT MNG-7470.
> Problem is following:
> Maven Core exports following packages:
> * resolver-api
> * resolver-spi
> * resolver-impl
> While plugin will have added its "own" versions of these below to plugin
> realm:
> * resolver-util
> * resolver-connector-basic
> This means, that a plugin will be forced to use api/spi/imp from core
> (1.8.0), but they will keep using their own util and connector-basic.
> Resolver 1.8.0 introduces API changes that affects all of impl,
> connector-basic and spi, basically their own copy of connector-basic will
> fail. The interface change from resolver-spi will prevent class from
> resolver-connector-basic to be instantiated.
> Error that is thrown during execution of plugin using Resolver:
> {{Caused by: org.apache.maven.plugin.PluginContainerException: An API
> incompatibility was encountered while executing
> io.quarkus:quarkus-maven-plugin:2.3.1.Final:build:
> java.lang.NoSuchMethodError: 'java.util.List
> org.eclipse.aether.spi.connector.layout.RepositoryLayout.getChecksums(org.eclipse.aether.artifact.Artifact,
> boolean, java.net.URI)'}}
> Important note: the error is triggered only when remote download happens, so
> even IT will pass OK with 3.9.0-SNAPSHOT IF local repository is
> pre-populated, hence, no remote download happens!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2090) Xref link to source code with specified line number doesn't work. Missing "L" in anchor
[ https://issues.apache.org/jira/browse/SUREFIRE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545095#comment-17545095 ] Michael Osipov commented on SUREFIRE-2090: -- Here it is: https://github.com/apache/maven-surefire/blob/master/maven-surefire-report-plugin/src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportGenerator.java#L611 > Xref link to source code with specified line number doesn't work. Missing "L" > in anchor > --- > > Key: SUREFIRE-2090 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2090 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 3.0.0-M6 >Reporter: Lau Brino >Priority: Minor > > Steps to reproduce: > # Have a Java Maven project setup > # In pom.xml, configure maven-surefire-report-plugin together with > maven-jxr-plugin:3.2.0 in section > # have a failed test in you project. > # generate html surefire report with xrefs to source code > # in that report locate failed test with link to test source code > Expected behavior: > Clicking on the link bring you to the exact line is test source where the > test failed. > Actual behavior: > The link works, but the line number is ignored. > > The link on surefire report looks like this > .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#121 > However correct URL looks like this > .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#L121 > (notice the "L" right after #) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] michael-o commented on a diff in pull request #741: [MNG-7468] Check unsupported plugins parameters in configuration
michael-o commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887192301
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
The following snippet is rather a goal which is part of plugin, no? So
shouldn't it rather read ...is unknown for goal...?
--
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-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545100#comment-17545100
]
ASF GitHub Bot commented on MNG-7468:
-
michael-o commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887192301
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
The following snippet is rather a goal which is part of plugin, no? So
shouldn't it rather read ...is unknown for goal...?
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545103#comment-17545103
]
ASF GitHub Bot commented on MNG-7468:
-
slawekjaranowski commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887204090
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
It is for plugin - we check parameters for all goals
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #741: [MNG-7468] Check unsupported plugins parameters in configuration
slawekjaranowski commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887204090
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
It is for plugin - we check parameters for all goals
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #741: [MNG-7468] Check unsupported plugins parameters in configuration
slawekjaranowski commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887204663
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
https://github.com/apache/maven/pull/741#discussion_r882879288
--
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-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545104#comment-17545104
]
ASF GitHub Bot commented on MNG-7468:
-
slawekjaranowski commented on code in PR #741:
URL: https://github.com/apache/maven/pull/741#discussion_r887204663
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultMojoExecutionConfigurator.java:
##
@@ -108,4 +122,77 @@ private PluginExecution findPluginExecution( String
executionId, Collection parametersNamesGoal =
mojoDescriptor.getParameters().stream()
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+Set unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesGoal );
+
+if ( unknownParameters.isEmpty() )
+{
+return;
+}
+
+// second step get parameter names of all plugin goals
+Set parametersNamesAll =
mojoDescriptor.getPluginDescriptor().getMojos().stream()
+.flatMap( m -> m.getParameters().stream() )
+.flatMap( this::getParameterNames )
+.collect( Collectors.toSet() );
+
+unknownParameters = getUnknownParameters( mojoExecution,
parametersNamesAll );
+
+unknownParameters.forEach(
+name ->
+{
+MessageBuilder messageBuilder = MessageUtils.buffer()
+.warning( "Parameter '" )
+.warning( name )
+.warning( "' is unknown for plugin '" )
Review Comment:
https://github.com/apache/maven/pull/741#discussion_r882879288
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MEJB-133) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/MEJB-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545245#comment-17545245 ] Hudson commented on MEJB-133: - Build failed in Jenkins: Maven » Maven TLP » maven-ejb-plugin » master #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-ejb-plugin/job/master/11/ > Upgrade to Java 8 > - > > Key: MEJB-133 > URL: https://issues.apache.org/jira/browse/MEJB-133 > Project: Maven EJB Plugin > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.2.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MEJB-131) Upgrade Maven to 3.2.5
[ https://issues.apache.org/jira/browse/MEJB-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545244#comment-17545244 ] Hudson commented on MEJB-131: - Build failed in Jenkins: Maven » Maven TLP » maven-ejb-plugin » master #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-ejb-plugin/job/master/11/ > Upgrade Maven to 3.2.5 > -- > > Key: MEJB-131 > URL: https://issues.apache.org/jira/browse/MEJB-131 > Project: Maven EJB Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.2.1 > > > Update plugin changes: > * set required Maven version to 3.2.5 > * make maven bits provided scope > * update dependencies -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-doxia] feckertson commented on pull request #104: implement hidden rows
feckertson commented on PR #104: URL: https://github.com/apache/maven-doxia/pull/104#issuecomment-1144395835 Decides whether to toggle the even/odd table row parity for zebra striping based on whether the 'hidden' class is being applied. Also adds unit tests for setting an externalLink and a class string simultaneously. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-doxia] feckertson commented on pull request #98: [DOXIA-590] Either provided element class or default class gets ignored
feckertson commented on PR #98: URL: https://github.com/apache/maven-doxia/pull/98#issuecomment-1144396324 @michael-o PR #104 improves this PR to allow the `hidden` class to decide whether the even/odd row parity gets toggled which is the gist of the matter. If one wants ternary+ coloring, one can override the `a` and `b` css to do nothing and define/manage alternate classes based on visible row number mod N. Ideally org.apache.maven.skins:maven-skins should be improved to hide the 'hidden' rows, but one can provide additional css to do that in the meantime. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-590) Either provided element class or default class gets ignored
[ https://issues.apache.org/jira/browse/DOXIA-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545258#comment-17545258 ] ASF GitHub Bot commented on DOXIA-590: -- feckertson commented on PR #98: URL: https://github.com/apache/maven-doxia/pull/98#issuecomment-1144396324 @michael-o PR #104 improves this PR to allow the `hidden` class to decide whether the even/odd row parity gets toggled which is the gist of the matter. If one wants ternary+ coloring, one can override the `a` and `b` css to do nothing and define/manage alternate classes based on visible row number mod N. Ideally org.apache.maven.skins:maven-skins should be improved to hide the 'hidden' rows, but one can provide additional css to do that in the meantime. > Either provided element class or default class gets ignored > --- > > Key: DOXIA-590 > URL: https://issues.apache.org/jira/browse/DOXIA-590 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.8 >Reporter: Fred Eckertson >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M3, 1.11.2 > > Attachments: image-2022-05-18-21-57-40-619.png > > > The following construct is somewhat common in doxia-core > att.addAttribute( Attribute.CLASS, "a" ); > The documentation says that basic attributes (including CLASS) are supported. > However in cases like this either that "a" or the CLASS that was provided in > the attributes parameter will be ignored. The correct way to do this is to > append the provided CLASS to "a " if a CLASS attribute was provided. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #157: [MENFORCER-389] Allow filtering of parent in requireReleaseDeps
slawekjaranowski merged PR #157: URL: https://github.com/apache/maven-enforcer/pull/157 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MENFORCER-389) Exclusions are not considered when looking at parent for requireReleaseDeps
[
https://issues.apache.org/jira/browse/MENFORCER-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MENFORCER-389.
-
Resolution: Fixed
> Exclusions are not considered when looking at parent for requireReleaseDeps
> ---
>
> Key: MENFORCER-389
> URL: https://issues.apache.org/jira/browse/MENFORCER-389
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0
>Reporter: Henri Tremblay
>Assignee: Slawomir Jaranowski
>Priority: Blocker
> Fix For: 3.0.1
>
>
> I would like to prevent parent poms to be a snapshots. But I have a
> multi-module project. The rule is this on the parent pom:
> {code:java}
>
>
> No Snapshots Allowed!
>
> ${project.groupId}:*
>
> true
>
>
> {code}
> I would expect this to fail only when the parent pom is not in my groupId.
> But it's not what it does. It just makes {{failWhenParentIsSnapshot}}
> unusable for multi-module projects.
> See [https://github.com/henri-tremblay/enforce-parent-bug] for a full project
> to reproduce. Just type {{mvn enforcer:enforce}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
