[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648980#comment-17648980
]
Michael Osipov commented on MNG-7637:
-
Can they really be null at times?
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Läubrich updated MNG-7637:
Description:
org.apache.maven.project.MavenProject.hashCode() has the following code:
{code:java}
public int hashCode()
{
int hash = 17;
hash = 31 * hash + getGroupId().hashCode();
hash = 31 * hash + getArtifactId().hashCode();
hash = 31 * hash + getVersion().hashCode();
return hash;
}
{code}
if any of those values is null, a NPE is thrown from the method.
was:
org.apache.maven.project.MavenProject.hashCode() has the following code:
public int hashCode()
{
int hash = 17;
hash = 31 * hash + getGroupId().hashCode();
hash = 31 * hash + getArtifactId().hashCode();
hash = 31 * hash + getVersion().hashCode();
return hash;
}
if any of those values is null, a NPE is thrown from the method.
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648981#comment-17648981
]
Christoph Läubrich commented on MNG-7637:
-
I see this NPE in test of m2eclipse where the user supplies the following pom:
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
some garbage maven project builder can't parse
{code}
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7637:
Affects Version/s: 4.0.0-alpha-3
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7637:
Affects Version/s: 3.8.6
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648982#comment-17648982
]
Michael Osipov commented on MNG-7637:
-
Darn, according to the schema the can be omitted, so this is a bug. Please
propose a patch this will be then in 3.8.7+.
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] laeubi opened a new pull request, #921: MNG-7637 - NPE in MavenProject#hashCode if incomplete xml
laeubi opened a new pull request, #921: URL: https://github.com/apache/maven/pull/921 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG-7637) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` 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. - [x] 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 [Core IT][core-its] successfully. 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. - [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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648983#comment-17648983
]
ASF GitHub Bot commented on MNG-7637:
-
laeubi opened a new pull request, #921:
URL: https://github.com/apache/maven/pull/921
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG-7637) 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.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` 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.
- [x] 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 [Core IT][core-its] successfully.
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.
- [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)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648984#comment-17648984
]
Michael Osipov commented on MNG-7637:
-
Do you think there are any other spots in the code which could lead to a NPE?
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7637:
---
Assignee: Michael Osipov
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7637:
Fix Version/s: 3.9.0
4.0.0
4.0.0-alpha-4
3.8.7
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648985#comment-17648985
]
Christoph Läubrich commented on MNG-7637:
-
Nothing I found directly, I think this is also rather a rare case, as these
most likely optional because a child can inherit it from a parent, so this case
can only arise for such cases where one really mess up things...
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) NPE in MavenProject#hashCode if erornous xml
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648986#comment-17648986
]
Michael Osipov commented on MNG-7637:
-
Then this is good to merge as-is.
> NPE in MavenProject#hashCode if erornous xml
>
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) NPE in MavenProject#hashCode()
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7637:
Summary: NPE in MavenProject#hashCode() (was: NPE in MavenProject#hashCode
if erornous xml)
> NPE in MavenProject#hashCode()
> --
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7637) Possible NPE in MavenProject#hashCode()
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7637:
Summary: Possible NPE in MavenProject#hashCode() (was: NPE in
MavenProject#hashCode())
> Possible NPE in MavenProject#hashCode()
> ---
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] olamy merged pull request #152: Bump qdox from 2.0.2 to 2.0.3
olamy merged PR #152: URL: https://github.com/apache/maven-compiler-plugin/pull/152 -- 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] asfgit closed pull request #921: MNG-7637 - NPE in MavenProject#hashCode if incomplete xml
asfgit closed pull request #921: MNG-7637 - NPE in MavenProject#hashCode if incomplete xml URL: https://github.com/apache/maven/pull/921 -- 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-7637) Possible NPE in MavenProject#hashCode()
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7637.
---
Resolution: Fixed
Fixed with
[7a1cc12a47a4082b7d6761bc960306bc8d9fd083|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7a1cc12a47a4082b7d6761bc960306bc8d9fd083],
with
[4db9b94baf520e34a5aa9f47cdf7c0053b910d83|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=4db9b94baf520e34a5aa9f47cdf7c0053b910d83]
for {{maven-3.9.x}} branch, with
[4fbbcc322ece8f07cd7d6c40b499c2afcdabf60c|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=4fbbcc322ece8f07cd7d6c40b499c2afcdabf60c]
for {{maven-3.8.x}} branch.
> Possible NPE in MavenProject#hashCode()
> ---
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7637) Possible NPE in MavenProject#hashCode()
[
https://issues.apache.org/jira/browse/MNG-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648988#comment-17648988
]
ASF GitHub Bot commented on MNG-7637:
-
asfgit closed pull request #921: MNG-7637 - NPE in MavenProject#hashCode if
incomplete xml
URL: https://github.com/apache/maven/pull/921
> Possible NPE in MavenProject#hashCode()
> ---
>
> Key: MNG-7637
> URL: https://issues.apache.org/jira/browse/MNG-7637
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.6, 4.0.0-alpha-3
>Reporter: Christoph Läubrich
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-4, 3.8.7
>
>
> org.apache.maven.project.MavenProject.hashCode() has the following code:
> {code:java}
> public int hashCode()
> {
> int hash = 17;
> hash = 31 * hash + getGroupId().hashCode();
> hash = 31 * hash + getArtifactId().hashCode();
> hash = 31 * hash + getVersion().hashCode();
> return hash;
> }
> {code}
> if any of those values is null, a NPE is thrown from the method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] asfgit closed pull request #918: [MNG-7636] Document MavenProject#getAttachedArtifacts() as read-only
asfgit closed pull request #918: [MNG-7636] Document MavenProject#getAttachedArtifacts() as read-only URL: https://github.com/apache/maven/pull/918 -- 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-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648998#comment-17648998
]
ASF GitHub Bot commented on MNG-7636:
-
asfgit closed pull request #918: [MNG-7636] Document
MavenProject#getAttachedArtifacts() as read-only
URL: https://github.com/apache/maven/pull/918
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x, but documented in 3.9.0 and 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648999#comment-17648999
]
Michael Osipov commented on MNG-7636:
-
Documentation updated in master:
[3eec6b82d32f9889a92b275ec21765a82ebae7c6|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=3eec6b82d32f9889a92b275ec21765a82ebae7c6].
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x, but documented in 3.9.0 and 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7636:
Description: Due to the lack of documentation it was never clear whether
{{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable or
not. Components used or abused this collection. The change was done in 3.8.x in
a patch release which was unfortunately and make things obvious. To better
address the breaking situation this change will be partially reverted in 3.8.x
and 3.9.0, but documented in 4.0.0 that the collection is read-only. A proper
solution to remove attached is desired in the future. (was: Due to the lack of
documentation it was never clear whether
{{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable or
not. Components used or abused this collection. The change was done in 3.8.x in
a patch release which was unfortunately and make things obvious. To better
address the breaking situation this change will be partially reverted in 3.8.x,
but documented in 3.9.0 and 4.0.0 that the collection is read-only. A proper
solution to remove attached is desired in the future.)
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x and 3.9.0, but documented in 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7473) Backport Maven BOM to Maven 3.9.x
[ https://issues.apache.org/jira/browse/MNG-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7473: Fix Version/s: (was: 3.9.0-candidate) > Backport Maven BOM to Maven 3.9.x > - > > Key: MNG-7473 > URL: https://issues.apache.org/jira/browse/MNG-7473 > Project: Maven > Issue Type: Task > Components: POM >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > It will ease lives of plugin developers a lot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7600) LocalRepositoryManager is created too early
[
https://issues.apache.org/jira/browse/MNG-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649004#comment-17649004
]
Michael Osipov commented on MNG-7600:
-
[~sjaranowski], is this bugfix worth back porting to 3.8.7?
> LocalRepositoryManager is created too early
> ---
>
> Key: MNG-7600
> URL: https://issues.apache.org/jira/browse/MNG-7600
> Project: Maven
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> {{LocalRepositoryManager}} needs configurations from
> {{RepositorySystemSession}}
> so must be created after session configuration is finished.
> In other case only System properties will be available during
> {{LocalRepositoryManager}} preparation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7106) VersionRange.toString() produces a string that cannot be parsed with VersionRange.createFromVersionSpec() for same lower and upper bounds
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7106:
Fix Version/s: 3.8.x-candidate
> VersionRange.toString() produces a string that cannot be parsed with
> VersionRange.createFromVersionSpec() for same lower and upper bounds
> -
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-2, 4.0.0
>
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7106) VersionRange.toString() produces a string that cannot be parsed with VersionRange.createFromVersionSpec() for same lower and upper bounds
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649005#comment-17649005
]
Michael Osipov commented on MNG-7106:
-
[~sjaranowski], is this bugfix worth back porting to 3.8.7?
> VersionRange.toString() produces a string that cannot be parsed with
> VersionRange.createFromVersionSpec() for same lower and upper bounds
> -
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7600) LocalRepositoryManager is created too early
[
https://issues.apache.org/jira/browse/MNG-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7600:
Fix Version/s: 3.8.x-candidate
> LocalRepositoryManager is created too early
> ---
>
> Key: MNG-7600
> URL: https://issues.apache.org/jira/browse/MNG-7600
> Project: Maven
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> {{LocalRepositoryManager}} needs configurations from
> {{RepositorySystemSession}}
> so must be created after session configuration is finished.
> In other case only System properties will be available during
> {{LocalRepositoryManager}} preparation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7106) VersionRange.toString() produces a string that cannot be parsed with VersionRange.createFromVersionSpec() for same lower and upper bounds
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649005#comment-17649005
]
Michael Osipov edited comment on MNG-7106 at 12/18/22 1:27 PM:
---
[~kwin], is this bugfix worth back porting to 3.8.7?
was (Author: michael-o):
[~sjaranowski], is this bugfix worth back porting to 3.8.7?
> VersionRange.toString() produces a string that cannot be parsed with
> VersionRange.createFromVersionSpec() for same lower and upper bounds
> -
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0
>
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7559:
---
Assignee: Elliotte Rusty Harold
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7559:
Fix Version/s: 4.0.0
4.0.0-alpha-3
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] pzygielo commented on pull request #914: Implement some `toString`s
pzygielo commented on PR #914: URL: https://github.com/apache/maven/pull/914#issuecomment-1356799202 @michael-o - [[HEADS UP] Maven 3.8.7](https://lists.apache.org/thread/7p81o29z56k1kw1tc3k5j1t5fg4rsr2d) - may I interest you in reviewing this change, please? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7559:
Fix Version/s: 3.8.x-candidate
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #914: Implement some `toString`s
michael-o commented on PR #914: URL: https://github.com/apache/maven/pull/914#issuecomment-1356805024 > @michael-o - [[HEADS UP] Maven 3.8.7](https://lists.apache.org/thread/7p81o29z56k1kw1tc3k5j1t5fg4rsr2d) - may I interest you in reviewing this change, please? Yes! Is is merged in 3.9.x and master? -- 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] asfgit merged pull request #920: [MNG-7636] Partially revert MNG-5868 to restore backward compatibilit…
asfgit merged PR #920: URL: https://github.com/apache/maven/pull/920 -- 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-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649007#comment-17649007
]
ASF GitHub Bot commented on MNG-7636:
-
asfgit merged PR #920:
URL: https://github.com/apache/maven/pull/920
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x and 3.9.0, but documented in 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] asfgit merged pull request #919: [MNG-7636] Partially revert MNG-5868 to restore backward compatibilit…
asfgit merged PR #919: URL: https://github.com/apache/maven/pull/919 -- 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] michael-o commented on pull request #601: [MNG-7316] MavenProject.getAttachedArtifacts() regression with 3.8.1
michael-o commented on PR #601: URL: https://github.com/apache/maven/pull/601#issuecomment-1356805631 The test hunk has been integrated into another PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7316) REGRESSION: MavenProject.getAttachedArtifacts() is read-only
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649010#comment-17649010
]
ASF GitHub Bot commented on MNG-7316:
-
michael-o commented on PR #601:
URL: https://github.com/apache/maven/pull/601#issuecomment-1356805631
The test hunk has been integrated into another PR.
> REGRESSION: MavenProject.getAttachedArtifacts() is read-only
>
>
> 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
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.9.0, 3.8.7
>
>
> 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.10#820010)
[GitHub] [maven] michael-o closed pull request #601: [MNG-7316] MavenProject.getAttachedArtifacts() regression with 3.8.1
michael-o closed pull request #601: [MNG-7316] MavenProject.getAttachedArtifacts() regression with 3.8.1 URL: https://github.com/apache/maven/pull/601 -- 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-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649008#comment-17649008
]
ASF GitHub Bot commented on MNG-7636:
-
asfgit merged PR #919:
URL: https://github.com/apache/maven/pull/919
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x and 3.9.0, but documented in 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7636) Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
[
https://issues.apache.org/jira/browse/MNG-7636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7636.
---
Resolution: Fixed
Fixed with
[a1d43778efe577f58f74ee84949f680fe017a14d|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=a1d43778efe577f58f74ee84949f680fe017a14d]
for {{maven-3.9.x}} branch, with
[8c65fcf01732685f7d085d58df5f8d56b0c8a303|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=8c65fcf01732685f7d085d58df5f8d56b0c8a303]
for {{maven-3.8.x}} branch.
> Partially revert MNG-5868 to restore backward compatibility (see MNG-7316)
> --
>
> Key: MNG-7636
> URL: https://issues.apache.org/jira/browse/MNG-7636
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.8.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> Due to the lack of documentation it was never clear whether
> {{org.apache.maven.project.MavenProject.getAttachedArtifacts()}} is mutable
> or not. Components used or abused this collection. The change was done in
> 3.8.x in a patch release which was unfortunately and make things obvious. To
> better address the breaking situation this change will be partially reverted
> in 3.8.x and 3.9.0, but documented in 4.0.0 that the collection is read-only.
> A proper solution to remove attached is desired in the future.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7316) REGRESSION: MavenProject.getAttachedArtifacts() is read-only
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649011#comment-17649011
]
ASF GitHub Bot commented on MNG-7316:
-
michael-o closed pull request #601: [MNG-7316]
MavenProject.getAttachedArtifacts() regression with 3.8.1
URL: https://github.com/apache/maven/pull/601
> REGRESSION: MavenProject.getAttachedArtifacts() is read-only
>
>
> 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
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.9.0, 3.8.7
>
>
> 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.10#820010)
[jira] [Closed] (MNG-7316) REGRESSION: MavenProject.getAttachedArtifacts() is read-only
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7316.
---
Resolution: Fixed
This has been implicitly addressed by MNG-7636 for the 3.x line. [~chtompki],
still owes me an explanation why he attaches and then detaches the same
artifacts. [~laeubi], though I do not fully understand your usecase, I think it
is justified. Feel free to raise a new ticket to improve the
{{MavenProjectHelper}}.
> REGRESSION: MavenProject.getAttachedArtifacts() is read-only
>
>
> 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
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.9.0, 3.8.7
>
>
> 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.10#820010)
[GitHub] [maven] michael-o opened a new pull request, #922: [MNG-7106] Accept same lower and upper bound in version spec string (…
michael-o opened a new pull request, #922: URL: https://github.com/apache/maven/pull/922 …#826) 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/MNG) 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 `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` 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 [Core IT][core-its] successfully. 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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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-7106) VersionRange.toString() produces a string that cannot be parsed with VersionRange.createFromVersionSpec() for same lower and upper bounds
[
https://issues.apache.org/jira/browse/MNG-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649014#comment-17649014
]
ASF GitHub Bot commented on MNG-7106:
-
michael-o opened a new pull request, #922:
URL: https://github.com/apache/maven/pull/922
…#826)
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/MNG) 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 `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` 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 [Core IT][core-its] successfully.
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).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> VersionRange.toString() produces a string that cannot be parsed with
> VersionRange.createFromVersionSpec() for same lower and upper bounds
> -
>
> Key: MNG-7106
> URL: https://issues.apache.org/jira/browse/MNG-7106
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Akshay Shankara
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-2, 4.0.0
>
>
> When a hard version requirement (Ex - [1.0]) is passed to
> [VersionRange#createFromVersionSpec(String)|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L106],
> it is parsed to [1.0, 1.0]. But, this version range is invalid [according to
> this
> exception|https://github.com/apache/maven/blob/maven-3.6.3/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/VersionRange.java#L214-L217].
> If the parsed version range ([1.0, 1.0]) is converted to a String, it cannot
> be parsed once again by VersionRange#createFromVersionSpec(String).
> Steps to reproduce -
> {code:java}
> VersionRange versionRange = VersionRange.createFromVersionSpec("[1.0]"); //
> [1.0, 1.0]
> String stringVersionRange = VersionRange.toString(versionRange); // "[1.0,
> 1.0]"
> VersionRange exceptionVersionRange =
> VersionRange.createFromVersionSpec(stringVersionRange); // <-
> InvalidVersionSpecificationException( "Range cannot have identical
> boundaries: [1.0, 1.0]" )
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] slawekjaranowski merged pull request #910: [MNG-7626] maven-bom should have the same parent version as project
slawekjaranowski merged PR #910: URL: https://github.com/apache/maven/pull/910 -- 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-7626) maven-bom should have the same parent version as project
[ https://issues.apache.org/jira/browse/MNG-7626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649015#comment-17649015 ] ASF GitHub Bot commented on MNG-7626: - slawekjaranowski merged PR #910: URL: https://github.com/apache/maven/pull/910 > maven-bom should have the same parent version as project > > > Key: MNG-7626 > URL: https://issues.apache.org/jira/browse/MNG-7626 > Project: Maven > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7626) maven-bom should have the same parent version as project
[ https://issues.apache.org/jira/browse/MNG-7626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MNG-7626. Fix Version/s: 4.0.0 4.0.0-alpha-4 Resolution: Fixed > maven-bom should have the same parent version as project > > > Key: MNG-7626 > URL: https://issues.apache.org/jira/browse/MNG-7626 > Project: Maven > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on pull request #915: Upgrade to parent 39 (and reformat)
slawekjaranowski commented on PR #915: URL: https://github.com/apache/maven/pull/915#issuecomment-1356808908 please also update in maven-bom -- 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] (MRESOURCES-288) make test jar reproducible
[
https://issues.apache.org/jira/browse/MRESOURCES-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MRESOURCES-288:
-
Fix Version/s: 3.3.1
> make test jar reproducible
> --
>
> Key: MRESOURCES-288
> URL: https://issues.apache.org/jira/browse/MRESOURCES-288
> Project: Maven Resources Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.3.1
>
>
> found when rebuilding release 3.3.0:
> {noformat}
> $ diffoscope target/reference/maven-resources-plugin-3.3.0-tests.jar
> target/maven-resources-plugin-3.3.0-tests.jar
> --- target/reference/maven-resources-plugin-3.3.0-tests.jar
> +++ target/maven-resources-plugin-3.3.0-tests.jar
> ├── zipinfo {}
> │ @@ -404,15 +404,15 @@
> │ -rw-r--r-- 2.0 unx 39 b- defN 22-Jul-23 17:48
> unit/test-dir/resourceSystemProperties_Filtering/src/test/resources/file4.txt
> │ --rw-r--r-- 2.0 unx 95 b- defN 22-Jul-23 17:48
> unit/test-dir/resourceSystemProperties_Filtering/target/classes/file4.txt
> │ +-rw-r--r-- 2.0 unx 80 b- defN 22-Jul-23 17:48
> unit/test-dir/resourceSystemProperties_Filtering/target/classes/file4.txt
> │ -rw-r--r-- 2.0 unx 0 b- defN 22-Jul-23 17:48
> unit/test-dir/resourceTargetPath/src/main/resources/file4.txt
> ├── unit/test-dir/resourceSystemProperties_Filtering/target/classes/file4.txt
> │ @@ -1 +1 @@
> │ -current-working-directory =
> D:\\Entwicklung\\Projekte\\maven-resources-plugin\\target\\checkout
> │ +current-working-directory =
> /Users/hboutemy/dev/tmp/maven-resources-plugin-3.3.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOURCES-278) Regression - Changed copy behaviour if files already exists
[ https://issues.apache.org/jira/browse/MRESOURCES-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649016#comment-17649016 ] Herve Boutemy commented on MRESOURCES-278: -- can you provide a sample project showing the failure, please? > Regression - Changed copy behaviour if files already exists > --- > > Key: MRESOURCES-278 > URL: https://issues.apache.org/jira/browse/MRESOURCES-278 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 3.3.0 >Reporter: Georg Tsakumagos >Priority: Critical > > With MSHARED-966 the behavior for the maven-resources-plugin changed > dramatically. > Now an exception is thown if an file already exists. > Before it was only overwritten if newer an no exception was thrown. > The new behavior breaks many builds. If this new behavior is a feature the > plugin site should be updated with a big (!) warning to everyone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] pzygielo commented on pull request #914: Implement some `toString`s
pzygielo commented on PR #914: URL: https://github.com/apache/maven/pull/914#issuecomment-1356813946 > > @michael-o - [[HEADS UP] Maven 3.8.7](https://lists.apache.org/thread/7p81o29z56k1kw1tc3k5j1t5fg4rsr2d) - may I interest you in reviewing this change, please? > > Yes! Is is merged in 3.9.x and master? I have only opened it against 3.8.x so far. There is no JIRA raised as I tried to check if there is interest in such change at 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
[GitHub] [maven-enforcer] slawekjaranowski commented on pull request #186: Bump junit-bom from 5.9.0 to 5.9.1
slawekjaranowski commented on PR #186: URL: https://github.com/apache/maven-enforcer/pull/186#issuecomment-1356814703 @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] (MRESOURCES-292) describe from and to in "Copying x resources" info message
Herve Boutemy created MRESOURCES-292: Summary: describe from and to in "Copying x resources" info message Key: MRESOURCES-292 URL: https://issues.apache.org/jira/browse/MRESOURCES-292 Project: Maven Resources Plugin Issue Type: Improvement Components: copy Affects Versions: 3.3.0 Reporter: Herve Boutemy Fix For: 3.3.1 Currently, default destination directory is either implicit or shown with full path, and from is hidden: [INFO] — maven-resources-plugin:3.3.0:resources (default-resources) @ demo — [INFO] Copying 3 resources [INFO] Copying 70 resources to /noisy/path/to/project/target/site-src [INFO] — maven-resources-plugin:3.3.0:testResources (default-testResources) @ demo — [INFO] Copying 39 resources It would be much clearer to always see info as relative: [INFO] — maven-resources-plugin:3.3.1-SNAPSHOT:resources (default-resources) @ demo — [INFO] Copying 3 resources from src/main/resources to target/classes [INFO] Copying 70 resources from src/site to target/site-src [INFO] — maven-resources-plugin:3.3.1-SNAPSHOT:testResources (default-testResources) @ demo — [INFO] Copying 39 resources from src/test/resources to target/test-classes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1175) describe from and to in "Copying x resources" info message
Herve Boutemy created MSHARED-1175: -- Summary: describe from and to in "Copying x resources" info message Key: MSHARED-1175 URL: https://issues.apache.org/jira/browse/MSHARED-1175 Project: Maven Shared Components Issue Type: Improvement Components: maven-filtering Affects Versions: maven-filtering-3.3.0 Reporter: Herve Boutemy Fix For: maven-filtering-3.3.1 see MRESOURCES-292 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-442) Bump Mockito from 4.7.0 to 4.10.0
Slawomir Jaranowski created MENFORCER-442: - Summary: Bump Mockito from 4.7.0 to 4.10.0 Key: MENFORCER-442 URL: https://issues.apache.org/jira/browse/MENFORCER-442 Project: Maven Enforcer Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #197: [MENFORCER-442] Bump mockito.version from 4.7.0 to 4.10.0
slawekjaranowski merged PR #197: URL: https://github.com/apache/maven-enforcer/pull/197 -- 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-filtering] hboutemy opened a new pull request, #62: [MSHARED-1175] Copying x resources from rel/path to rel/path
hboutemy opened a new pull request, #62: URL: https://github.com/apache/maven-filtering/pull/62 see https://issues.apache.org/jira/browse/MSHARED-1175 -- 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] michael-o commented on pull request #914: Implement some `toString`s
michael-o commented on PR #914: URL: https://github.com/apache/maven/pull/914#issuecomment-1356817229 Looking at ... -- 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-7600) LocalRepositoryManager is created too early
[
https://issues.apache.org/jira/browse/MNG-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649028#comment-17649028
]
Slawomir Jaranowski commented on MNG-7600:
--
[~michael-o] Can be. To have a complete code here we also can consider: MNG-7590
> LocalRepositoryManager is created too early
> ---
>
> Key: MNG-7600
> URL: https://issues.apache.org/jira/browse/MNG-7600
> Project: Maven
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> {{LocalRepositoryManager}} needs configurations from
> {{RepositorySystemSession}}
> so must be created after session configuration is finished.
> In other case only System properties will be available during
> {{LocalRepositoryManager}} preparation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #914: Implement some `toString`s
michael-o commented on PR #914: URL: https://github.com/apache/maven/pull/914#issuecomment-1356820610 Merged with 6c53b28ecc84f0f90d5417f199d99b20334f26d7. -- 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] michael-o closed pull request #914: Implement some `toString`s
michael-o closed pull request #914: Implement some `toString`s URL: https://github.com/apache/maven/pull/914 -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649031#comment-17649031
]
Michael Osipov commented on MNG-7559:
-
The handling of this issue is a mess. [~elharo], please clean up which PRs have
been merged, close this and link the commit message in our canonical repos. I
am not able to follow/understand what happened here.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0, 4.0.0-alpha-3
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7590) Allow configure resolver by properties in settings.xml
[ https://issues.apache.org/jira/browse/MNG-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7590: Fix Version/s: 4.0.0 (was: 4.0.x-candidate) > Allow configure resolver by properties in settings.xml > -- > > Key: MNG-7590 > URL: https://issues.apache.org/jira/browse/MNG-7590 > Project: Maven > Issue Type: Improvement >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3 > > > New Artifact Resolver has many useful configuration options, currently we > only have the option to pass them as system or user properties. > It will be useful to have possibility to provide them by properties in > settings.xml to have whole configuration in one place. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5577: Fix Version/s: 4.0.0 > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-2, 4.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. > *NOTE:* The descriptor must still be generated, since Maven doesn't do > annotation scanning for performance reason. It simply reads the descriptor > file(s). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6991:
Affects Version/s: 4.0.0-alpha-2
(was: 3.0-alpha-1)
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-2
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 4.0.0-alpha-2
>
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7505) Remove ReportingConverter
[
https://issues.apache.org/jira/browse/MNG-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7505:
Fix Version/s: 4.0.0
> Remove ReportingConverter
> -
>
> Key: MNG-7505
> URL: https://issues.apache.org/jira/browse/MNG-7505
> Project: Maven
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> In m-site-p 3.7 configuration parameter {{reportPlugins}} was removed -
> MSITE-792
> So converting from reporting sections to {{reportPlugins}} option of m-site-p
> is not needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7580) New settings and toolchains builders
[ https://issues.apache.org/jira/browse/MNG-7580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7580: Fix Version/s: 4.0.0 > New settings and toolchains builders > > > Key: MNG-7580 > URL: https://issues.apache.org/jira/browse/MNG-7580 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-2 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7578:
Fix Version/s: 4.0.0
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7586) Update Maven Resolver to 1.9.2
[ https://issues.apache.org/jira/browse/MNG-7586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7586: Fix Version/s: 4.0.0 > Update Maven Resolver to 1.9.2 > -- > > Key: MNG-7586 > URL: https://issues.apache.org/jira/browse/MNG-7586 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3 > > > Update Maven Resolver to 1.9.2 (releases 1.9.0 and 1.9.1 are fluke due > different reasons). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7596) Upgrade to plexus-utils 3.5.0
[ https://issues.apache.org/jira/browse/MNG-7596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7596: Fix Version/s: 4.0.0 > Upgrade to plexus-utils 3.5.0 > - > > Key: MNG-7596 > URL: https://issues.apache.org/jira/browse/MNG-7596 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7583) Allow concurrent access to the MavenPluginManager
[ https://issues.apache.org/jira/browse/MNG-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7583: Fix Version/s: 4.0.0 > Allow concurrent access to the MavenPluginManager > - > > Key: MNG-7583 > URL: https://issues.apache.org/jira/browse/MNG-7583 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7616) Add missing exported artifacts for the new API
[ https://issues.apache.org/jira/browse/MNG-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7616: Fix Version/s: 4.0.0 > Add missing exported artifacts for the new API > -- > > Key: MNG-7616 > URL: https://issues.apache.org/jira/browse/MNG-7616 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7618) Use goalPrefix instead of artifactId to display mojos being executed
[
https://issues.apache.org/jira/browse/MNG-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7618:
Fix Version/s: 4.0.0
> Use goalPrefix instead of artifactId to display mojos being executed
> -
>
> Key: MNG-7618
> URL: https://issues.apache.org/jira/browse/MNG-7618
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> The main problem is that the information displayed when starting a mojo looks
> like:
> {code:java}
> [INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce-maven-version) @
> camel ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce-java-version) @ camel
> ---
> [INFO]
> {code}
> However, if you try to execute {{{}maven-enforcer-plugin:3.0.0:enforce{}}},
> you end up with the following:
> {code:java}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> Downloading from apache.snapshots:
> https://repository.apache.org/snapshots/maven-enforcer-plugin/3.0.0/maven-metadata.xml
> Downloading from central:
> https://repo.maven.apache.org/maven2/maven-enforcer-plugin/3.0.0/maven-metadata.xml
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.879 s
> [INFO] Finished at: 2022-12-03T12:12:40+01:00
> [INFO]
>
> [ERROR] Error resolving version for plugin 'maven-enforcer-plugin:3.0.0' from
> the repositories [local (/Users/gnodet/.m2/repository), apache.snapshots
> (https://repository.apache.org/snapshots/), central
> (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin
> repository -> [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/PluginVersionResolutionException
> {code}
>
> I suggest to change the display to the {{pluginPrefix}} which gives
> {code}
> [INFO] ---< org.apache.camel:camel
> >---
> [INFO] Building Camel 4.0.0-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ pom
> ]-
> [WARN] Parameter 'reportPlugins' is unknown for plugin
> 'maven-site-plugin:3.11.0:attach-descriptor (attach-descriptor)'
> [INFO]
> [INFO] --- enforcer:3.0.0:enforce (enforce-maven-version) @ camel ---
> [INFO]
> [INFO] --- enforcer:3.0.0:enforce (enforce-java-version) @ camel ---
> [INFO]
> [INFO] --- enforcer:3.0.0:enforce (enforce-maven) @ camel ---
> [INFO]
> {code}
> which can then be easily executed:
> {code}
> ➜ maven git:(build-improvements) ✗ mvn -N -f ../camel flatten:1.2.5:flatten
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Processing build on daemon 56c20cb8
> [INFO] Scanning for projects...
> [INFO] BuildTimeEventSpy is registered.
> [INFO]
> [INFO] Using the SmartBuilder implementation with a thread count of 9
> [INFO] Task segments : [flatten:1.2.5:flatten]
> [INFO] Build maximum degree of concurrency is 9
> [INFO] Total number of projects is 1
> [INFO]
> [INFO] ---< org.apache.camel:camel
> >---
> [INFO] Building Camel 4.0.0-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] --- flatten:1.2.5:flatten (default-cli) @ camel ---
> [INFO] Generating flattened POM of project
> org.apache.camel:camel:pom:4.0.0-SNAPSHOT...
> [INFO] Segment walltime 0 s, segment projects service time 0 s,
> effective/maximum degree of concurrency 0.97/9
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.025 s (Wall Clock)
> [INFO] Finished at: 2022-12-03T12:14:29+01:00
> [INFO]
>
> ➜ maven git:(build-improvements) ✗
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7619) Maven should explain why an artifact is present in local repository
[
https://issues.apache.org/jira/browse/MNG-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7619:
Fix Version/s: 4.0.0
(was: 4.0.x-candidate)
> Maven should explain why an artifact is present in local repository
> ---
>
> Key: MNG-7619
> URL: https://issues.apache.org/jira/browse/MNG-7619
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> Ability to make Maven record:
> * why given artifact is present in local repository
> * record reverse dep tree how this artifact got resolved
> This is mostly for detecting dependency resolution anomalies, ideally best
> combined with {{-Dmaven.repo.local}} when you use new/empty local repo to
> build a project. After the build, you will end up with reverse dep trees in
> {{.tracking}} directories for each artifact.
> To enable, pass {{-Dmaven.repo.local.recordReverseTree}} on CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7098:
Fix Version/s: 4.0.0
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.0-alpha-2, 4.0.0
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7098:
---
Assignee: Guillaume Nodet
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-2, 4.0.0
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7183) Plugin declaration silently ignored if groupId uses property references
[
https://issues.apache.org/jira/browse/MNG-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649039#comment-17649039
]
Michael Osipov commented on MNG-7183:
-
[~gnodet], do you want to take a look at this?
> Plugin declaration silently ignored if groupId uses property references
> ---
>
> Key: MNG-7183
> URL: https://issues.apache.org/jira/browse/MNG-7183
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build, Inheritance and Interpolation
>Affects Versions: 3.6.2, 3.6.3, 3.8.1
>Reporter: Martin D'Aloia
>Priority: Minor
> Attachments: bug-example.zip
>
>
> Declaring a plugin where its {{}} value is/contains a property
> reference ({{$\{example}}}) is silently ignored and no error is thrown since
> Maven 3.6.2 (worked on 3.6.1).
> *Actual behavior:*
> - Plugin configuration silently ignored
> *Expected behavior:*
> - Work as in 3.6.1, or
> - Produce an error if such config is not allowed
> *Workaround:*
> * Use a static value for the without property references
> *Suspecting root cause:*
> * MNG-6697
> Attached you could find a self-contained example using the
> {{maven-clean-plugin}} (but also happens with third-party plugins).
> To ease the comparison, this has 2 profiles: one declares the value
> explicitly and the other (indirect) via a property reference.
> Execute it as: {{./run.sh}}
> and you will get at the end:
> {noformat}
> ./out/maven-3.8.1-profile-indirect.log:[INFO] ---
> maven-clean-plugin:2.5:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.8.1-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.8.1-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.8.1-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.3-profile-indirect.log:[INFO] ---
> maven-clean-plugin:2.5:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.3-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.6.3-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.3-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.2-profile-indirect.log:[INFO] ---
> maven-clean-plugin:2.5:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.2-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.6.2-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.2-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.1-profile-indirect.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.1-profile-indirect.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.1-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.1-profile-explicit.log:[DEBUG] (f) skip = true
> {noformat}
> Here you could see that the plugin version (2.5) and skip (false)
> configuration isn't what was configured for {{indirect}} profile.
> Another example, defining a base config as {{}}, it is also
> ignoring the specific {{}} on {{}} usage.
> Execute it as: {{./run.sh pom-pluginManagement.xml}}
> and you will get at the end:
> {noformat}
> ./out/maven-3.8.1-profile-indirect.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.8.1-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.8.1-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.8.1-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.3-profile-indirect.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.3-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.6.3-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.3-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.2-profile-indirect.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.2-profile-indirect.log:[DEBUG] (f) skip = false
> ./out/maven-3.6.2-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.2-profile-explicit.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.1-profile-indirect.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-3.6.1-profile-indirect.log:[DEBUG] (f) skip = true
> ./out/maven-3.6.1-profile-explicit.log:[INFO] ---
> maven-clean-plugin:3.1.0:clean (default-clean) @ maven-bug-example ---
> ./out/maven-
[jira] [Commented] (MNG-7610) ValidatingConfigurationListener doesn't validate, causing wrong "parameters ... are missing or invalid" errors
[
https://issues.apache.org/jira/browse/MNG-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649040#comment-17649040
]
Michael Osipov commented on MNG-7610:
-
[~sjaranowski], do you want to take a look at this?
> ValidatingConfigurationListener doesn't validate, causing wrong "parameters
> ... are missing or invalid" errors
> --
>
> Key: MNG-7610
> URL: https://issues.apache.org/jira/browse/MNG-7610
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.6
> Environment: mvn -version
> Apache Maven 3.8.6
> java -version
> openjdk version "11" 2018-09-25
>Reporter: Peter Bugla
>Priority: Major
>
> Applies to mvn 3.8.6 (and at least some earlier versions, but our project
> uses 3.8.6 now), mvn-core.
> {*}Short description{*}:
> ValidatingConfigurationListener (see constructor) considers all parameters
> marked as required in a plugin as missing, causing an otherwise perfectly
> fine mvn run to wrongly end with an error statement
> Detailed description:
> *Short intro* / history / pointing out that it's not my rare irrelevant
> personal issue:
> There are already some articles on StackOverflow getting the following error
> message after an mvn run that uses a plugin, which has at least one required
> parameter.
> Apart from obvious user errors, where someone just forgot to set a required
> parameter, looking closely there are also a bunch of cases (including mine)
> where the required parameter(s) are set perfectly fine, the triggered plugin
> execution used them successfully, so they were obviously there, but mvn still
> ends with the error statement.:
> [ERROR] Failed to execute goal
> ::: (default-cli) on
> project : The parameters
> '' for goal
> ::: are missing or
> invalid
> --
> *Specific example* (the one I encountered):
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:3.1.0:java
> (default-cli) on project qat.lup.alltests: The parameters 'mainClass' for
> goal org.codehaus.mojo:exec-maven-plugin:3.1.0:java are missing or invalid
> Excerpt from my pom.xml:
>
> org.codehaus.mojo
> exec-maven-plugin
> 3.1.0
>
>
> MyExecutionId
>
> java
>
>
>
>
> full.package.ClassName
>
> argument_1_for_class_ClassName
> argument_2_for_class_ClassName
> argument_3_for_class_ClassName
>
>
>
> Started with:
> mvn -s settings.xml exec:java
> Run result:
> The execution of full.package.ClassName via the plugin worked perfectly. So
> obviously "mainClass" was found and read correctly by exec-maven-plugin,
> otherwise it would have failed.
> However that mvn run always ends with the error message:
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:3.1.0:java
> (default-cli) on project qat.lup.alltests: The parameters 'mainClass' for
> goal org.codehaus.mojo:exec-maven-plugin:3.1.0:java are missing or invalid
> --
> *My analysis* (all file names and line numbers are references against mvn
> 3.8.6 checked out with the according tag from your git):
> As there was no answer in StackOverflow that worked for me, I dug deeper in
> my case:
> The relevant configuration in plugin.xml of
> org.codehaus.mojo:exec-maven-plugin:3.1.0 concerning the parameter mainClass
> seems fine (it's set as required as expected, no visible issue with that).
> So I checked where that error message originates from and backtrack from
> there:
> - The error message is from
> PluginParameterException.java:45
> (org.apache.maven.plugin.PluginParameterException) (in constructor).
> - this (in the relevant case) is called from DefaultMavenPluginManager.java
> (in multiple places, but I believe the relevant one here is:
> DefaultMavenPluginManager.java:644
> (org.apache.maven.plugin.internal.DefaultMavenPluginManager) (in
> populatePluginFields)
> - DefaultMavenPluginManager.java:630 calls
> ValidatingConfigurationListener.java:46 (constructor) and I think in there is
> the issue:
> It gets the parameters from the mojoDescriptor, checks if they are marked
> as required and if yes adds them to "missingParameters" without
> checking if the parameters are actually present in the parameters supplied
> to the "mojo".
> DefaultMavenPluginManager.java:639 then gets "missingParameters" from
> ValidatingConfigurationListener and turns that into a
> PluginParam
[jira] [Updated] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
[ https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7536: Fix Version/s: waiting-for-feedback > Mojo execution locking in Maven 3.8.5 deadlocks my plugin > - > > Key: MNG-7536 > URL: https://issues.apache.org/jira/browse/MNG-7536 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.8.6 >Reporter: David Elliott >Assignee: Guillaume Nodet >Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: thread-example.tar.gz > > > I have an existing mojo which stopped working in Maven 3.8.5 but had been > working for years. It looks like MNG-7156 is the cause. > This mojo looks through its dependencies for other reactor projects, then > looks at those projects for any plugin executions with a special phase name. > For all found executions, it executes them in a thread pool as part of some > other processing it is doing. > My plugin is proprietary and I am unable to share it, but I am able to share > a much smaller example illustrating the problem. > Being example code, it just spawns a thread to run the mojo executions and > attempts to join the thread. In the real code all executions for a given > project will run sequentially on one thread, but each project's work will be > scheduled concurrently on a thread pool. > I didn't feel it was necessary to use a thread pool and schedule more than > one project's executions for this example. The deadlock will occur simply by > running any mojo at all on a secondary thread while the calling thread is > running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
[ https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649041#comment-17649041 ] Michael Osipov commented on MNG-7536: - [~dfelliott], can you verify [~gnodet]'s proposal? > Mojo execution locking in Maven 3.8.5 deadlocks my plugin > - > > Key: MNG-7536 > URL: https://issues.apache.org/jira/browse/MNG-7536 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.8.6 >Reporter: David Elliott >Assignee: Guillaume Nodet >Priority: Major > Fix For: waiting-for-feedback, wontfix-candidate > > Attachments: thread-example.tar.gz > > > I have an existing mojo which stopped working in Maven 3.8.5 but had been > working for years. It looks like MNG-7156 is the cause. > This mojo looks through its dependencies for other reactor projects, then > looks at those projects for any plugin executions with a special phase name. > For all found executions, it executes them in a thread pool as part of some > other processing it is doing. > My plugin is proprietary and I am unable to share it, but I am able to share > a much smaller example illustrating the problem. > Being example code, it just spawns a thread to run the mojo executions and > attempts to join the thread. In the real code all executions for a given > project will run sequentially on one thread, but each project's work will be > scheduled concurrently on a thread pool. > I didn't feel it was necessary to use a thread pool and schedule more than > one project's executions for this example. The deadlock will occur simply by > running any mojo at all on a secondary thread while the calling thread is > running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7536) Mojo execution locking in Maven 3.8.5 deadlocks my plugin
[ https://issues.apache.org/jira/browse/MNG-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7536: Fix Version/s: wontfix-candidate > Mojo execution locking in Maven 3.8.5 deadlocks my plugin > - > > Key: MNG-7536 > URL: https://issues.apache.org/jira/browse/MNG-7536 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5, 3.8.6 >Reporter: David Elliott >Assignee: Guillaume Nodet >Priority: Major > Fix For: wontfix-candidate > > Attachments: thread-example.tar.gz > > > I have an existing mojo which stopped working in Maven 3.8.5 but had been > working for years. It looks like MNG-7156 is the cause. > This mojo looks through its dependencies for other reactor projects, then > looks at those projects for any plugin executions with a special phase name. > For all found executions, it executes them in a thread pool as part of some > other processing it is doing. > My plugin is proprietary and I am unable to share it, but I am able to share > a much smaller example illustrating the problem. > Being example code, it just spawns a thread to run the mojo executions and > attempts to join the thread. In the real code all executions for a given > project will run sequentially on one thread, but each project's work will be > scheduled concurrently on a thread pool. > I didn't feel it was necessary to use a thread pool and schedule more than > one project's executions for this example. The deadlock will occur simply by > running any mojo at all on a secondary thread while the calling thread is > running a mojo waiting for that secondary thread to complete. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649042#comment-17649042
]
Emmanuel Bourg commented on MRESOURCES-237:
---
This issue is marked as fixed in the version 3.3.0, but there is no mention of
MRESOURCES-237 in the commit history. Is the resolution actually Won't Fix ?
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.2.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: a.tgz
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7546) A NullPointerException on recursive propety definition
[
https://issues.apache.org/jira/browse/MNG-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649043#comment-17649043
]
Michael Osipov commented on MNG-7546:
-
Still waiting for the sample.
> A NullPointerException on recursive propety definition
> --
>
> Key: MNG-7546
> URL: https://issues.apache.org/jira/browse/MNG-7546
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.8.6
>Reporter: Ondrej
>Priority: Trivial
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> A NPE occured when I have changed some versions to a ${...} expression using
> find & replace.
> That also replaced the property definition:
> <{color:#002586}version.testcontainers{color}>${version.testcontainers}
> ...
> <{color:#002586}dependency{color}><{color:#002586}groupId{color}>org.testcontainers<{color:#002586}artifactId{color}>testcontainers<{color:#002586}type{color}>pom<{color:#002586}version{color}>${version.testcontainers}<{color:#002586}scope{color}>test
> This resulted in the following NPE:
> {code:java}
> /usr/lib/jvm/java-1.18.0-openjdk-amd64/bin/java
> -Dmaven.multiModuleProjectDirectory=/home/o/work/tracker-service/tracker-service
> -Dmaven.home=/snap/intellij-idea-community/387/plugins/maven/lib/maven3
> -Dclassworlds.conf=/snap/intellij-idea-community/387/plugins/maven/lib/maven3/bin/m2.conf
>
> -Dmaven.ext.class.path=/snap/intellij-idea-community/387/plugins/maven/lib/maven-event-listener.jar
>
> -javaagent:/snap/intellij-idea-community/387/lib/idea_rt.jar=46145:/snap/intellij-idea-community/387/bin
> -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8
> -Dsun.stderr.encoding=UTF-8 -classpath
> /snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds-2.6.0.jar:/snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds.license
> org.codehaus.classworlds.Launcher -Didea.version=2022.2.2 compile
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:577)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap$MapEntry.setValue
> (ConcurrentHashMap.java:3546)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1429)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1027)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:170)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
> (StringVisitorModelInterpolator.java:107)
> at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
> (DefaultModelBuilder.java:789)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:393)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:448)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:414)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:377)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven
[jira] [Updated] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7352: Issue Type: Improvement (was: Bug) > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Priority: Trivial > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7546) A NullPointerException on recursive propety definition
[
https://issues.apache.org/jira/browse/MNG-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7546:
Fix Version/s: waiting-for-feedback
wontfix-candidate
> A NullPointerException on recursive propety definition
> --
>
> Key: MNG-7546
> URL: https://issues.apache.org/jira/browse/MNG-7546
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.8.6
>Reporter: Ondrej
>Priority: Trivial
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> A NPE occured when I have changed some versions to a ${...} expression using
> find & replace.
> That also replaced the property definition:
> <{color:#002586}version.testcontainers{color}>${version.testcontainers}
> ...
> <{color:#002586}dependency{color}><{color:#002586}groupId{color}>org.testcontainers<{color:#002586}artifactId{color}>testcontainers<{color:#002586}type{color}>pom<{color:#002586}version{color}>${version.testcontainers}<{color:#002586}scope{color}>test
> This resulted in the following NPE:
> {code:java}
> /usr/lib/jvm/java-1.18.0-openjdk-amd64/bin/java
> -Dmaven.multiModuleProjectDirectory=/home/o/work/tracker-service/tracker-service
> -Dmaven.home=/snap/intellij-idea-community/387/plugins/maven/lib/maven3
> -Dclassworlds.conf=/snap/intellij-idea-community/387/plugins/maven/lib/maven3/bin/m2.conf
>
> -Dmaven.ext.class.path=/snap/intellij-idea-community/387/plugins/maven/lib/maven-event-listener.jar
>
> -javaagent:/snap/intellij-idea-community/387/lib/idea_rt.jar=46145:/snap/intellij-idea-community/387/bin
> -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8
> -Dsun.stderr.encoding=UTF-8 -classpath
> /snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds-2.6.0.jar:/snap/intellij-idea-community/387/plugins/maven/lib/maven3/boot/plexus-classworlds.license
> org.codehaus.classworlds.Launcher -Didea.version=2022.2.2 compile
> [INFO] Scanning for projects...
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:577)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> at org.codehaus.classworlds.Launcher.main (Launcher.java:47)
> Caused by: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap$MapEntry.setValue
> (ConcurrentHashMap.java:3546)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1429)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1027)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:170)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
> (StringVisitorModelInterpolator.java:107)
> at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
> (DefaultModelBuilder.java:789)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:393)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:448)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:414)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:377)
> at org.apache.maven.graph.DefaultGraphBuilder.collectProjects
> (DefaultGraphBuilder.java:414)
> at org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor
> (DefaultGraphBuilder.java:405)
> at org.apache.maven.graph.DefaultGraphBuilder.build
> (DefaultGraphBuilder.java:82)
> at org.apache.maven.DefaultMaven.buildGraph (DefaultMaven.java:507)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMav
[jira] [Commented] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649044#comment-17649044
]
Michael Osipov commented on MNG-7425:
-
[~breun], can you try https://maven.apache.org/resolver/maven-3.8.x.html?
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649045#comment-17649045
]
Michael Osipov commented on MNG-7425:
-
[~cstamas], I believe this is implicitly fixed in 3.9.0 with Resolver 1.8.x.
WDYT?
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7425) Maven artifact downloads sometimes result in empty zip files in local repository
[
https://issues.apache.org/jira/browse/MNG-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7425:
Fix Version/s: 3.9.0-candidate
> Maven artifact downloads sometimes result in empty zip files in local
> repository
>
>
> Key: MNG-7425
> URL: https://issues.apache.org/jira/browse/MNG-7425
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Nils Breunese
>Priority: Major
> Fix For: 3.9.0-candidate
>
>
> I’ve been encountering Maven warnings like these for years from time to time:
> {code}
> WARN: zip file is empty:
> /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar
> java.util.zip.ZipException: zip file is empty
> {code}
> This issue causes builds to fail. While I am sure that Maven 3.8.4 is
> affected, this is certainly not the oldest version that is affected.
> According to [the thread I started about this on the Maven users mailinglist
> this issue|https://lists.apache.org/thread/5kq5xkwdm2583dhfor78vf0l5mc11l9x]
> occurs on at least macOS, Linux and Windows.
> I know that when I encounter this I can just delete the file and run Maven
> again and then it’ll generally download ok, but this a manual workaround for
> an issue that shouldn't exist in the first place.
> * Could Maven be modified to ensure that 0 bytes artifacts don't end up in
> the local repository?
> * Would it make sense for Maven to assume that an empty JAR file was not
> downloaded correctly and the download should be retried automatically?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7399) Intermittent failures on Java 18-EA / 19-EA on Windows x86 (32-bit)
[
https://issues.apache.org/jira/browse/MNG-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649047#comment-17649047
]
Michael Osipov commented on MNG-7399:
-
Did anyone try to re-evaluate this?
> Intermittent failures on Java 18-EA / 19-EA on Windows x86 (32-bit)
> ---
>
> Key: MNG-7399
> URL: https://issues.apache.org/jira/browse/MNG-7399
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.4
>Reporter: Dmitry Bedrin
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> I'm maintaining open-source project (multi-module Maven) and my CI/CD builds
> it on 3 platforms (Linux, MacOS, Windows) on Java versions from 6 to 19-ea
> both 64 bit and 32 bit (where available).
> After adding JDK 18-ea and 19-ea to the compatibility matrix I've noticed
> that builds on Windows *32bit* are failing with errors like these:
>
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.2.0:jar (default-jar) on project
> sniffy: The parameters 'classesDirectory', 'outputDirectory' for goal
> org.apache.maven.plugins:maven-jar-plugin:3.2.0:jar are missing or invalid ->
> [Help 1]{noformat}
>
> Another example with stack trace from compiler plugin (other plugins fail as
> well):
> {noformat}[INFO] --- maven-compiler-plugin:3.9.0:compile (default-compile) @
> sniffy ---
> [DEBUG] Dependency collection stats {ConflictMarker.analyzeTime=9500,
> ConflictMarker.markTime=9500, ConflictMarker.nodeCount=17,
> ConflictIdSorter.graphTime=5100, ConflictIdSorter.topsortTime=8400,
> ConflictIdSorter.conflictIdCount=12, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=60300, ConflictResolver.conflictItemCount=17,
> DefaultDependencyCollector.collectTime=1351500,
> DefaultDependencyCollector.transformTime=101700}
> [DEBUG] org.apache.maven.plugins:maven-compiler-plugin:jar:3.9.0
> [DEBUG]org.apache.maven.shared:maven-shared-utils:jar:3.3.4:compile
> [DEBUG] commons-io:commons-io:jar:2.6:compile
> [DEBUG]org.apache.maven.shared:maven-shared-incremental:jar:1.1:compile
> [DEBUG]
> org.codehaus.plexus:plexus-component-annotations:jar:2.0.0:compile (version
> managed from default)
> [DEBUG]org.codehaus.plexus:plexus-java:jar:1.1.0:compile
> [DEBUG] org.ow2.asm:asm:jar:9.2:compile
> [DEBUG] com.thoughtworks.qdox:qdox:jar:2.0.1:compile (version managed
> from default)
> [DEBUG]org.codehaus.plexus:plexus-compiler-api:jar:2.9.0:compile
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:3.3.0:compile
> [DEBUG]org.codehaus.plexus:plexus-compiler-manager:jar:2.9.0:compile
> [DEBUG]org.codehaus.plexus:plexus-compiler-javac:jar:2.9.0:runtime
> [DEBUG] Created new class realm
> plugin>org.apache.maven.plugins:maven-compiler-plugin:3.9.0--107150504
> [DEBUG] Importing foreign packages into class realm
> plugin>org.apache.maven.plugins:maven-compiler-plugin:3.9.0--107150504
> [DEBUG] Imported: < project>io.sniffy:sniffy:3.1.13-SNAPSHOT
> [DEBUG] Populating class realm
> plugin>org.apache.maven.plugins:maven-compiler-plugin:3.9.0--107150504
> [DEBUG] Included: org.apache.maven.plugins:maven-compiler-plugin:jar:3.9.0
> [DEBUG] Included: org.apache.maven.shared:maven-shared-utils:jar:3.3.4
> [DEBUG] Included: commons-io:commons-io:jar:2.6
> [DEBUG] Included: org.apache.maven.shared:maven-shared-incremental:jar:1.1
> [DEBUG] Included: org.codehaus.plexus:plexus-component-annotations:jar:2.0.0
> [DEBUG] Included: org.codehaus.plexus:plexus-java:jar:1.1.0
> [DEBUG] Included: org.ow2.asm:asm:jar:9.2
> [DEBUG] Included: com.thoughtworks.qdox:qdox:jar:2.0.1
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-api:jar:2.9.0
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:3.3.0
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-manager:jar:2.9.0
> [DEBUG] Included: org.codehaus.plexus:plexus-compiler-javac:jar:2.9.0
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-compiler-plugin:3.9.0:compile from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-compiler-plugin:3.9.0--107150504,
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@1ebdb06]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:3.9.0:compile' with basic
> configurator -->
> [DEBUG] (f) basedir = C:\work\github\sniffy\sniffy
> [DEBUG] (f) compilePath = []
> [DEBUG] (f) compileSourceRoots = []
> [DEBUG] (f) compilerId = javac
> [DEBUG] (f) debug = true
> [DEBUG] (f) encoding = UTF-8
> [DEBUG] (f) failOnError = true
> [DEBUG] (f) failOnWarning = false
> [DEBUG] (f) forceJavacCompilerUse = false
> [DEBUG] (f) fork = false
> [DEBUG] (f) generatedSourcesDirectory =
> C:\work\github\sni
[jira] [Updated] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7352: Issue Type: Bug (was: Improvement) > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Priority: Trivial > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7352: --- Assignee: Michael Osipov > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Assignee: Michael Osipov >Priority: Trivial > Fix For: waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7352: Fix Version/s: waiting-for-feedback > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Priority: Trivial > Fix For: waiting-for-feedback > > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7352) org.apache.maven.toolchain.java.JavaToolchainImpl should be public
[ https://issues.apache.org/jira/browse/MNG-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649048#comment-17649048 ] Michael Osipov commented on MNG-7352: - Look at 61f1d01ba86e0765e0a78eb0b18571ee503055f6. [~hboutemy], well this class was public, you assumed it should be package private, though the deprecated one does not provide a public successor. I am included to make this public again. WDYT? > org.apache.maven.toolchain.java.JavaToolchainImpl should be public > -- > > Key: MNG-7352 > URL: https://issues.apache.org/jira/browse/MNG-7352 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.4 >Reporter: Michael Keppler >Priority: Trivial > > org.apache.maven.toolchain.java.JavaToolchainImpl has been created as > replacement for the now deprecated > org.apache.maven.toolchain.java.DefaultJavaToolChain. > However, the deprecated class was public, the new one isn't. That makes it > impossible to follow the deprecation note to use the new class (outside of > Maven core). I'm trying to fix this deprecation in Maven Tycho. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] pzygielo opened a new pull request, #923: Implement some #toString() methods (3.9.x)
pzygielo opened a new pull request, #923: URL: https://github.com/apache/maven/pull/923 - [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) - - Picked from #914 and spotless-reformatted. -- 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-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649052#comment-17649052
]
Michael Osipov commented on MNG-7578:
-
Fixed with
[a6b8a9e9fb3ca1f742883abd8cafe9eb6bf39691|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=a6b8a9e9fb3ca1f742883abd8cafe9eb6bf39691]
for {{maven-3.9.x}} branch.
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7578:
Fix Version/s: 3.9.0
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7578:
Fix Version/s: 3.8.7
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3, 3.8.7
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17649053#comment-17649053
]
Michael Osipov commented on MNG-7578:
-
Fixed with
[a020540c5f5d5b3a01b08b1014465b3999f2be76|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=a020540c5f5d5b3a01b08b1014465b3999f2be76]
for {{maven-3.8.x}} branch.
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.9.0, 4.0.0, 4.0.0-alpha-3, 3.8.7
>
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
