[jira] [Commented] (MCOMPILER-541) maven-shared-utils to 3.4.2
[ https://issues.apache.org/jira/browse/MCOMPILER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735159#comment-17735159 ] ASF GitHub Bot commented on MCOMPILER-541: -- slawekjaranowski commented on PR #195: URL: https://github.com/apache/maven-compiler-plugin/pull/195#issuecomment-1598210248 Maybe add update or bump ... to commit message and jira to be more descriptive what we do > maven-shared-utils to 3.4.2 > --- > > Key: MCOMPILER-541 > URL: https://issues.apache.org/jira/browse/MCOMPILER-541 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MSHARED-1274: - Component/s: maven-shared-utils > Deprecate the xml bits from maven-shared-utils > -- > > Key: MSHARED-1274 > URL: https://issues.apache.org/jira/browse/MSHARED-1274 > Project: Maven Shared Components > Issue Type: Task > Components: maven-shared-utils >Reporter: Guillaume Nodet >Priority: Major > > The xml bits from plexus-utils are a de-facto part of the maven 3.x api and > we should not have two conflicting versions of it. Now that it has been > extract in a separate project in plexus-xml, I think it is time to deprecate > those classes in maven-shared-utils. Fwiw, the core implementation classes > are mainly implemented with maven-xml-impl, and the Xpp3Dom class from > plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl class from > maven, however the parser is still present in plexus-xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735156#comment-17735156 ] Guillaume Nodet commented on MSHARED-1274: -- [~elharo] [~sjaranowski] thoughts on that one ? > Deprecate the xml bits from maven-shared-utils > -- > > Key: MSHARED-1274 > URL: https://issues.apache.org/jira/browse/MSHARED-1274 > Project: Maven Shared Components > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > > The xml bits from plexus-utils are a de-facto part of the maven 3.x api and > we should not have two conflicting versions of it. Now that it has been > extract in a separate project in plexus-xml, I think it is time to deprecate > those classes in maven-shared-utils. Fwiw, the core implementation classes > are mainly implemented with maven-xml-impl, and the Xpp3Dom class from > plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl class from > maven, however the parser is still present in plexus-xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1274) Deprecate the xml bits from maven-shared-utils
Guillaume Nodet created MSHARED-1274: Summary: Deprecate the xml bits from maven-shared-utils Key: MSHARED-1274 URL: https://issues.apache.org/jira/browse/MSHARED-1274 Project: Maven Shared Components Issue Type: Task Reporter: Guillaume Nodet The xml bits from plexus-utils are a de-facto part of the maven 3.x api and we should not have two conflicting versions of it. Now that it has been extract in a separate project in plexus-xml, I think it is time to deprecate those classes in maven-shared-utils. Fwiw, the core implementation classes are mainly implemented with maven-xml-impl, and the Xpp3Dom class from plexus-xml is mainly a wrapper around the new XmlNode/XmlNodeImpl class from maven, however the parser is still present in plexus-xml. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-193) No checked exceptions for rendering
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735155#comment-17735155 ] Herve Boutemy commented on MSHARED-193: --- yes, reading in memory is exactly what I'm talking about avoiding > No checked exceptions for rendering > --- > > Key: MSHARED-193 > URL: https://issues.apache.org/jira/browse/MSHARED-193 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-api, maven-reporting-impl >Affects Versions: maven-reporting-impl-2.1, maven-reporting-api-3.0 >Reporter: Benson Margulies >Priority: Major > Labels: doxia-2.0.0-stack > > It seems unfortunate that > [org.apache.maven.reporting.MavenReportRenderer.render()|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReportRenderer.html] > does not throw MavenReportingException. Thus, even though the execute method > for a report throws that exception, rendering problems cannot. > Obviously, a change to this would ramify. Would there be any chance of > acceptance for a patch that added this 'throws'? Alternatively, how about an > unchecked cousin of MavenReportingException? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] gnodet opened a new pull request, #432: 4.0.0-alpha-6 release notes
gnodet opened a new pull request, #432: URL: https://github.com/apache/maven-site/pull/432 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735152#comment-17735152
]
ASF GitHub Bot commented on MNG-7714:
-
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234788016
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -383,4 +412,15 @@ void testMng7644() {
checkVersionsEqual("2.0." + x, "2.0.0." + x); // previously
ordered, now equals
}
}
+
+@Test
+public void testMng7714() {
+String f = "1.0.final-redhat";
Review Comment:
Done.
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] CrazyHZM commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234788016
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -383,4 +412,15 @@ void testMng7644() {
checkVersionsEqual("2.0." + x, "2.0.0." + x); // previously
ordered, now equals
}
}
+
+@Test
+public void testMng7714() {
+String f = "1.0.final-redhat";
Review Comment:
Done.
--
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-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735150#comment-17735150 ] Herve Boutemy commented on MNG-7808: read in the documentation effort: "using implicit plugin version... is not managed by PluginValidationManager" can we get a Jira issue or PR for this feature, please? > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735151#comment-17735151
]
ASF GitHub Bot commented on MNG-7714:
-
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234787833
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
+checkVersionsEqualOrder("1ga", "1");
+checkVersionObjectInequality("1ga", "1");
Review Comment:
It was a special behavior before the change, but now that it's not a special
behavior, I've removed the test case.
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] CrazyHZM commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234787833
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
+checkVersionsEqualOrder("1ga", "1");
+checkVersionObjectInequality("1ga", "1");
Review Comment:
It was a special behavior before the change, but now that it's not a special
behavior, I've removed the test case.
--
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-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735149#comment-17735149
]
ASF GitHub Bot commented on MNG-7714:
-
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234786802
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -422,6 +439,106 @@ public String toString() {
}
}
+/**
+ * Represents a combination in the version item list.
+ * It is usually a combination of a string and a number, with the string
first and the number second
+ */
+private static class CombinationItem implements Item {
+
+StringItem stringValue;
Review Comment:
That's a good idea. I changed it.
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] CrazyHZM commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1234786802
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -422,6 +439,106 @@ public String toString() {
}
}
+/**
+ * Represents a combination in the version item list.
+ * It is usually a combination of a string and a number, with the string
first and the number second
+ */
+private static class CombinationItem implements Item {
+
+StringItem stringValue;
Review Comment:
That's a good idea. I changed it.
--
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-7812) Get rid of maven-shared-utils dependency
[ https://issues.apache.org/jira/browse/MNG-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7812: - Issue Type: Dependency upgrade (was: New Feature) Summary: Get rid of maven-shared-utils dependency (was: Get rid of deprecated maven-shared-utils) > Get rid of maven-shared-utils dependency > > > Key: MNG-7812 > URL: https://issues.apache.org/jira/browse/MNG-7812 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > This issue will seek to remove maven-shared-utils from the list of maven > dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7811) Plugins verification - reports are inconsistent
[
https://issues.apache.org/jira/browse/MNG-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735147#comment-17735147
]
ASF GitHub Bot commented on MNG-7811:
-
hboutemy commented on code in PR #429:
URL: https://github.com/apache/maven-site/pull/429#discussion_r1234785697
##
content/markdown/plugin-validation.md:
##
@@ -0,0 +1,73 @@
+# Plugin Validation
+
+
+
+Maven since versions 3.9.x and 4.x introduced `Plugin Validation`
+in order to help Maven users and Maven Plugin developers maintain theirs
projects.
+
+## Internal Plugins Validation issues
+
+Internal Plugins Validation issues (project local) are issues discovered in
Maven project configuration, like:
Review Comment:
"Project local issues": because there are "Project remote issues"?
= local is too relative
"Plugin Usage Validation" vs "Plugin Code Validation" (I'm not happy about
"Code": "Development"? "Internals"?)
finding good user-oriented in that documentation is a good first step: we'll
see after if renaming Maven code to match it is reasonable (because
definitively, INTERNAL/EXTERNAL is alien to me)
> Plugins verification - reports are inconsistent
> ---
>
> Key: MNG-7811
> URL: https://issues.apache.org/jira/browse/MNG-7811
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> We have report modes:
> {noformat}
> - NONE, // mute validation completely (validation issue collection still
> happens, it is just not reported!)
> - INLINE, // inline, each "internal" problem one line next to mojo invocation
> - SUMMARY, // at end, list of plugin GAVs along with "internal" issues
> - BRIEF, // synonym to SUMMARY
> - VERBOSE // at end, list of plugin GAVs along with detailed report of ANY
> validation issues
> {noformat}
> *NONE*
> - is ok works as expected, as documented
> *INLINE*
> - is ok works as expected, as documented
> *SUMMARY*, *BRIEF*
> - are the same - *{color:#ff}bug{color}*
> - prints *internal* issues in *VERBOSE* mode - *{color:#ff}bug{color}*
> *VERBOSE*
> - is ok works as expected, as documented
> So we don't have possibility to report an external issues in brief mode - as
> a list at the end, also - *{color:#ff}bug{color}*
> h1. Proposition
> - *SUMMARY* - prints *internal* and *external* issues as list at the end
> - *BRIEF* - prints *internal* issues in *INLINE* and *external* as list at
> the end
> - prepare documentation on Maven site with explanation of common issues and
> what user can do with it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7648) Generated model reader is not setting location information
[
https://issues.apache.org/jira/browse/MNG-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735148#comment-17735148
]
ASF GitHub Bot commented on MNG-7648:
-
pavelhoral commented on PR #940:
URL: https://github.com/apache/maven/pull/940#issuecomment-1598178832
> @pavelhoral Do you know if alpha 5 has this regression again? Testing
alpha 4 here
https://github.com/hazendaz/spotbugs-maven-plugin/actions/workflows/it-maven-4.0.0.yaml
and it works, the prior runs for same job used alpha 5 and seems broken again.
Just wonder if you are seeing same behaviour.
It shouldn't be the same bug as that would have been caught by the unit
tests (I hope).
Interesting thing is that the enforcer rule fails only on Java 17 and not
Java 11:
Java 11 run
```console
/tmp/spotbugs-maven-plugin$ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/
/srv/repo/maven/apache-maven-4.0.0-alpha-5/bin/mvn -B -V clean install
-Dlicense.skip=true -Dmaven.min-version=4.0.0-alpha-5 --no-transfer-progress
Apache Maven 4.0.0-alpha-5 (26d10a4bf9a2df75feef60da01d8706f2bf77a47)
Maven home: /srv/repo/maven/apache-maven-4.0.0-alpha-5
Java version: 11.0.19, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[INFO]
[INFO] --<
com.github.spotbugs:spotbugs-maven-plugin
>---
[INFO] Building spotbugs-maven-plugin 4.7.3.6-SNAPSHOT
[INFO] from pom.xml
[INFO] -[ maven-plugin
]-
[INFO]
[INFO] -
> Generated model reader is not setting location information
> --
>
> Key: MNG-7648
> URL: https://issues.apache.org/jira/browse/MNG-7648
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 4.0.0-alpha-3
>Reporter: Pavel Horal
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.8, 3.9.0, 4.0.0-alpha-4, 4.0.0
>
>
> -Generated model reader is not setting {{location}} property -
> [https://github.com/apache/maven/blob/e73a0b00fde80c400a6d854ec0c2ba7436325eed/maven-toolchain-model/src/main/mdo/reader.vm#L683]
> .-
> Project model does not have location property in plugin execution (potential
> issue when merging model parent configuration?). This causes issues for
> example in Maven Enforcer Plugin which uses this information (see
> [MENFORCER-447|https://issues.apache.org/jira/browse/MENFORCER-447?focusedCommentId=17651671&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17651671]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] pavelhoral commented on pull request #940: [MNG-7648] Fix locationTracking in DefaultModelBuildingRequest copy constructor.
pavelhoral commented on PR #940: URL: https://github.com/apache/maven/pull/940#issuecomment-1598178832 > @pavelhoral Do you know if alpha 5 has this regression again? Testing alpha 4 here https://github.com/hazendaz/spotbugs-maven-plugin/actions/workflows/it-maven-4.0.0.yaml and it works, the prior runs for same job used alpha 5 and seems broken again. Just wonder if you are seeing same behaviour. It shouldn't be the same bug as that would have been caught by the unit tests (I hope). Interesting thing is that the enforcer rule fails only on Java 17 and not Java 11: Java 11 run ```console /tmp/spotbugs-maven-plugin$ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ /srv/repo/maven/apache-maven-4.0.0-alpha-5/bin/mvn -B -V clean install -Dlicense.skip=true -Dmaven.min-version=4.0.0-alpha-5 --no-transfer-progress Apache Maven 4.0.0-alpha-5 (26d10a4bf9a2df75feef60da01d8706f2bf77a47) Maven home: /srv/repo/maven/apache-maven-4.0.0-alpha-5 Java version: 11.0.19, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix" [INFO] Scanning for projects... [INFO] [INFO] --< com.github.spotbugs:spotbugs-maven-plugin >--- [INFO] Building spotbugs-maven-plugin 4.7.3.6-SNAPSHOT [INFO] from pom.xml [INFO] -[ maven-plugin ]- [INFO] [INFO] --- enforcer:3.3.0:enforce (enforce-clean) @ spotbugs-maven-plugin --- [INFO] Rule 0: org.apache.maven.enforcer.rules.dependency.BannedDependencies passed [INFO] Rule 1: org.apache.maven.enforcer.rules.BanDuplicatePomDependencyVersions passed [INFO] Adding ignore: module-info [INFO] Rule 2: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion passed [INFO] Rule 3: org.apache.maven.enforcer.rules.ReactorModuleConvergence passed [INFO] Rule 4: org.apache.maven.enforcer.rules.version.RequireJavaVersion passed [INFO] Rule 5: org.apache.maven.enforcer.rules.version.RequireMavenVersion passed [INFO] Rule 6: org.apache.maven.enforcer.rules.RequirePluginVersions passed [INFO] Rule 7: org.apache.maven.plugins.enforcer.RestrictImports passed [INFO] [INFO] --- clean:3.2.0:clean (default-clean) @ spotbugs-maven-plugin --- [INFO] Deleting /tmp/spotbugs-maven-plugin/target (includes = [**/*], excludes = []) [INFO] ... ``` Java 17 run ```console /tmp/spotbugs-maven-plugin$ $ JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64/ /srv/repo/maven/apache-maven-4.0.0-alpha-5/bin/mvn -B -V clean install -Dlicense.skip=true -Dmaven.min-version=4.0.0-alpha-5 --no-transfer-progress Apache Maven 4.0.0-alpha-5 (26d10a4bf9a2df75feef60da01d8706f2bf77a47) Maven home: /srv/repo/maven/apache-maven-4.0.0-alpha-5 Java version: 17.0.7, vendor: Private Build, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix" [INFO] Scanning for projects... [INFO] [INFO] --< com.github.spotbugs:spotbugs-maven-plugin >--- [INFO] Building spotbugs-maven-plugin 4.7.3.6-SNAPSHOT [INFO] from pom.xml [INFO] -[ maven-plugin ]- [INFO] [INFO] --- enforcer:3.3.0:enforce (enforce-clean) @ spotbugs-maven-plugin --- [INFO] Rule 0: org.apache.maven.enforcer.rules.dependency.BannedDependencies passed [INFO] Rule 1: org.apache.maven.enforcer.rules.BanDuplicatePomDependencyVersions passed [INFO] Adding ignore: module-info [INFO] Rule 2: org.codehaus.mojo.extraenforcer.dependencies.EnforceBytecodeVersion passed [INFO] Rule 3: org.apache.maven.enforcer.rules.ReactorModuleConvergence passed [INFO] Rule 4: org.apache.maven.enforcer.rules.version.RequireJavaVersion passed [INFO] Rule 5: org.apache.maven.enforcer.rules.version.RequireMavenVersion passed [INFO] Rule 7: org.apache.maven.plugins.enforcer.RestrictImports passed [INFO] -- [INFO] BUILD FAILURE [INFO] -- [INFO] Total time: 1.262 s [INFO] Finished at: 2023-06-20T08:09:42+02:00 [INFO] -- [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.3.0:enforce (enforce-clean) on
[GitHub] [maven-site] hboutemy commented on a diff in pull request #429: [MNG-7811] Documentation for Plugin Validation
hboutemy commented on code in PR #429: URL: https://github.com/apache/maven-site/pull/429#discussion_r1234785697 ## content/markdown/plugin-validation.md: ## @@ -0,0 +1,73 @@ +# Plugin Validation + + + +Maven since versions 3.9.x and 4.x introduced `Plugin Validation` +in order to help Maven users and Maven Plugin developers maintain theirs projects. + +## Internal Plugins Validation issues + +Internal Plugins Validation issues (project local) are issues discovered in Maven project configuration, like: Review Comment: "Project local issues": because there are "Project remote issues"? = local is too relative "Plugin Usage Validation" vs "Plugin Code Validation" (I'm not happy about "Code": "Development"? "Internals"?) finding good user-oriented in that documentation is a good first step: we'll see after if renaming Maven code to match it is reasonable (because definitively, INTERNAL/EXTERNAL is alien to me) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7756) The degree of concurrency does not support "2." as a factor
[
https://issues.apache.org/jira/browse/MNG-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7756:
-
Fix Version/s: (was: 3.8.x-candidate)
(was: 3.9.x-candidate)
Issue Type: Bug (was: Improvement)
> The degree of concurrency does not support "2." as a factor
> ---
>
> Key: MNG-7756
> URL: https://issues.apache.org/jira/browse/MNG-7756
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-6, 4.0.0
>
>
> The {{2.}} syntax is supported by {{Float.parseFloat()}} and there's no
> reason why that particular syntax should be rejected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7800) Upgrade to Maven Resolver 1.9.12
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7800: - Summary: Upgrade to Maven Resolver 1.9.12 (was: Upgrade to resolver 1.9.12) > Upgrade to Maven Resolver 1.9.12 > > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.12 with latest fixed. > Was: > Ingest resolver 1.9.11 with latest fixes (but MRESOLVER-371) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7820) Remove dependency on plexus-utils
Guillaume Nodet created MNG-7820: Summary: Remove dependency on plexus-utils Key: MNG-7820 URL: https://issues.apache.org/jira/browse/MNG-7820 Project: Maven Issue Type: Task Reporter: Guillaume Nodet Fix For: 4.0.0-alpha-7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7811) Plugins verification - reports are inconsistent
[
https://issues.apache.org/jira/browse/MNG-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735143#comment-17735143
]
ASF GitHub Bot commented on MNG-7811:
-
hboutemy commented on code in PR #429:
URL: https://github.com/apache/maven-site/pull/429#discussion_r1234781733
##
content/markdown/plugin-validation.md:
##
@@ -0,0 +1,73 @@
+# Plugin Validation
+
+
+
+Maven since versions 3.9.x and 4.x introduced `Plugin Validation`
+in order to help Maven users and Maven Plugin developers maintain theirs
projects.
+
+## Internal Plugins Validation issues
+
+Internal Plugins Validation issues (project local) are issues discovered in
Maven project configuration, like:
+
+ - using deprecated plugins goals
+ - using deprecated plugins parameters
+ - using read only plugins parameters
+
+In such cases users can fix their project by fixing configuration by editing
their POMs.
+Users should consult actual plugin documentation or try to update plugin to
newer version.
+
+## External Plugins Validation issues
+
+`External Plugins Validation issues (non-configuration) are issues detected in
plugin itself, like:
+
+ - using old, deprecated Maven Api by plugin
+ - declaring dependencies for Maven Core artifacts in wrong scope in plugin
project
Review Comment:
can we get a list of associated Jira issues, or PRs, please?
> Plugins verification - reports are inconsistent
> ---
>
> Key: MNG-7811
> URL: https://issues.apache.org/jira/browse/MNG-7811
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> We have report modes:
> {noformat}
> - NONE, // mute validation completely (validation issue collection still
> happens, it is just not reported!)
> - INLINE, // inline, each "internal" problem one line next to mojo invocation
> - SUMMARY, // at end, list of plugin GAVs along with "internal" issues
> - BRIEF, // synonym to SUMMARY
> - VERBOSE // at end, list of plugin GAVs along with detailed report of ANY
> validation issues
> {noformat}
> *NONE*
> - is ok works as expected, as documented
> *INLINE*
> - is ok works as expected, as documented
> *SUMMARY*, *BRIEF*
> - are the same - *{color:#ff}bug{color}*
> - prints *internal* issues in *VERBOSE* mode - *{color:#ff}bug{color}*
> *VERBOSE*
> - is ok works as expected, as documented
> So we don't have possibility to report an external issues in brief mode - as
> a list at the end, also - *{color:#ff}bug{color}*
> h1. Proposition
> - *SUMMARY* - prints *internal* and *external* issues as list at the end
> - *BRIEF* - prints *internal* issues in *INLINE* and *external* as list at
> the end
> - prepare documentation on Maven site with explanation of common issues and
> what user can do with it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7821) Require JDK 11 at build time and get rid of animal-sniffer
Guillaume Nodet created MNG-7821: Summary: Require JDK 11 at build time and get rid of animal-sniffer Key: MNG-7821 URL: https://issues.apache.org/jira/browse/MNG-7821 Project: Maven Issue Type: Task Reporter: Guillaume Nodet Fix For: 4.0.0-alpha-7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7811) Plugins verification - reports are inconsistent
[
https://issues.apache.org/jira/browse/MNG-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735142#comment-17735142
]
ASF GitHub Bot commented on MNG-7811:
-
hboutemy commented on code in PR #429:
URL: https://github.com/apache/maven-site/pull/429#discussion_r1234781093
##
content/markdown/plugin-validation.md:
##
@@ -0,0 +1,73 @@
+# Plugin Validation
+
+
+
+Maven since versions 3.9.x and 4.x introduced `Plugin Validation`
+in order to help Maven users and Maven Plugin developers maintain theirs
projects.
+
+## Internal Plugins Validation issues
+
+Internal Plugins Validation issues (project local) are issues discovered in
Maven project configuration, like:
+
+ - using deprecated plugins goals
+ - using deprecated plugins parameters
+ - using read only plugins parameters
+
+In such cases users can fix their project by fixing configuration by editing
their POMs.
+Users should consult actual plugin documentation or try to update plugin to
newer version.
+
+## External Plugins Validation issues
+
+`External Plugins Validation issues (non-configuration) are issues detected in
plugin itself, like:
+
+ - using old, deprecated Maven Api by plugin
+ - declaring dependencies for Maven Core artifacts in wrong scope in plugin
project
+
+External Plugins issues can only be fix by plugin authors.
+
+In such cases users can try to update plugin to newer version.
+If the newest version of plugin still has an issue users should report problem
to plugin authors.
+
+## Manage Plugin Validation verbosity
+
+In order to manage Plugin Validation verbosity a property
`maven.plugin.validation` can be used.
+
+Allowed values are:
+
+ - `NONE` - mute Plugin Validation completely, nothing will be reported
+ - `INLINE` - report only `Internal` issues in place where occur
+ - `BRIEF` - report only `Internal` issues in place where occur and list of
plugins with `External` issues at the and of build
+ - `SUMMARY` - report list of plugins with `Internal` and `External` issues at
the end of build
+ - `VERBOSE` - report `Internal` and `External` issues at the end of build in
verbose mode
+
+Configuration values for `maven.plugin.validation` are case insensitive, can
be used on command line, like:
+
+```
+mvn -Dmaven.plugin.validation=verbose ...
+```
+
+Can be added to `MAVEN_OPTS` or `MAVEN_ARGS` environment variables,
+can also be added to `.mvn/maven.config` file in order to configure per
project.
Review Comment:
perhaps a not on this will be useful, because I suppose I won't be the only
one to think at pom.xml properties
> Plugins verification - reports are inconsistent
> ---
>
> Key: MNG-7811
> URL: https://issues.apache.org/jira/browse/MNG-7811
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> We have report modes:
> {noformat}
> - NONE, // mute validation completely (validation issue collection still
> happens, it is just not reported!)
> - INLINE, // inline, each "internal" problem one line next to mojo invocation
> - SUMMARY, // at end, list of plugin GAVs along with "internal" issues
> - BRIEF, // synonym to SUMMARY
> - VERBOSE // at end, list of plugin GAVs along with detailed report of ANY
> validation issues
> {noformat}
> *NONE*
> - is ok works as expected, as documented
> *INLINE*
> - is ok works as expected, as documented
> *SUMMARY*, *BRIEF*
> - are the same - *{color:#ff}bug{color}*
> - prints *internal* issues in *VERBOSE* mode - *{color:#ff}bug{color}*
> *VERBOSE*
> - is ok works as expected, as documented
> So we don't have possibility to report an external issues in brief mode - as
> a list at the end, also - *{color:#ff}bug{color}*
> h1. Proposition
> - *SUMMARY* - prints *internal* and *external* issues as list at the end
> - *BRIEF* - prints *internal* issues in *INLINE* and *external* as list at
> the end
> - prepare documentation on Maven site with explanation of common issues and
> what user can do with it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] hboutemy commented on a diff in pull request #429: [MNG-7811] Documentation for Plugin Validation
hboutemy commented on code in PR #429: URL: https://github.com/apache/maven-site/pull/429#discussion_r1234781733 ## content/markdown/plugin-validation.md: ## @@ -0,0 +1,73 @@ +# Plugin Validation + + + +Maven since versions 3.9.x and 4.x introduced `Plugin Validation` +in order to help Maven users and Maven Plugin developers maintain theirs projects. + +## Internal Plugins Validation issues + +Internal Plugins Validation issues (project local) are issues discovered in Maven project configuration, like: + + - using deprecated plugins goals + - using deprecated plugins parameters + - using read only plugins parameters + +In such cases users can fix their project by fixing configuration by editing their POMs. +Users should consult actual plugin documentation or try to update plugin to newer version. + +## External Plugins Validation issues + +`External Plugins Validation issues (non-configuration) are issues detected in plugin itself, like: + + - using old, deprecated Maven Api by plugin + - declaring dependencies for Maven Core artifacts in wrong scope in plugin project Review Comment: can we get a list of associated Jira issues, or PRs, 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
[GitHub] [maven-site] hboutemy commented on a diff in pull request #429: [MNG-7811] Documentation for Plugin Validation
hboutemy commented on code in PR #429: URL: https://github.com/apache/maven-site/pull/429#discussion_r1234781093 ## content/markdown/plugin-validation.md: ## @@ -0,0 +1,73 @@ +# Plugin Validation + + + +Maven since versions 3.9.x and 4.x introduced `Plugin Validation` +in order to help Maven users and Maven Plugin developers maintain theirs projects. + +## Internal Plugins Validation issues + +Internal Plugins Validation issues (project local) are issues discovered in Maven project configuration, like: + + - using deprecated plugins goals + - using deprecated plugins parameters + - using read only plugins parameters + +In such cases users can fix their project by fixing configuration by editing their POMs. +Users should consult actual plugin documentation or try to update plugin to newer version. + +## External Plugins Validation issues + +`External Plugins Validation issues (non-configuration) are issues detected in plugin itself, like: + + - using old, deprecated Maven Api by plugin + - declaring dependencies for Maven Core artifacts in wrong scope in plugin project + +External Plugins issues can only be fix by plugin authors. + +In such cases users can try to update plugin to newer version. +If the newest version of plugin still has an issue users should report problem to plugin authors. + +## Manage Plugin Validation verbosity + +In order to manage Plugin Validation verbosity a property `maven.plugin.validation` can be used. + +Allowed values are: + + - `NONE` - mute Plugin Validation completely, nothing will be reported + - `INLINE` - report only `Internal` issues in place where occur + - `BRIEF` - report only `Internal` issues in place where occur and list of plugins with `External` issues at the and of build + - `SUMMARY` - report list of plugins with `Internal` and `External` issues at the end of build + - `VERBOSE` - report `Internal` and `External` issues at the end of build in verbose mode + +Configuration values for `maven.plugin.validation` are case insensitive, can be used on command line, like: + +``` +mvn -Dmaven.plugin.validation=verbose ... +``` + +Can be added to `MAVEN_OPTS` or `MAVEN_ARGS` environment variables, +can also be added to `.mvn/maven.config` file in order to configure per project. Review Comment: perhaps a not on this will be useful, because I suppose I won't be the only one to think at pom.xml properties -- 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-7811) Plugins verification - reports are inconsistent
[
https://issues.apache.org/jira/browse/MNG-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735141#comment-17735141
]
ASF GitHub Bot commented on MNG-7811:
-
hboutemy commented on code in PR #429:
URL: https://github.com/apache/maven-site/pull/429#discussion_r1234779438
##
content/markdown/plugin-validation.md:
##
@@ -0,0 +1,73 @@
+# Plugin Validation
+
+
+
+Maven since versions 3.9.x and 4.x introduced `Plugin Validation`
+in order to help Maven users and Maven Plugin developers maintain theirs
projects.
+
+## Internal Plugins Validation issues
Review Comment:
I think this would really improve users understanding, because currently
they don't get the meaning and concretely what to do
> Plugins verification - reports are inconsistent
> ---
>
> Key: MNG-7811
> URL: https://issues.apache.org/jira/browse/MNG-7811
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> We have report modes:
> {noformat}
> - NONE, // mute validation completely (validation issue collection still
> happens, it is just not reported!)
> - INLINE, // inline, each "internal" problem one line next to mojo invocation
> - SUMMARY, // at end, list of plugin GAVs along with "internal" issues
> - BRIEF, // synonym to SUMMARY
> - VERBOSE // at end, list of plugin GAVs along with detailed report of ANY
> validation issues
> {noformat}
> *NONE*
> - is ok works as expected, as documented
> *INLINE*
> - is ok works as expected, as documented
> *SUMMARY*, *BRIEF*
> - are the same - *{color:#ff}bug{color}*
> - prints *internal* issues in *VERBOSE* mode - *{color:#ff}bug{color}*
> *VERBOSE*
> - is ok works as expected, as documented
> So we don't have possibility to report an external issues in brief mode - as
> a list at the end, also - *{color:#ff}bug{color}*
> h1. Proposition
> - *SUMMARY* - prints *internal* and *external* issues as list at the end
> - *BRIEF* - prints *internal* issues in *INLINE* and *external* as list at
> the end
> - prepare documentation on Maven site with explanation of common issues and
> what user can do with it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] hboutemy commented on a diff in pull request #429: [MNG-7811] Documentation for Plugin Validation
hboutemy commented on code in PR #429: URL: https://github.com/apache/maven-site/pull/429#discussion_r1234779438 ## content/markdown/plugin-validation.md: ## @@ -0,0 +1,73 @@ +# Plugin Validation + + + +Maven since versions 3.9.x and 4.x introduced `Plugin Validation` +in order to help Maven users and Maven Plugin developers maintain theirs projects. + +## Internal Plugins Validation issues Review Comment: I think this would really improve users understanding, because currently they don't get the meaning and concretely what to do -- 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-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7714:
-
Fix Version/s: 4.0.0-alpha-7
(was: 4.0.0-alpha-6)
> sp < final
> --
>
> Key: MNG-7714
> URL: https://issues.apache.org/jira/browse/MNG-7714
> Project: Maven
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 4.0.0-alpha-7
>
>
> Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701
> The claim is that sp < final, which if true is incorrect according to spec.
> It is easy to demonstrate that this is not fixed and also not in line with
> the spec, with just this one important example (yes this does break for us):
> $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 < 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat,
> [1
> versus
> $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001
> 1.0.sp1-redhat-0001
> Display parameters as parsed by Maven (in canonical form and as a list of
> tokens) and comparison result:
> 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]]
>1.0.final-redhat-0001 > 1.0.sp1-redhat-0001
> 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat,
> [1]
> As you can see, our `sp` release is now ordered after our `final` release
> despite this clear text in the "spec":
> Non-numeric tokens ("qualifiers") have the alphabetical order, except for
> the following tokens which come first in this order: "alpha" < "beta" <
> "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp"
> It's clear that this tokenization isn't really correct by any reasonable
> measurement, and breaking large amounts of (our) existing artifacts in the
> wild is definitely not OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7814) Use location tracking for settings
[ https://issues.apache.org/jira/browse/MNG-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7814. Resolution: Fixed > Use location tracking for settings > -- > > Key: MNG-7814 > URL: https://issues.apache.org/jira/browse/MNG-7814 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > We do have all the code needed to track settings location in a similar way > than we do for the model. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7648) Generated model reader is not setting location information
[
https://issues.apache.org/jira/browse/MNG-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735139#comment-17735139
]
ASF GitHub Bot commented on MNG-7648:
-
gnodet commented on PR #940:
URL: https://github.com/apache/maven/pull/940#issuecomment-1598165246
@pavelhoral I'm planning a release of 4.0.0-alpha-6 in the coming days, so a
quick check with the latest master branch would be welcomed !
> Generated model reader is not setting location information
> --
>
> Key: MNG-7648
> URL: https://issues.apache.org/jira/browse/MNG-7648
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 4.0.0-alpha-3
>Reporter: Pavel Horal
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.8, 3.9.0, 4.0.0-alpha-4, 4.0.0
>
>
> -Generated model reader is not setting {{location}} property -
> [https://github.com/apache/maven/blob/e73a0b00fde80c400a6d854ec0c2ba7436325eed/maven-toolchain-model/src/main/mdo/reader.vm#L683]
> .-
> Project model does not have location property in plugin execution (potential
> issue when merging model parent configuration?). This causes issues for
> example in Maven Enforcer Plugin which uses this information (see
> [MENFORCER-447|https://issues.apache.org/jira/browse/MENFORCER-447?focusedCommentId=17651671&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17651671]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #940: [MNG-7648] Fix locationTracking in DefaultModelBuildingRequest copy constructor.
gnodet commented on PR #940: URL: https://github.com/apache/maven/pull/940#issuecomment-1598165246 @pavelhoral I'm planning a release of 4.0.0-alpha-6 in the coming days, so a quick check with the latest master branch would be welcomed ! -- 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-7648) Generated model reader is not setting location information
[
https://issues.apache.org/jira/browse/MNG-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734577#comment-17734577
]
ASF GitHub Bot commented on MNG-7648:
-
hazendaz commented on PR #940:
URL: https://github.com/apache/maven/pull/940#issuecomment-1597870102
@pavelhoral Do you know if alpha 5 has this regression again? Testing alpha
4 here
https://github.com/hazendaz/spotbugs-maven-plugin/actions/workflows/it-maven-4.0.0.yaml
and it works, the prior runs for same job used alpha 5 and seems broken again.
Just wonder if you are seeing same behaviour.
> Generated model reader is not setting location information
> --
>
> Key: MNG-7648
> URL: https://issues.apache.org/jira/browse/MNG-7648
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 4.0.0-alpha-3
>Reporter: Pavel Horal
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.8.8, 3.9.0, 4.0.0-alpha-4, 4.0.0
>
>
> -Generated model reader is not setting {{location}} property -
> [https://github.com/apache/maven/blob/e73a0b00fde80c400a6d854ec0c2ba7436325eed/maven-toolchain-model/src/main/mdo/reader.vm#L683]
> .-
> Project model does not have location property in plugin execution (potential
> issue when merging model parent configuration?). This causes issues for
> example in Maven Enforcer Plugin which uses this information (see
> [MENFORCER-447|https://issues.apache.org/jira/browse/MENFORCER-447?focusedCommentId=17651671&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17651671]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hazendaz commented on pull request #940: [MNG-7648] Fix locationTracking in DefaultModelBuildingRequest copy constructor.
hazendaz commented on PR #940: URL: https://github.com/apache/maven/pull/940#issuecomment-1597870102 @pavelhoral Do you know if alpha 5 has this regression again? Testing alpha 4 here https://github.com/hazendaz/spotbugs-maven-plugin/actions/workflows/it-maven-4.0.0.yaml and it works, the prior runs for same job used alpha 5 and seems broken again. Just wonder if you are seeing same behaviour. -- 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-compiler-plugin] elharo commented on pull request #194: Remove references to old Maven versions.
elharo commented on PR #194: URL: https://github.com/apache/maven-compiler-plugin/pull/194#issuecomment-1597779902 What we support and what we spend time calling out in documentation are two different things. Maven 2 is definitely dead. -- 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-compiler-plugin] slachiewicz commented on pull request #194: Remove references to old Maven versions.
slachiewicz commented on PR #194: URL: https://github.com/apache/maven-compiler-plugin/pull/194#issuecomment-1597775677 I hope You remember discussion on ML about minimum supported Maven version in all our plugins - so far 3.2.5 is minimal for users https://maven.apache.org/docs/history.html#maven-3-6-x-and-before and You strongly voted against setting it to 3.5.4 -- 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] hboutemy merged pull request #1175: update logging documentation
hboutemy merged PR #1175: URL: https://github.com/apache/maven/pull/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-integration-testing] cstamas opened a new pull request, #271: [MNG-7819] Add IT that excercise the bug
cstamas opened a new pull request, #271: URL: https://github.com/apache/maven-integration-testing/pull/271 Template/reproducer: https://gist.github.com/cstamas/3f15775bd4785a5f4b157399f52af6fc While local repo is empty. --- https://issues.apache.org/jira/browse/MNG-7819 -- 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] (MCOMPILER-541) maven-shared-utils to 3.4.2
[ https://issues.apache.org/jira/browse/MCOMPILER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734472#comment-17734472 ] ASF GitHub Bot commented on MCOMPILER-541: -- elharo opened a new pull request, #195: URL: https://github.com/apache/maven-compiler-plugin/pull/195 (no comment) > maven-shared-utils to 3.4.2 > --- > > Key: MCOMPILER-541 > URL: https://issues.apache.org/jira/browse/MCOMPILER-541 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-541) maven-shared-utils to 3.4.2
Elliotte Rusty Harold created MCOMPILER-541: --- Summary: maven-shared-utils to 3.4.2 Key: MCOMPILER-541 URL: https://issues.apache.org/jira/browse/MCOMPILER-541 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-541) maven-shared-utils to 3.4.2
[ https://issues.apache.org/jira/browse/MCOMPILER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MCOMPILER-541: --- Assignee: Elliotte Rusty Harold > maven-shared-utils to 3.4.2 > --- > > Key: MCOMPILER-541 > URL: https://issues.apache.org/jira/browse/MCOMPILER-541 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-compiler-plugin] elharo opened a new pull request, #194: Remove references to old Maven versions.
elharo opened a new pull request, #194: URL: https://github.com/apache/maven-compiler-plugin/pull/194 In 2023 assume everyone is on 3.3.1 or later. -- 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-7819) Create IT that exercise file locking with snaphots
[ https://issues.apache.org/jira/browse/MNG-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7819: - Description: Reproducer for 3.9,2 bug: https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 > Create IT that exercise file locking with snaphots > -- > > Key: MNG-7819 > URL: https://issues.apache.org/jira/browse/MNG-7819 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Tamas Cservenak >Priority: Major > > Reproducer for 3.9,2 bug: > https://gist.github.com/cstamas/0f1909c81d975f513ceb88012d7c0529 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7819) Create IT that exercise file locking with snaphots
Tamas Cservenak created MNG-7819: Summary: Create IT that exercise file locking with snaphots Key: MNG-7819 URL: https://issues.apache.org/jira/browse/MNG-7819 Project: Maven Issue Type: Task Components: Integration Tests Reporter: Tamas Cservenak -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] elharo opened a new pull request, #327: Tighten language
elharo opened a new pull request, #327: URL: https://github.com/apache/maven-dependency-plugin/pull/327 Trivial change with no effect on build so I can see if the CI is broken at head or not -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734354#comment-17734354
]
Michael Osipov commented on MRESOLVER-372:
--
See also MRESOLVER-325 for explanation.
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] lprimak opened a new pull request, #1178: Fixes https://issues.apache.org/jira/browse/MNG-7818
lprimak opened a new pull request, #1178: URL: https://github.com/apache/maven/pull/1178 Removed exclusion of hamcrest from JUnit 4 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. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both 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-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734322#comment-17734322
]
ASF GitHub Bot commented on MNG-7818:
-
lprimak opened a new pull request, #1178:
URL: https://github.com/apache/maven/pull/1178
Removed exclusion of hamcrest from JUnit 4
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.
- [ ] Also format the first line of the commit message like `[MNG-XXX]
SUMMARY`.
Best practice is to use the JIRA issue title in both 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/
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
> JUnit 4 works just fine as well, making the exclusion, again, unnecessary
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRu
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734311#comment-17734311
]
ASF GitHub Bot commented on MSHARED-1248:
-
garydgregory commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1234261257
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
Review Comment:
@elharo
I updated the call.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
> at org.apache.maven.c
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734308#comment-17734308
]
ASF GitHub Bot commented on MSHARED-1248:
-
garydgregory commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1234261733
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
@elharo
I updated the message. I do not see where to get a path since we are
starting from an InputStream.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.m
[GitHub] [maven-dependency-analyzer] garydgregory commented on a diff in pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
garydgregory commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1234261733
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
@elharo
I updated the message. I do not see where to get a path since we are
starting from an InputStream.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734306#comment-17734306
]
ASF GitHub Bot commented on MSHARED-1248:
-
garydgregory commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1234261257
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
Review Comment:
@elharo
I update the call.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
> at org.apache.maven.cl
[jira] [Assigned] (MRESOLVER-373) Partially undo MRESOLVER-346
[ https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-373: - Assignee: Tamas Cservenak > Partially undo MRESOLVER-346 > > > Key: MRESOLVER-373 > URL: https://issues.apache.org/jira/browse/MRESOLVER-373 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Blocker > Fix For: 1.9.13 > > > The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and > DefaultMetadataResolver is wrong, and is actually complemented by > MRESOLVER-349, so is really not needed. The change happened for > DefaultDeployer is correct. > In short, DefaultArtifactResolver within syncContext will invoke > DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT > supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 > this went unnoticed. > Just undo the change and make two component as before, always use exclusive > locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-220:
-
Assignee: Tamas Cservenak
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
> In short: code attempting unsupported "lock upgrade" should fail fast and
> with a clear reason ("illegal op"). Fail fast will happen with a runtime
> exception thrown and bubbling up all to the caller to make it clear, that
> there is some problem with code, that cannot be fixed without code change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-220:
--
Component/s: Resolver
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
> In short: code attempting unsupported "lock upgrade" should fail fast and
> with a clear reason ("illegal op"). Fail fast will happen with a runtime
> exception thrown and bubbling up all to the caller to make it clear, that
> there is some problem with code, that cannot be fixed without code change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-220:
--
Description:
Lock upgrading is not supported, it is the caller that must be aware of this.
Currently the code for all implementations returns {{false}} in case of lock
upgrade attempted, same way as locking failed. IMHO, we should change this to
some exception maybe?
In short: code attempting unsupported "lock upgrade" should fail fast and with
a clear reason ("illegal op"). Fail fast will happen with a runtime exception
thrown and bubbling up all to the caller to make it clear, that there is some
problem with code, that cannot be fixed without code change.
was:
Lock upgrading is not supported, it is the caller that must be aware of this.
Currently the code for all implementations returns {{false}} in case of lock
upgrade attempted, same way as locking failed. IMHO, we should change this to
some exception maybe?
In short: code attempting unsupported "lock upgrade" should fail fast and with
a clear reason ("illegal op").
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
> In short: code attempting unsupported "lock upgrade" should fail fast and
> with a clear reason ("illegal op"). Fail fast will happen with a runtime
> exception thrown and bubbling up all to the caller to make it clear, that
> there is some problem with code, that cannot be fixed without code change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-220:
--
Description:
Lock upgrading is not supported, it is the caller that must be aware of this.
Currently the code for all implementations returns {{false}} in case of lock
upgrade attempted, same way as locking failed. IMHO, we should change this to
some exception maybe?
In short: code attempting unsupported "lock upgrade" should fail fast and with
a clear reason ("illegal op").
was:
Lock upgrading is not supported, it is the caller that must be aware of this.
Currently the code for all implementations returns {{false}} in case of lock
upgrade attempted, same way as locking failed. IMHO, we should change this to
some exception maybe?
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
> In short: code attempting unsupported "lock upgrade" should fail fast and
> with a clear reason ("illegal op").
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-220:
--
Issue Type: Improvement (was: Task)
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-373) Partially undo MRESOLVER-346
[ https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-373: -- Issue Type: Bug (was: Task) > Partially undo MRESOLVER-346 > > > Key: MRESOLVER-373 > URL: https://issues.apache.org/jira/browse/MRESOLVER-373 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.13 > > > The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and > DefaultMetadataResolver is wrong, and is actually complemented by > MRESOLVER-349, so is really not needed. The change happened for > DefaultDeployer is correct. > In short, DefaultArtifactResolver within syncContext will invoke > DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT > supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 > this went unnoticed. > Just undo the change and make two component as before, always use exclusive > locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-373) Partially undo MRESOLVER-346
[ https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-373: -- Priority: Blocker (was: Major) > Partially undo MRESOLVER-346 > > > Key: MRESOLVER-373 > URL: https://issues.apache.org/jira/browse/MRESOLVER-373 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Blocker > Fix For: 1.9.13 > > > The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and > DefaultMetadataResolver is wrong, and is actually complemented by > MRESOLVER-349, so is really not needed. The change happened for > DefaultDeployer is correct. > In short, DefaultArtifactResolver within syncContext will invoke > DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT > supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 > this went unnoticed. > Just undo the change and make two component as before, always use exclusive > locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-373) Partially undo MRESOLVER-346
[ https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734260#comment-17734260 ] ASF GitHub Bot commented on MRESOLVER-373: -- cstamas opened a new pull request, #302: URL: https://github.com/apache/maven-resolver/pull/302 In change 4c5e9ea98f8815c6df8bf26baa9032c8d9cd5f2d we introduced code that in some case tries illegal "lock upgrade", that due lack of MRESOLVER-220 went unnoticed. This change merely undoes the changes for DefaultArtifactResolver and DefaultMetadataResolver (will as before, use exclusive SyncContext immediately, not be "optimistic"), while change for DefaultDeploy is still correct. --- https://issues.apache.org/jira/browse/MRESOLVER-373 > Partially undo MRESOLVER-346 > > > Key: MRESOLVER-373 > URL: https://issues.apache.org/jira/browse/MRESOLVER-373 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.13 > > > The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and > DefaultMetadataResolver is wrong, and is actually complemented by > MRESOLVER-349, so is really not needed. The change happened for > DefaultDeployer is correct. > In short, DefaultArtifactResolver within syncContext will invoke > DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT > supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 > this went unnoticed. > Just undo the change and make two component as before, always use exclusive > locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-373) Partially undo MRESOLVER-346
[ https://issues.apache.org/jira/browse/MRESOLVER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-373: -- Description: The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and DefaultMetadataResolver is wrong, and is actually complemented by MRESOLVER-349, so is really not needed. The change happened for DefaultDeployer is correct. In short, DefaultArtifactResolver within syncContext will invoke DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 this went unnoticed. Just undo the change and make two component as before, always use exclusive locks. was: The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and DefaultMetadataResolver is wrong, and is actually complemented by MRESOLVER-349, so is really not needed. The change happened for DefaultDeployer is correct. In short, DefaultArtifactResolver within syncContext will invoke DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT supported by named locks -> failure. Just undo the change and make two component as before, always use exclusive locks. > Partially undo MRESOLVER-346 > > > Key: MRESOLVER-373 > URL: https://issues.apache.org/jira/browse/MRESOLVER-373 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.13 > > > The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and > DefaultMetadataResolver is wrong, and is actually complemented by > MRESOLVER-349, so is really not needed. The change happened for > DefaultDeployer is correct. > In short, DefaultArtifactResolver within syncContext will invoke > DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT > supported by named locks -> failure. Sadly, due push back on MRESOLVER-220 > this went unnoticed. > Just undo the change and make two component as before, always use exclusive > locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-373) Partially undo MRESOLVER-346
Tamas Cservenak created MRESOLVER-373: - Summary: Partially undo MRESOLVER-346 Key: MRESOLVER-373 URL: https://issues.apache.org/jira/browse/MRESOLVER-373 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.13 The change done in MRESOLVER-346 in relation to DefaultArtifactResolver and DefaultMetadataResolver is wrong, and is actually complemented by MRESOLVER-349, so is really not needed. The change happened for DefaultDeployer is correct. In short, DefaultArtifactResolver within syncContext will invoke DefaultMetadataResolver that may case "lock upgrade" attempt that is NOT supported by named locks -> failure. Just undo the change and make two component as before, always use exclusive locks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7805) The modelVersion should be inferred from the namespace used
[ https://issues.apache.org/jira/browse/MNG-7805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734240#comment-17734240 ] ASF GitHub Bot commented on MNG-7805: - gnodet merged PR #1148: URL: https://github.com/apache/maven/pull/1148 > The modelVersion should be inferred from the namespace used > --- > > Key: MNG-7805 > URL: https://issues.apache.org/jira/browse/MNG-7805 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > The model reader currently completely ignores the namespace, but it should be > quite easy to get it and, if the modelVersion is not set, derive it from the > namespace. > This would make modelVersion effectively optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7059) Add profile-free repository support in Maven Settings model
[ https://issues.apache.org/jira/browse/MNG-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7059. Resolution: Fixed > Add profile-free repository support in Maven Settings model > --- > > Key: MNG-7059 > URL: https://issues.apache.org/jira/browse/MNG-7059 > Project: Maven > Issue Type: New Feature > Components: Settings >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > With MNG-4645 = the move of Maven Central repository definition out of [Super > POM|https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html] > into global settings, [current settings > model|https://maven.apache.org/ref/3.6.3/maven-settings/settings.html] forces > to use a profile, although central repository should be always there w/o a > profile. > Settings Model version 1.2.0 shall have native support for repositories w/o > the need to use profiles. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7632) Regression: combine.children breaks when combining executions
[ https://issues.apache.org/jira/browse/MNG-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734241#comment-17734241 ] ASF GitHub Bot commented on MNG-7632: - gnodet merged PR #1168: URL: https://github.com/apache/maven/pull/1168 > Regression: combine.children breaks when combining executions > - > > Key: MNG-7632 > URL: https://issues.apache.org/jira/browse/MNG-7632 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-2 >Reporter: Lenny Primak >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 4.0.0-alpha-6 > > > When upgrading from 3.x to 4.x, combine.children behaves differently. > When it is declared in the parent pom, the child pom do not correctly combine > elements: > See > [https://github.com/flowlogix/flowlogix/commit/301f428a229f4ab51e55a488bd71ec4aec87bce4] > for a reproducer. > > Prior to maven 4, you could put combine.children into the parent pom and it > would work. Since maven 4, combine.children only works when put into the > child pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7805) The modelVersion should be inferred from the namespace used
[ https://issues.apache.org/jira/browse/MNG-7805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7805. Resolution: Fixed > The modelVersion should be inferred from the namespace used > --- > > Key: MNG-7805 > URL: https://issues.apache.org/jira/browse/MNG-7805 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > The model reader currently completely ignores the namespace, but it should be > quite easy to get it and, if the modelVersion is not set, derive it from the > namespace. > This would make modelVersion effectively optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6112) Align artifacts and plugins policies using the default value
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734238#comment-17734238 ] ASF GitHub Bot commented on MNG-6112: - gnodet merged PR #1142: URL: https://github.com/apache/maven/pull/1142 > Align artifacts and plugins policies using the default value > > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Guillaume Nodet >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.0-alpha-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7632) Regression: combine.children breaks when combining executions
[ https://issues.apache.org/jira/browse/MNG-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-7632. Resolution: Fixed > Regression: combine.children breaks when combining executions > - > > Key: MNG-7632 > URL: https://issues.apache.org/jira/browse/MNG-7632 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-2 >Reporter: Lenny Primak >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 4.0.0-alpha-6 > > > When upgrading from 3.x to 4.x, combine.children behaves differently. > When it is declared in the parent pom, the child pom do not correctly combine > elements: > See > [https://github.com/flowlogix/flowlogix/commit/301f428a229f4ab51e55a488bd71ec4aec87bce4] > for a reproducer. > > Prior to maven 4, you could put combine.children into the parent pom and it > would work. Since maven 4, combine.children only works when put into the > child pom. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #1168: [MNG-7632] Regression: combine.children breaks when combining executions
gnodet merged PR #1168: URL: https://github.com/apache/maven/pull/1168 -- 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-6112) Align artifacts and plugins policies using the default value
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-6112. Resolution: Fixed > Align artifacts and plugins policies using the default value > > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Guillaume Nodet >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.0-alpha-6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7059) Add profile-free repository support in Maven Settings model
[ https://issues.apache.org/jira/browse/MNG-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734236#comment-17734236 ] ASF GitHub Bot commented on MNG-7059: - gnodet merged PR #1139: URL: https://github.com/apache/maven/pull/1139 > Add profile-free repository support in Maven Settings model > --- > > Key: MNG-7059 > URL: https://issues.apache.org/jira/browse/MNG-7059 > Project: Maven > Issue Type: New Feature > Components: Settings >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-6 > > > With MNG-4645 = the move of Maven Central repository definition out of [Super > POM|https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html] > into global settings, [current settings > model|https://maven.apache.org/ref/3.6.3/maven-settings/settings.html] forces > to use a profile, although central repository should be always there w/o a > profile. > Settings Model version 1.2.0 shall have native support for repositories w/o > the need to use profiles. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] gnodet merged pull request #266: [MNG-4645] Fix IT to not use the newly supported syntax
gnodet merged PR #266: URL: https://github.com/apache/maven-integration-testing/pull/266 -- 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-6112) Align artifacts and plugins policies using the default value
[
https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734227#comment-17734227
]
ASF GitHub Bot commented on MNG-6112:
-
slawekjaranowski commented on code in PR #1142:
URL: https://github.com/apache/maven/pull/1142#discussion_r1234169184
##
maven-settings-builder/src/main/java/org/apache/maven/settings/building/DefaultSettingsBuilder.java:
##
@@ -104,6 +106,26 @@ public SettingsBuildingResult
build(SettingsBuildingRequest request) throws Sett
settingsMerger.merge(projectSettings, globalSettings,
TrackableBase.GLOBAL_LEVEL);
settingsMerger.merge(userSettings, projectSettings,
TrackableBase.PROJECT_LEVEL);
+// If no repository is defined in the user/global settings,
+// it means that we have "old" settings (as those are new in 4.0)
+// so add central to the computed settings for backward compatibility.
+if (userSettings.getRepositories().isEmpty()
+&& userSettings.getPluginRepositories().isEmpty()) {
+Repository central = new Repository();
+central.setId("central");
+central.setName("Central Repository");
+central.setUrl("https://repo.maven.apache.org/maven2";);
+RepositoryPolicy disabledPolicy = new RepositoryPolicy();
+disabledPolicy.setEnabled(false);
+central.setSnapshots(disabledPolicy);
+userSettings.getRepositories().add(central);
+central = central.clone();
+RepositoryPolicy updateNeverPolicy = new RepositoryPolicy();
+disabledPolicy.setUpdatePolicy("never");
Review Comment:
here we override update policy - but in settings.xml we don't such it
> Align artifacts and plugins policies using the default value
>
>
> Key: MNG-6112
> URL: https://issues.apache.org/jira/browse/MNG-6112
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0-beta-1
>Reporter: Christian Schulte
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: must-be-in-4.0.0-alpha-2
> Fix For: 4.0.0-alpha-6
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #1142: [MNG-6112] Make central update policy coherent
slawekjaranowski commented on code in PR #1142:
URL: https://github.com/apache/maven/pull/1142#discussion_r1234169184
##
maven-settings-builder/src/main/java/org/apache/maven/settings/building/DefaultSettingsBuilder.java:
##
@@ -104,6 +106,26 @@ public SettingsBuildingResult
build(SettingsBuildingRequest request) throws Sett
settingsMerger.merge(projectSettings, globalSettings,
TrackableBase.GLOBAL_LEVEL);
settingsMerger.merge(userSettings, projectSettings,
TrackableBase.PROJECT_LEVEL);
+// If no repository is defined in the user/global settings,
+// it means that we have "old" settings (as those are new in 4.0)
+// so add central to the computed settings for backward compatibility.
+if (userSettings.getRepositories().isEmpty()
+&& userSettings.getPluginRepositories().isEmpty()) {
+Repository central = new Repository();
+central.setId("central");
+central.setName("Central Repository");
+central.setUrl("https://repo.maven.apache.org/maven2";);
+RepositoryPolicy disabledPolicy = new RepositoryPolicy();
+disabledPolicy.setEnabled(false);
+central.setSnapshots(disabledPolicy);
+userSettings.getRepositories().add(central);
+central = central.clone();
+RepositoryPolicy updateNeverPolicy = new RepositoryPolicy();
+disabledPolicy.setUpdatePolicy("never");
Review Comment:
here we override update policy - but in settings.xml we don't such it
--
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] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-220:
--
Fix Version/s: 1.9.13
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.13
>
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-220) Modify signaling for unsupported operations
[
https://issues.apache.org/jira/browse/MRESOLVER-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734198#comment-17734198
]
ASF GitHub Bot commented on MRESOLVER-220:
--
cstamas opened a new pull request, #301:
URL: https://github.com/apache/maven-resolver/pull/301
Instead to silently "send result" (that is false) to caller, as this makes
totally strange outcome: "failed to lock within 30sec" but caller did not wait
anything. Moreover, the bug where upgrade is attempted slips in unnoticed.
---
https://issues.apache.org/jira/browse/MRESOLVER-220
> Modify signaling for unsupported operations
> ---
>
> Key: MRESOLVER-220
> URL: https://issues.apache.org/jira/browse/MRESOLVER-220
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Tamas Cservenak
>Priority: Major
>
> Lock upgrading is not supported, it is the caller that must be aware of this.
> Currently the code for all implementations returns {{false}} in case of lock
> upgrade attempted, same way as locking failed. IMHO, we should change this to
> some exception maybe?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-372) Download fails if file is currently in use under windows
Christoph Läubrich created MRESOLVER-372:
Summary: Download fails if file is currently in use under windows
Key: MRESOLVER-372
URL: https://issues.apache.org/jira/browse/MRESOLVER-372
Project: Maven Resolver
Issue Type: Bug
Reporter: Christoph Läubrich
With the new file-locking in maven-resolver there is a problem under windows if
the file is currently used by another process (this can for example happen in
an IDE ...) and resolver likes to move the file:
{code:java}
Caused by: java.nio.file.AccessDeniedException:
xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at java.base/java.nio.file.Files.move(Files.java:1432)
at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
... 30 more{code}
My suggestion would be that resolver simply uses the temp file if it can't be
moved to final location and marks it as delete on exit. Even though this is not
optimal, it at least ensures the the build does not fail to the cost that next
time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734186#comment-17734186 ] ASF GitHub Bot commented on MSHARED-1273: - elharo opened a new pull request, #160: URL: https://github.com/apache/maven-shared-utils/pull/160 (no comment) > getFiles/getFileNames do not throw IOException > -- > > Key: MSHARED-1273 > URL: https://issues.apache.org/jira/browse/MSHARED-1273 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lenny Primak updated MNG-7818:
--
Description:
junit 4 now has exclusions for hamcrest-core, which causes
ClassNotFouncException
BTW: Using hamcrest-core 2.2 (as opposed to 1.3 and without exclusions) with
JUnit 4 works just fine as well, making the exclusion, again, unnecessary
Traced to https://issues.apache.org/jira/browse/MNG-7670
{code:java}
[INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 s
<<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
[ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
elapsed: 0.009 s <<< ERROR!
java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at
java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
at java.base/java.lang.Class.getConstructor0(Class.java:3678)
at java.base/java.lang.Class.getConstructor(Class.java:2368)
at
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
at
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
at
org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
at
org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
at
org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at
org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 28 more {code}
was:
junit 4 now has exclusions for hamcrest-core, which causes
ClassNotFouncException
BTW: upgrading hamcrest-core to 2.2 (without exclusions) works just fine as well
Traced to https://issues.apache.org/jira/browse/MNG-7670
{code:java}
[INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088 s
<<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
[ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
elapsed: 0.009 s <<< ERROR!
java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
at
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at
java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
at
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader
[jira] [Commented] (MNG-7818) [REGRESSION] maven improperly excludes hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734169#comment-17734169
]
Lenny Primak commented on MNG-7818:
---
I still don't see why hamcrest-core is excluded from JUnit, which clearly
requires it. Why not just remove the exclusion and be done with it?
Since hamcrest 2.2 is already included, upgrade will still "happen"
> [REGRESSION] maven improperly excludes hamcrest-core from junit
> ---
>
> Key: MNG-7818
> URL: https://issues.apache.org/jira/browse/MNG-7818
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.9.2
> Environment: Any
>Reporter: Lenny Primak
>Priority: Minor
>
> junit 4 now has exclusions for hamcrest-core, which causes
> ClassNotFouncException
> BTW: upgrading hamcrest-core to 2.2 (without exclusions) works just fine as
> well
> Traced to https://issues.apache.org/jira/browse/MNG-7670
> {code:java}
> [INFO] Running com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.088
> s <<< FAILURE! -- in com.flowlogix.arqsuite.DeploymentOneTest
> [ERROR] com.flowlogix.arqsuite.DeploymentOneTest.initializationError -- Time
> elapsed: 0.009 s <<< ERROR!
> java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1013)
> at
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
> at
> java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3473)
> at java.base/java.lang.Class.getConstructor0(Class.java:3678)
> at java.base/java.lang.Class.getConstructor(Class.java:2368)
> at
> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
> at
> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:86)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:37)
> at
> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:70)
> at
> org.junit.internal.requests.ClassRequest.createRunner(ClassRequest.java:28)
> at
> org.junit.internal.requests.MemoizingRequest.getRunner(MemoizingRequest.java:19)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:314)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
> Caused by: java.lang.ClassNotFoundException: org.hamcrest.SelfDescribing
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 28 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734160#comment-17734160 ] ASF GitHub Bot commented on MSHARED-1273: - slachiewicz commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1597109735 No problem. You just have to release minor versions and not bugfix > getFiles/getFileNames do not throw IOException > -- > > Key: MSHARED-1273 > URL: https://issues.apache.org/jira/browse/MSHARED-1273 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] slachiewicz commented on pull request #158: [MSHARED-1273] clean up API doc and exceptions
slachiewicz commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1597109735 No problem. You just have to release minor versions and not bugfix -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734159#comment-17734159 ] ASF GitHub Bot commented on MSHARED-1273: - elharo commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1597107134 You're right. I think I was mixing up catch blocks for unthrown exceptions and throws clauses for unthrown exceptions in my head. I'll send another PR to clean this up. > getFiles/getFileNames do not throw IOException > -- > > Key: MSHARED-1273 > URL: https://issues.apache.org/jira/browse/MSHARED-1273 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] elharo commented on pull request #158: [MSHARED-1273] clean up API doc and exceptions
elharo commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1597107134 You're right. I think I was mixing up catch blocks for unthrown exceptions and throws clauses for unthrown exceptions in my head. I'll send another PR to clean this up. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734158#comment-17734158
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233970781
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
Make this log message distinct. E.g. "Byte code of " + className + " is
corrupt" and possibly include the name or path of the jar file in which the
class appears.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (
[GitHub] [maven-dependency-analyzer] elharo commented on a diff in pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
elharo commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233970781
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
Make this log message distinct. E.g. "Byte code of " + className + " is
corrupt" and possibly include the name or path of the jar file in which the
class appears.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734152#comment-17734152
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233971298
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
Review Comment:
Might be helpful to include the exception in the warning here as well
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
Make this log message distinct. E.g. "Byte code of " + className + " is
corrupt" an possibly include the name or path of the jar file in which the
class appears.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor
[GitHub] [maven-dependency-analyzer] elharo commented on a diff in pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
elharo commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233971298
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
Review Comment:
Might be helpful to include the exception in the warning here as well
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -75,6 +75,9 @@ public void visitClass(String className, InputStream in) {
// some bug inside ASM causes an IOB exception. Log it and move on?
// this happens when the class isn't valid.
logger.warn("Unable to process: " + className);
+} catch (IllegalArgumentException e) {
+// [MSHARED-1248] should log instead of failing when analyzing a
corrupted jar file
+logger.warn("Unable to process: " + className, e);
Review Comment:
Make this log message distinct. E.g. "Byte code of " + className + " is
corrupt" an possibly include the name or path of the jar file in which the
class appears.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1248) maven-dependency-analyzer should log instead of failing when analyzing a corrupted jar file
[
https://issues.apache.org/jira/browse/MSHARED-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734149#comment-17734149
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo commented on PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#issuecomment-1597073456
I think this PR is the better approach. Excluding files only works when you
know in advance which files are corrupt. I know from experience that's not
always true. There are corrupt jar files in the wild, including a few in Maven
Central. The general principle in play is that tools should accept any input,
including arbitrary byte sequences that do not meet expectations, and
gracefully reject them without crashing. In this case that means the dependency
analyzer should log the problem with a particular jar file and continue with
the rest of the build.
Since the dependency analyzer is a library, not a plugin, it should never
abort the build. It can report the issues it detects up the chain to plugins
that can be configured to respond to a corrupt jar in the way that makes the
most sense for the particular project.
> maven-dependency-analyzer should log instead of failing when analyzing a
> corrupted jar file
> ---
>
> Key: MSHARED-1248
> URL: https://issues.apache.org/jira/browse/MSHARED-1248
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.13.1
> Environment: Apache Maven 3.9.1
> (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: C:\java\apache-maven-3.9.1
> Java version: 1.8.0_362, vendor: Temurin, runtime: C:\Program Files\Eclipse
> Adoptium\jdk-8.0.362.9-hotspot\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> Microsoft Windows [Version 10.0.19044.2728]
>Reporter: Gary D. Gregory
>Priority: Major
>
> In Apache Commons BCEL, we include corrupted jar files created by the
> oss-fuzz project which causes the build to fail when the CycloneDX plugin
> runs to create an SBOM.
> This issue happens only after getting past the issue fixed by MSHARED-1247
> {noformat}
> [DEBUG] CycloneDX: Calculating Hashes
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 3.594 s
> [INFO] Finished at: 2023-04-29T15:23:05-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom (default-cli) on
> project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom
> (default-cli) on project bcel: Execution default-cli of goal
> org.cyclonedx:cyclonedx-maven-plugin:2.7.7:makeAggregateBom failed:
> Unsupported class file major version 1025 from directory =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes, path =
> C:\Users\ggregory\git\a\commons-bcel\target\test-classes\ossfuzz\issue51980\Test.class
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:347)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:330)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:213)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:175)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:76)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:163)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.
[GitHub] [maven-dependency-analyzer] elharo commented on pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
elharo commented on PR #89: URL: https://github.com/apache/maven-dependency-analyzer/pull/89#issuecomment-1597073456 I think this PR is the better approach. Excluding files only works when you know in advance which files are corrupt. I know from experience that's not always true. There are corrupt jar files in the wild, including a few in Maven Central. The general principle in play is that tools should accept any input, including arbitrary byte sequences that do not meet expectations, and gracefully reject them without crashing. In this case that means the dependency analyzer should log the problem with a particular jar file and continue with the rest of the build. Since the dependency analyzer is a library, not a plugin, it should never abort the build. It can report the issues it detects up the chain to plugins that can be configured to respond to a corrupt jar in the way that makes the most sense for the particular project. -- 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-7714) sp < final
[
https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734146#comment-17734146
]
ASF GitHub Bot commented on MNG-7714:
-
elharo commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1233935475
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -422,6 +439,106 @@ public String toString() {
}
}
+/**
+ * Represents a combination in the version item list.
+ * It is usually a combination of a string and a number, with the string
first and the number second
+ */
+private static class CombinationItem implements Item {
+
+StringItem stringValue;
Review Comment:
This confused since I initially thought these were different representations
of the same value. How about stringPart and digitPart?
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
Review Comment:
testVersionsHaveSameOrderButAreNotEqual
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -101,6 +102,21 @@ private void checkVersionsEqual(String v1, String v2) {
assertEquals(c2, c1, "expected " + v2 + ".equals( " + v1 + " )");
}
+private void checkVersionsEqualOrder(String v1, String v2) {
+ComparableVersion c1 = new ComparableVersion(v1);
+ComparableVersion c2 = new ComparableVersion(v2);
+assertEquals(0, c1.compareTo(c2), "expected " + v1 + " == " + v2);
+assertEquals(0, c2.compareTo(c1), "expected " + v2 + " == " + v1);
+}
+
+private void checkVersionObjectInequality(String v1, String v2) {
Review Comment:
checkVersionsAreNotEqual
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -383,4 +412,15 @@ void testMng7644() {
checkVersionsEqual("2.0." + x, "2.0.0." + x); // previously
ordered, now equals
}
}
+
+@Test
+public void testMng7714() {
+String f = "1.0.final-redhat";
Review Comment:
Make these variables ComparableVersions, not strings, and then inline
checkVersionsOrder in this method so it's easier to understand in one place
what is being tested. `checkVersionsOrder(f, sp1)` is unclear because it does
not indicate whether f is expected to be less than, equal to, or greater than
sp1.
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -101,6 +101,13 @@ private void checkVersionsEqual(String v1, String v2) {
assertEquals(c2, c1, "expected " + v2 + ".equals( " + v1 + " )");
}
+private void checkVersionsEqualOrder(String v1, String v2) {
Review Comment:
I see what's happening here now, but only because I've been over this a few
times. Consider renaming this method to checkVersionsHaveSameOrder or
checkVersionsAreOrderedTheSame
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
+checkVersionsEqualOrder("1ga", "1");
+checkVersionOb
[GitHub] [maven] elharo commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
elharo commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1233935475
##
maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java:
##
@@ -422,6 +439,106 @@ public String toString() {
}
}
+/**
+ * Represents a combination in the version item list.
+ * It is usually a combination of a string and a number, with the string
first and the number second
+ */
+private static class CombinationItem implements Item {
+
+StringItem stringValue;
Review Comment:
This confused since I initially thought these were different representations
of the same value. How about stringPart and digitPart?
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
Review Comment:
testVersionsHaveSameOrderButAreNotEqual
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -101,6 +102,21 @@ private void checkVersionsEqual(String v1, String v2) {
assertEquals(c2, c1, "expected " + v2 + ".equals( " + v1 + " )");
}
+private void checkVersionsEqualOrder(String v1, String v2) {
+ComparableVersion c1 = new ComparableVersion(v1);
+ComparableVersion c2 = new ComparableVersion(v2);
+assertEquals(0, c1.compareTo(c2), "expected " + v1 + " == " + v2);
+assertEquals(0, c2.compareTo(c1), "expected " + v2 + " == " + v1);
+}
+
+private void checkVersionObjectInequality(String v1, String v2) {
Review Comment:
checkVersionsAreNotEqual
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -383,4 +412,15 @@ void testMng7644() {
checkVersionsEqual("2.0." + x, "2.0.0." + x); // previously
ordered, now equals
}
}
+
+@Test
+public void testMng7714() {
+String f = "1.0.final-redhat";
Review Comment:
Make these variables ComparableVersions, not strings, and then inline
checkVersionsOrder in this method so it's easier to understand in one place
what is being tested. `checkVersionsOrder(f, sp1)` is unclear because it does
not indicate whether f is expected to be less than, equal to, or greater than
sp1.
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -101,6 +101,13 @@ private void checkVersionsEqual(String v1, String v2) {
assertEquals(c2, c1, "expected " + v2 + ".equals( " + v1 + " )");
}
+private void checkVersionsEqualOrder(String v1, String v2) {
Review Comment:
I see what's happening here now, but only because I've been over this a few
times. Consider renaming this method to checkVersionsHaveSameOrder or
checkVersionsAreOrderedTheSame
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -162,21 +173,39 @@ void testVersionsEqual() {
checkVersionsEqual("1A", "1a");
checkVersionsEqual("1B", "1b");
checkVersionsEqual("1M", "1m");
-checkVersionsEqual("1Ga", "1");
-checkVersionsEqual("1GA", "1");
-checkVersionsEqual("1RELEASE", "1");
-checkVersionsEqual("1release", "1");
-checkVersionsEqual("1RELeaSE", "1");
-checkVersionsEqual("1Final", "1");
-checkVersionsEqual("1FinaL", "1");
-checkVersionsEqual("1FINAL", "1");
checkVersionsEqual("1Cr", "1Rc");
checkVersionsEqual("1cR", "1rC");
checkVersionsEqual("1m3", "1Milestone3");
checkVersionsEqual("1m3", "1MileStone3");
checkVersionsEqual("1m3", "1MILESTONE3");
}
+@Test
+void testVersionsEqualOrderAndObjectInequality() {
+checkVersionsEqualOrder("1ga", "1");
+checkVersionObjectInequality("1ga", "1");
Review Comment:
Is inequality part of the API for ComparableVersion or is it an
implementation detail? If the former it should be added to the class JavaDoc.
If the latter, it shouldn't be tested.
##
mav
[jira] [Created] (MDEP-874) Warning: Could not get javadoc URL for reference FileMapper at FullyQualifiedJavadocReference
Elliotte Rusty Harold created MDEP-874: -- Summary: Warning: Could not get javadoc URL for reference FileMapper at FullyQualifiedJavadocReference Key: MDEP-874 URL: https://issues.apache.org/jira/browse/MDEP-874 Project: Maven Dependency Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold seen in build [INFO] --- plugin:3.7.0:descriptor (default-descriptor) @ maven-dependency-plugin --- [INFO] Using 'UTF-8' encoding to read mojo source files. Warning: Could not get javadoc URL for reference StrictPatternExcludesArtifactFilter at FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.artifact.filter], className=Optional[StrictPatternExcludesArtifactFilter], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] (fully qualified src/main/java/org/apache/maven/plugins/dependency/tree/TreeMojo.java:214): Found no javadoc site for FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.artifact.filter], className=Optional[StrictPatternExcludesArtifactFilter], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] Warning: Could not get javadoc URL for reference StrictPatternIncludesArtifactFilter at FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.artifact.filter], className=Optional[StrictPatternIncludesArtifactFilter], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] (fully qualified src/main/java/org/apache/maven/plugins/dependency/tree/TreeMojo.java:193): Found no javadoc site for FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.artifact.filter], className=Optional[StrictPatternIncludesArtifactFilter], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] Warning: Could not get javadoc URL for reference ProjectDependencyAnalyzer at FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.dependency.analyzer], className=Optional[ProjectDependencyAnalyzer], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] (fully qualified src/main/java/org/apache/maven/plugins/dependency/analyze/AbstractAnalyzeMojo.java:56): Found no javadoc site for FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.apache.maven.shared.dependency.analyzer], className=Optional[ProjectDependencyAnalyzer], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] Warning: Could not get javadoc URL for reference FileMapper at FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.codehaus.plexus.components.io.filemappers], className=Optional[FileMapper], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] (fully qualified src/main/java/org/apache/maven/plugins/dependency/fromConfiguration/UnpackMojo.java:90): Found no javadoc site for FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.codehaus.plexus.components.io.filemappers], className=Optional[FileMapper], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] Warning: Could not get javadoc URL for reference FileMapper at FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.codehaus.plexus.components.io.filemappers], className=Optional[FileMapper], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] (fully qualified src/main/java/org/apache/maven/plugins/dependency/fromDependencies/UnpackDependenciesMojo.java:98): Found no javadoc site for FullyQualifiedJavadocReference [moduleName=Optional.empty, packageName=Optional[org.codehaus.plexus.components.io.filemappers], className=Optional[FileMapper], memberType=Optional.empty, member=Optional.empty, label=Optional.empty, isExternal=true] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734136#comment-17734136 ] ASF GitHub Bot commented on MDEP-872: - elharo commented on PR #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326#issuecomment-1597011330 Failure on JDK 8 is curious: Error: org.apache.maven.plugins.dependency.fromConfiguration.TestUnpackMojo.testUnpackFile Time elapsed: 2.832 s <<< ERROR! java.lang.OutOfMemoryError: Java heap space > update commons-io to 2.13.0 > --- > > Key: MDEP-872 > URL: https://issues.apache.org/jira/browse/MDEP-872 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734131#comment-17734131 ] ASF GitHub Bot commented on MSHARED-1273: - slachiewicz commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1596999610 external code that use this methods and catch exception will be broken after update > getFiles/getFileNames do not throw IOException > -- > > Key: MSHARED-1273 > URL: https://issues.apache.org/jira/browse/MSHARED-1273 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] slachiewicz commented on pull request #158: [MSHARED-1273] clean up API doc and exceptions
slachiewicz commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1596999610 external code that use this methods and catch exception will be broken after update -- 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] (MCHECKSTYLE-439) Upgrade to parent POM 40
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734129#comment-17734129 ] ASF GitHub Bot commented on MCHECKSTYLE-439: slachiewicz commented on PR #123: URL: https://github.com/apache/maven-checkstyle-plugin/pull/123#issuecomment-1596993917 I can do a release anyway of the plexus container. We also made more cleanups > Upgrade to parent POM 40 > > > Key: MCHECKSTYLE-439 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-439 > Project: Maven Checkstyle Plugin > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.3.1 > > > Mostly to get rid of majority of plugin warnings, as many plugins got updates. > As a sidenote, downgrade from plexus 2.1.1 to 2.1.0 as 2.1.1 is known to be > broken (is NOT affecting checkstyle build, but just to be on safe side) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17734130#comment-17734130 ] ASF GitHub Bot commented on MSHARED-1273: - elharo merged PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158 > getFiles/getFileNames do not throw IOException > -- > > Key: MSHARED-1273 > URL: https://issues.apache.org/jira/browse/MSHARED-1273 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] elharo merged pull request #158: [MSHARED-1273] clean up API doc and exceptions
elharo merged PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158 -- 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
