[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=17734008#comment-17734008 ] ASF GitHub Bot commented on MNG-7811: - hboutemy commented on code in PR #429: URL: https://github.com/apache/maven-site/pull/429#discussion_r1233550764 ## 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: are these really "internal"? Isn't it just a switch between the 2 sections? I really find internal vs external a good start, but now I see that "Internal Plugin" and "Plugin Internals" just say the exact opposite :) ## 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: "Internal Plugins Validation" vs "External Plugins Validation" what about "Plugin User Validation" vs "Plugin Developer Validation"? "Plugin Internals Validation" vs "Plugin Usage Validation"? ## 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. + +Users can add such property to their `settings.xml` file to change configuration globally. Review Comment: link settings.xml to https://maven.apache.org/ref/current/maven-settings/settings.html ## 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
[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_r1233550764 ## 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: are these really "internal"? Isn't it just a switch between the 2 sections? I really find internal vs external a good start, but now I see that "Internal Plugin" and "Plugin Internals" just say the exact opposite :) ## 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: "Internal Plugins Validation" vs "External Plugins Validation" what about "Plugin User Validation" vs "Plugin Developer Validation"? "Plugin Internals Validation" vs "Plugin Usage Validation"? ## 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. + +Users can add such property to their `settings.xml` file to change configuration globally. Review Comment: link settings.xml to https://maven.apache.org/ref/current/maven-settings/settings.html ## 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
[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=17734003#comment-17734003
]
ASF GitHub Bot commented on MNG-7811:
-
hboutemy commented on PR #429:
URL: https://github.com/apache/maven-site/pull/429#issuecomment-1596522236
> some proposition which menu item should link for this page?
definitively a user section https://maven.apache.org/users/index.html, but
where more precisely?
we have the "Guides", or the "Configuring Plugins" given this is for plugins
only
> 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 pull request #429: [MNG-7811] Documentation for Plugin Validation
hboutemy commented on PR #429: URL: https://github.com/apache/maven-site/pull/429#issuecomment-1596522236 > some proposition which menu item should link for this page? definitively a user section https://maven.apache.org/users/index.html, but where more precisely? we have the "Guides", or the "Configuring Plugins" given this is for plugins only -- 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=17733986#comment-17733986
]
ASF GitHub Bot commented on MNG-7714:
-
CrazyHZM commented on code in PR #1099:
URL: https://github.com/apache/maven/pull/1099#discussion_r1233451989
##
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:
@elharo
I have modified it, please review again.
> 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-6
>
>
> 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_r1233451989
##
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:
@elharo
I have modified it, please review again.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (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=17733970#comment-17733970
]
Lenny Primak edited comment on MNG-7818 at 6/19/23 12:17 AM:
-
How? Shrinkwrap of course :) It uses maven as a library to produce an
executable to be tested. Since shrinkwrap (minor version) has updated maven to
3.9.2, and 3.9.2 was the one started excluding hamcrest, error showed up here.
Here's a link to reproducer:
[https://github.com/flowlogix/test-arq-suite/blob/JUnit4/pom.xml#L46|https://github.com/flowlogix/test-arq-suite/blob/6541eb3f6943bd223b5048f6f9ec392b58a9954c/pom.xml#L46]
If you have docker, run to reproduce
{code:java}
$ mvn verify{code}
if no docker,
{code:java}
$ mvn verify -Ppayara-server-managed {code}
was (Author: lprimak):
How? Shrinkwrap of course :) It uses maven as a library to produce an
executable to be tested. Since shrinkwrap (minor version) has updated maven to
3.9.2, and 3.9.2 was the one started excluding hamcrest, error showed up here.
Here's a link to reproducer:
[https://github.com/flowlogix/test-arq-suite/blob/JUnit4/pom.xml#L46|https://github.com/flowlogix/test-arq-suite/blob/6541eb3f6943bd223b5048f6f9ec392b58a9954c/pom.xml#L46]
> 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
>
[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=17733970#comment-17733970
]
Lenny Primak commented on MNG-7818:
---
How? Shrinkwrap of course :) It uses maven as a library to produce an
executable to be tested. Since shrinkwrap (minor version) has updated maven to
3.9.2, and 3.9.2 was the one started excluding hamcrest, error showed up here.
Here's a link to reproducer:
[https://github.com/flowlogix/test-arq-suite/blob/JUnit4/pom.xml#L46|https://github.com/flowlogix/test-arq-suite/blob/6541eb3f6943bd223b5048f6f9ec392b58a9954c/pom.xml#L46]
> 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] [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:
--
Summary: Regression: maven improperly excludes hamcrest-core from junit
(was: Regression: maven improperly exclude hamcrest-core from junit)
> 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-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=17733966#comment-17733966
]
ASF GitHub Bot commented on MSHARED-1248:
-
garydgregory commented on PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#issuecomment-1596286870
@slawekjaranowski
That sounds reasonable but much more complicated, which I am ok with as long
the use case in the jira ticket can be handled. So I guess you can close this
ticket but I am not sure who will do this work.
> 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.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
>
[GitHub] [maven-dependency-analyzer] garydgregory commented on pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
garydgregory commented on PR #89: URL: https://github.com/apache/maven-dependency-analyzer/pull/89#issuecomment-1596286870 @slawekjaranowski That sounds reasonable but much more complicated, which I am ok with as long the use case in the jira ticket can be handled. So I guess you can close this ticket but I am not sure who will do this work. -- 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=17733961#comment-17733961
]
ASF GitHub Bot commented on MSHARED-1248:
-
slawekjaranowski commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233382350
##
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:
As I see all project production and tests classes are analyzed.
Maybe allowing exclusion for some path, patterns will be what we need.
In specific project we know which classes are broken and which should be
excluded.
So we not need to ignore errors when we will can exclude what we want.
@garydgregory - What do you think?
> 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
>
[GitHub] [maven-dependency-analyzer] slawekjaranowski commented on a diff in pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
slawekjaranowski commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233382350
##
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:
As I see all project production and tests classes are analyzed.
Maybe allowing exclusion for some path, patterns will be what we need.
In specific project we know which classes are broken and which should be
excluded.
So we not need to ignore errors when we will can exclude what we want.
@garydgregory - What do you think?
--
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=17733960#comment-17733960
]
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_r1233378937
##
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:
Hi @slawekjaranowski
I'm not sure how else you propose to solve
https://issues.apache.org/jira/browse/MSHARED-1248
Ideas?
> 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
[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_r1233378937
##
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:
Hi @slawekjaranowski
I'm not sure how else you propose to solve
https://issues.apache.org/jira/browse/MSHARED-1248
Ideas?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MJAVADOC-752) Setting the output directory affects dependencySourceIncludes
Henning Schmiedehausen created MJAVADOC-752:
---
Summary: Setting the output directory affects
dependencySourceIncludes
Key: MJAVADOC-752
URL: https://issues.apache.org/jira/browse/MJAVADOC-752
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: jar
Affects Versions: 3.5.0
Reporter: Henning Schmiedehausen
I have a large, multi-module build (github.com/jdbi/jdbi) where we build
separate javadoc jars for all modules. These are built with a javadoc plugin
configuration that writes the javadoc information into target/apidocs. This
works fine.
At the end of our build we aggregate all the separate javadoc modules into a
single documentation site.
This is the javadoc configuration for that:
{{
${project.build.directory}/generated-docs/apidocs
true
org.jdbi:*
Jdbi3 ${project.version} API
Jdbi3 ${project.version} API
}}
The reactor build tries to load the included modules (org.jdbi:*) but does not
look into the target/apidocs folder where the javadoc was written but from
target/generated-docs/apidocs. Setting the output directory for the aggregation
module affects the directory that the javadoc plugin uses to resolve the
dependencySourceInclude directory.
Expected effect: Setting the output directory only affects the place where the
aggregated doc is written. The plugin still picks up the existing javadoc from
the target/apidocs folders in the included modules
Observed effect: Setting the output directory makes the plugin look at the
wrong folders for the included moduled and does not find the existing
documentation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MASSEMBLY-991) XSDs for 2.2.0 missing from Maven Project Web Site
[ https://issues.apache.org/jira/browse/MASSEMBLY-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MASSEMBLY-991. - Fix Version/s: next-release Resolution: Fixed > XSDs for 2.2.0 missing from Maven Project Web Site > -- > > Key: MASSEMBLY-991 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-991 > Project: Maven Assembly Plugin > Issue Type: Task >Reporter: Robert Grimm >Assignee: Slawomir Jaranowski >Priority: Trivial > Fix For: next-release > > > XML examples throughout the Maven Project Web Site for the Assembly plugin > reference XSDs at locations [https://maven.apache.org/xsd/assembly-2.2.0.xsd] > and [https://maven.apache.org/xsd/assembly-component-2.2.0.xsd]. Currently, > these files are missing from the Maven project site resources. > A few of these XML examples may be viewed at: > # [https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html] > # > [https://maven.apache.org/plugins/maven-assembly-plugin/assembly-component.html] > Using these examples with IDEs such as IntelliJ IDEA causes problems with > code-completion support due to the missing XSDs. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-991) XSDs for 2.2.0 missing from Maven Project Web Site
[ https://issues.apache.org/jira/browse/MASSEMBLY-991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733957#comment-17733957 ] ASF GitHub Bot commented on MASSEMBLY-991: -- slawekjaranowski merged PR #149: URL: https://github.com/apache/maven-assembly-plugin/pull/149 > XSDs for 2.2.0 missing from Maven Project Web Site > -- > > Key: MASSEMBLY-991 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-991 > Project: Maven Assembly Plugin > Issue Type: Task >Reporter: Robert Grimm >Assignee: Slawomir Jaranowski >Priority: Trivial > > XML examples throughout the Maven Project Web Site for the Assembly plugin > reference XSDs at locations [https://maven.apache.org/xsd/assembly-2.2.0.xsd] > and [https://maven.apache.org/xsd/assembly-component-2.2.0.xsd]. Currently, > these files are missing from the Maven project site resources. > A few of these XML examples may be viewed at: > # [https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html] > # > [https://maven.apache.org/plugins/maven-assembly-plugin/assembly-component.html] > Using these examples with IDEs such as IntelliJ IDEA causes problems with > code-completion support due to the missing XSDs. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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=17733956#comment-17733956 ] Slawomir Jaranowski commented on MNG-7808: -- [~romain.manni-bucau] there was many changes to reports of plugin validation in 3.9.3 - can you test it? > 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-7808) Remove warnings of undefined plugin versions
[
https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733955#comment-17733955
]
Slawomir Jaranowski commented on MNG-7808:
--
{quote}
is there somewhere a list of the new "plugin validations" that have been added?
{quote}
list not present yet, but I started preparing documentations:
https://github.com/apache/maven-site/pull/429
{quote}
(these warning have really been painful given their scope, no doc, no
preparation: so many users ask about it that I'm really tired of trying to
answer)
{quote}
Can you point to such questions - it can be helpful for preparing documentation.
> 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] (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=17733953#comment-17733953
]
ASF GitHub Bot commented on MSHARED-1248:
-
slawekjaranowski commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233373650
##
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:
I'm still not sure if it will be the best solution.
Eg. when analyzer will not support jdk in newer version - user will only
have a warnings but nothing will be analyzed.
We know that warnings are many times ignored ...
> 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
[GitHub] [maven-dependency-analyzer] slawekjaranowski commented on a diff in pull request #89: [MSHARED-1248] maven-dependency-analyzer should log instead of failing
slawekjaranowski commented on code in PR #89:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/89#discussion_r1233373650
##
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:
I'm still not sure if it will be the best solution.
Eg. when analyzer will not support jdk in newer version - user will only
have a warnings but nothing will be analyzed.
We know that warnings are many times ignored ...
--
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=17733951#comment-17733951 ] ASF GitHub Bot commented on MSHARED-1273: - slawekjaranowski commented on PR #158: URL: https://github.com/apache/maven-shared-utils/pull/158#issuecomment-1596256913 Maybe commit message should contain ... `and do not throw IOException` as jira issue we don't add exceptions > 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-dependency-analyzer] slawekjaranowski merged pull request #94: Fix compiler warnings
slawekjaranowski merged PR #94: URL: https://github.com/apache/maven-dependency-analyzer/pull/94 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-7818) Regression: maven improperly exclude hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733949#comment-17733949
]
Tamas Cservenak edited comment on MNG-7818 at 6/18/23 8:21 PM:
---
I really miss HOW the change you point at (happened in Maven) affects ANY build
that USES Maven? (uses to build, not as dependency). In other words, what has
Maven dependencies to do with project you are building/testing? Can you point
me at example, reproducer? Test scope is not transitive, but even then... am
puzzled.
was (Author: cstamas):
I really miss HOW the change you point at (happened in Maven) affects ANY build
that USES Maven? (uses to build, not as dependency). In other words, what has
Maven dependencies to do with project you are building/testing? Can you point
me at example, reproducer?
> Regression: maven improperly exclude 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
[jira] [Commented] (MNG-7818) Regression: maven improperly exclude hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733949#comment-17733949
]
Tamas Cservenak commented on MNG-7818:
--
I really miss HOW the change you point at (happened in Maven) affects ANY build
that USES Maven? (uses to build, not as dependency). In other words, what has
Maven dependencies to do with project you are building/testing? Can you point
me at example, reproducer?
> Regression: maven improperly exclude 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)
[GitHub] [maven-shared-utils] elharo opened a new pull request, #159: remove and cleanup unused code
elharo opened a new pull request, #159: URL: https://github.com/apache/maven-shared-utils/pull/159 It took some digging through the PR history to figure this out, but some code paths proved to be vestiges of pre-Java 7 symlink hacks and are no longer needed. The public API and behavior is unchanged by this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] garydgregory opened a new pull request, #94: Fix compiler warnings
garydgregory opened a new pull request, #94: URL: https://github.com/apache/maven-dependency-analyzer/pull/94 - Use @Override - Use diamonds -- 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=17733946#comment-17733946 ] ASF GitHub Bot commented on MSHARED-1273: - elharo opened a new pull request, #158: URL: https://github.com/apache/maven-shared-utils/pull/158 still trying to figure out how best to replace these methods completely > 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 opened a new pull request, #158: [MSHARED-1273] clean up API doc and exceptions
elharo opened a new pull request, #158: URL: https://github.com/apache/maven-shared-utils/pull/158 still trying to figure out how best to replace these methods completely -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1273) getFiles/getFileNames do not throw IOException
Elliotte Rusty Harold created MSHARED-1273: -- Summary: 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 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1273) getFiles/getFileNames do not throw IOException
[ https://issues.apache.org/jira/browse/MSHARED-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MSHARED-1273: -- Assignee: Elliotte Rusty Harold > 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] [Commented] (MSHARED-1271) deprecate fileutils
[ https://issues.apache.org/jira/browse/MSHARED-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733944#comment-17733944 ] ASF GitHub Bot commented on MSHARED-1271: - elharo merged PR #156: URL: https://github.com/apache/maven-shared-utils/pull/156 > deprecate fileutils > --- > > Key: MSHARED-1271 > URL: https://issues.apache.org/jira/browse/MSHARED-1271 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > Seems all the methods have replacements in apache commons -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-shared-utils] elharo merged pull request #156: [MSHARED-1271] deprecate forceMkdir since a close replacement exists in Commons IO
elharo merged PR #156: URL: https://github.com/apache/maven-shared-utils/pull/156 -- 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] [Resolved] (MSHARED-1215) Deprecate maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java
[ https://issues.apache.org/jira/browse/MSHARED-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1215. Resolution: Fixed > Deprecate > maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java > - > > Key: MSHARED-1215 > URL: https://issues.apache.org/jira/browse/MSHARED-1215 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > In favor of > https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/SystemUtils.html > which is not a drop-in replacement, but is better supported, better > designed, and has more modern operating systems -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1215) Deprecate maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java
[ https://issues.apache.org/jira/browse/MSHARED-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733943#comment-17733943 ] ASF GitHub Bot commented on MSHARED-1215: - elharo merged PR #157: URL: https://github.com/apache/maven-shared-utils/pull/157 > Deprecate > maven-shared-utils/src/main/java/org/apache/maven/shared/utils/Os.java > - > > Key: MSHARED-1215 > URL: https://issues.apache.org/jira/browse/MSHARED-1215 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > In favor of > https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/SystemUtils.html > which is not a drop-in replacement, but is better supported, better > designed, and has more modern operating systems -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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=17733942#comment-17733942
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo merged PR #93:
URL: https://github.com/apache/maven-dependency-analyzer/pull/93
> 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.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
>
[GitHub] [maven-shared-utils] elharo merged pull request #157: [MSHARED-1215] deprecate Os class that hasn't been maintained for over a decade
elharo merged PR #157: URL: https://github.com/apache/maven-shared-utils/pull/157 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] elharo merged pull request #93: [MSHARED-1248] update commons-io to 2.13.0
elharo merged PR #93: URL: https://github.com/apache/maven-dependency-analyzer/pull/93 -- 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=17733940#comment-17733940 ] Herve Boutemy commented on MNG-7808: now I understand that the new "plugin validation" covers many aspects I did not know: "affects version" of this issue should be updated accordingly is there somewhere a list of the new "plugin validations" that have been added? (these warning have really been painful given their scope, no doc, no preparation: so many users ask about it that I'm really tired of trying to answer) > 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] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733939#comment-17733939
]
Benjamin Marwell commented on MSHARED-1032:
---
Ha, I wish I knew which plugin I was trying to modify when I stumbled over
this. Probably the checkstyle-plugin.
Maybe I did not mean "double call", but instead "called on two occurences", but
that is hard to guess from now. If it was from two different entry points, it
should be two different methods (imho). The default can be that one calls
another...
Then there's the exception issue, yes, which can be solved right afterwards.
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7804) add flexible goal ordering in phase
[ https://issues.apache.org/jira/browse/MNG-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733936#comment-17733936 ] ASF GitHub Bot commented on MNG-7804: - hboutemy opened a new pull request, #1173: URL: https://github.com/apache/maven/pull/1173 equivalent to #1147, but: - for Maven 3.9.x - as XML attribute `` - default priority from lifecycle weight *1000 to let space to insert executions sample use project: https://github.com/hboutemy/MNG-7804-plugin-execution-priority > add flexible goal ordering in phase > --- > > Key: MNG-7804 > URL: https://issues.apache.org/jira/browse/MNG-7804 > Project: Maven > Issue Type: New Feature > Components: Plugins and Lifecycle >Affects Versions: 3.0, 3.9.2, 4.0.0-alpha-5 >Reporter: Herve Boutemy >Assignee: Guillaume Nodet >Priority: Major > > as documented in MNG-5987 and described in MNG-5539 or MNG-6051, goals order > in a phase can't be defined in a flexible way > Adding a flexible mechanism would be useful -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hboutemy opened a new pull request, #1173: [MNG-7804] plugin execution order for Maven 3.9.x
hboutemy opened a new pull request, #1173: URL: https://github.com/apache/maven/pull/1173 equivalent to #1147, but: - for Maven 3.9.x - as XML attribute `` - default priority from lifecycle weight *1000 to let space to insert executions sample use project: https://github.com/hboutemy/MNG-7804-plugin-execution-priority -- 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=17733933#comment-17733933
]
Romain Manni-Bucau commented on MNG-7808:
-
[~hboutemy] yes, sadly we have not only 2 behaviors on that aspect (raw output:
https://gist.github.com/rmannibucau/fc07a89d554764d2826af2ff55b3a42d):
* old versions (tested on 3.8.6 in ^^) -> nothing (as expected I'd say)
* last v4 (at the beginning of the build):
{code:java}
[WARNING] Version not locked for default bindings plugins
[maven-surefire-plugin, maven-jar-plugin], you should define versions in
pluginManagement section of your pom.xml or parent {code}
* 3.9.2 (after the build, multiple lines)
{code:java}
[WARNING] [WARNING] Plugin validation issues were detected in 2
plugin(s)[WARNING] [WARNING] *
org.apache.maven.plugins:maven-resources-plugin:3.2.0[WARNING] *
org.apache.maven.plugins:maven-compiler-plugin:3.10.1[WARNING] [WARNING] For
more or less details, use 'maven.plugin.validation' property with one of the
values (case insensitive): [BRIEF, DEFAULT, VERBOSE][WARNING] {code}
> 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-7818) Regression: maven improperly exclude hamcrest-core from junit
[
https://issues.apache.org/jira/browse/MNG-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733931#comment-17733931
]
Lenny Primak commented on MNG-7818:
---
[~cstamas] yours :)
> Regression: maven improperly exclude 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] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[
https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733929#comment-17733929
]
ASF GitHub Bot commented on MDEP-799:
-
MartinWitt commented on code in PR #325:
URL:
https://github.com/apache/maven-dependency-plugin/pull/325#discussion_r128155
##
src/test/java/org/apache/maven/plugins/dependency/tree/TestTreeMojo.java:
##
@@ -127,6 +127,24 @@ public void _testTreeTGFSerializing() throws Exception {
assertTrue(findString(contents,
"testGroupId:release:jar:1.0:compile"));
}
+/**
+ * Test the JSON format serialization
+ */
+public void _testTreeJsonSerialzing() throws Exception {
+List contents = runTreeMojo("tree1.json", "json");
+assertTrue(findString(contents, "\"testGroupId\": \"project\""));
Review Comment:
I tried to keep the test case in the same style as the rest of the class.
But I can change it.
> improve mvn dependency:tree - add optional JSON output of the results
> -
>
> Key: MDEP-799
> URL: https://issues.apache.org/jira/browse/MDEP-799
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Reporter: Zhenxu Ke
>Priority: Major
>
> I'd like to add an output type JSON, will open a pull request soon
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-dependency-plugin] MartinWitt commented on a diff in pull request #325: [MDEP-799] tree: add optional output type json
MartinWitt commented on code in PR #325:
URL:
https://github.com/apache/maven-dependency-plugin/pull/325#discussion_r128155
##
src/test/java/org/apache/maven/plugins/dependency/tree/TestTreeMojo.java:
##
@@ -127,6 +127,24 @@ public void _testTreeTGFSerializing() throws Exception {
assertTrue(findString(contents,
"testGroupId:release:jar:1.0:compile"));
}
+/**
+ * Test the JSON format serialization
+ */
+public void _testTreeJsonSerialzing() throws Exception {
+List contents = runTreeMojo("tree1.json", "json");
+assertTrue(findString(contents, "\"testGroupId\": \"project\""));
Review Comment:
I tried to keep the test case in the same style as the rest of the class.
But I can change 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] [Commented] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733928#comment-17733928 ] ASF GitHub Bot commented on MSHARED-1269: - slawekjaranowski commented on PR #154: URL: https://github.com/apache/maven-shared-utils/pull/154#issuecomment-1596199236 > IMHO plexus-utils is the one that needs to go, not this. Plexus is not an apache project, and doesn't have the same controls or support as Maven. The preference order is > > JDK > Apache Commons > maben-shared-utils > plexus Here I agree with @elharo, even more many plexus components have an unclear licenses. > Deprecate maven-shared-utils > > > Key: MSHARED-1269 > URL: https://issues.apache.org/jira/browse/MSHARED-1269 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-shared-utils >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (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=17733925#comment-17733925
]
Herve Boutemy edited comment on MNG-7808 at 6/18/23 3:54 PM:
-
thank you [~romain.manni-bucau]: executing the archetype generate followed by
"mvn package" in the generated directory, I don't get any WARNING
I'm completely surprised, but that's what I get, even with older Maven:
{noformat}mvn -V package
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/herve/.sdkman/candidates/maven/3.6.3
Java version: 11.0.16, vendor: Azul Systems, Inc., runtime:
/home/herve/.sdkman/candidates/java/11.0.16-zulu
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-75-generic", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[INFO]
[INFO] -< test:camel >-
[INFO] Building A Camel Route 1.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ camel
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:testResources (default-testResources) @
camel ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @
camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ camel ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ camel ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.508 s
[INFO] Finished at: 2023-06-18T17:50:41+02:00
[INFO]
{noformat}
was (Author: hboutemy):
executing the archetype generate followed by "mvn package" in the generated
directory, I don't get any WARNING
I'm completely surprised, but that's what I get, even with older Maven:
{noformat}mvn -V package
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/herve/.sdkman/candidates/maven/3.6.3
Java version: 11.0.16, vendor: Azul Systems, Inc., runtime:
/home/herve/.sdkman/candidates/java/11.0.16-zulu
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-75-generic", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[INFO]
[INFO] -< test:camel >-
[INFO] Building A Camel Route 1.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ camel
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:testResources (default-testResources) @
camel ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @
camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ camel ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ camel ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.508 s
[INFO] Finished at: 2023-06-18T17:50:41+02:00
[INFO]
{noformat}
> Remove warnings of undefined plugin versions
>
>
> Key: MNG-7808
> URL:
[jira] [Comment Edited] (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=17733925#comment-17733925
]
Herve Boutemy edited comment on MNG-7808 at 6/18/23 3:52 PM:
-
executing the archetype generate followed by "mvn package" in the generated
directory, I don't get any WARNING
I'm completely surprised, but that's what I get, even with older Maven:
{noformat}mvn -V package
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /home/herve/.sdkman/candidates/maven/3.6.3
Java version: 11.0.16, vendor: Azul Systems, Inc., runtime:
/home/herve/.sdkman/candidates/java/11.0.16-zulu
Default locale: fr_FR, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-75-generic", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[INFO]
[INFO] -< test:camel >-
[INFO] Building A Camel Route 1.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ camel
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/main/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:compile (default-compile) @ camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:testResources (default-testResources) @
camel ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Using 'UTF-8' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory
/home/herve/tmp/init/camel/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.10.1:testCompile (default-testCompile) @
camel ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ camel ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ camel ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.508 s
[INFO] Finished at: 2023-06-18T17:50:41+02:00
[INFO]
{noformat}
was (Author: hboutemy):
executing the archetype generate followed by "mvn package" in the generated
directory, I don't get any WARNING
I'm completely surprised, but that's what I get
> 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] [Comment Edited] (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=17733925#comment-17733925 ] Herve Boutemy edited comment on MNG-7808 at 6/18/23 3:51 PM: - executing the archetype generate followed by "mvn package" in the generated directory, I don't get any WARNING I'm completely surprised, but that's what I get was (Author: hboutemy): executing the archetype generate followed by "mvn package" in the generated directory, I don't get any WARNING > 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-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733925#comment-17733925 ] Herve Boutemy commented on MNG-7808: executing the archetype generate followed by "mvn package" in the generated directory, I don't get any WARNING > 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] (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=17733917#comment-17733917
]
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_r1233317327
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -71,7 +71,7 @@ public void visitClass(String className, InputStream in) {
reader.accept(classVisitor, 0);
} catch (IOException exception) {
exception.printStackTrace();
-} catch (IndexOutOfBoundsException e) {
+} catch (IndexOutOfBoundsException | IllegalArgumentException e) {
Review Comment:
Hi @elharo
I rewrote the catch clause per your suggestion.
> 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
[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_r1233317327
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -71,7 +71,7 @@ public void visitClass(String className, InputStream in) {
reader.accept(classVisitor, 0);
} catch (IOException exception) {
exception.printStackTrace();
-} catch (IndexOutOfBoundsException e) {
+} catch (IndexOutOfBoundsException | IllegalArgumentException e) {
Review Comment:
Hi @elharo
I rewrote the catch clause per your suggestion.
--
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=17733913#comment-17733913
]
Romain Manni-Bucau commented on MNG-7808:
-
[~hboutemy] gave multiple examples in the related threads but if you want a
few:
{code:java}
mvn archetype:generate \
-DarchetypeGroupId=org.apache.camel.archetypes \
-DarchetypeArtifactId=camel-archetype-java \
-DarchetypeVersion=3.20.0 {code}
You will say me that camel must pin versions and as maven core committer, you
will also recommend to not pin default plugins to ensure it works with the most
maven versions since some archetypes are not about a specific plugin but just
building a jar or war (= 100% use maven plugins so best advice is to not bound
the pom to a version).
As explained, it is more than fine to fail if we dont support a config and we
broke a plugin for whatever reason, it is not acceptable to warn for something
we are ourself responsible (we own plugin and bind them to releases so it is
intended to not be pinned).
Last: if you want reproducibility you are bound to a mvn and java version at
build time (--release does not make it better, just more tolerance) so in such
a case, versions are locked by design so forcing the locking is overall
negative for maven and does not enhance the reproducibility - only goal AFAIK -
so we don't have to keep it.
Side note: indeed you can get the same issue with pure maven archtectype until
you bind maven version to archtetype versions which is, here again, not what we
do today nor what we want probably since it breaks consumer/producer contract.
Hope it is clearer.
> 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] [Closed] (MDEP-873) remove dependency on plexus-io
[ https://issues.apache.org/jira/browse/MDEP-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MDEP-873. -- Resolution: Won't Fix > remove dependency on plexus-io > -- > > Key: MDEP-873 > URL: https://issues.apache.org/jira/browse/MDEP-873 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > -- 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=17733901#comment-17733901 ] ASF GitHub Bot commented on MDEP-872: - elharo opened a new pull request, #326: URL: https://github.com/apache/maven-dependency-plugin/pull/326 (no comment) > 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] [Assigned] (MDEP-872) update commons-io to 2.13.0
[ https://issues.apache.org/jira/browse/MDEP-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MDEP-872: -- Assignee: Elliotte Rusty Harold > 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] [Created] (MDEP-873) remove dependency on plexus-io
Elliotte Rusty Harold created MDEP-873: -- Summary: remove dependency on plexus-io Key: MDEP-873 URL: https://issues.apache.org/jira/browse/MDEP-873 Project: Maven Dependency Plugin Issue Type: Dependency upgrade Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-872) update commons-io to 2.13.0
Elliotte Rusty Harold created MDEP-872: -- Summary: 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 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-analyzer] dependabot[bot] commented on pull request #92: Bump guava from 30.1.1-android to 32.0.0-android in /src/it/jarWithCompileDependency/project2
dependabot[bot] commented on PR #92: URL: https://github.com/apache/maven-dependency-analyzer/pull/92#issuecomment-1596112817 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on 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
[GitHub] [maven-dependency-analyzer] elharo closed pull request #92: Bump guava from 30.1.1-android to 32.0.0-android in /src/it/jarWithCompileDependency/project2
elharo closed pull request #92: Bump guava from 30.1.1-android to 32.0.0-android in /src/it/jarWithCompileDependency/project2 URL: https://github.com/apache/maven-dependency-analyzer/pull/92 -- 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=17733899#comment-17733899
]
ASF GitHub Bot commented on MSHARED-1248:
-
elharo opened a new pull request, #93:
URL: https://github.com/apache/maven-dependency-analyzer/pull/93
(no comment)
> 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.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at
[GitHub] [maven-dependency-analyzer] elharo opened a new pull request, #93: [MSHARED-1248] update commons-io to 2.13.0
elharo opened a new pull request, #93: URL: https://github.com/apache/maven-dependency-analyzer/pull/93 (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] [Created] (MSHARED-1272) commons-io to 2.13.0
Elliotte Rusty Harold created MSHARED-1272: -- Summary: commons-io to 2.13.0 Key: MSHARED-1272 URL: https://issues.apache.org/jira/browse/MSHARED-1272 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-dependency-analyzer Reporter: Elliotte Rusty Harold -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel
]
Elliotte Rusty Harold updated MSHARED-1248:
---
Issue Type: Bug (was: Improvement)
> 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.cli.MavenCli.doMain (MavenCli.java:272)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
[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=17733898#comment-17733898
]
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_r1233258151
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -71,7 +71,7 @@ public void visitClass(String className, InputStream in) {
reader.accept(classVisitor, 0);
} catch (IOException exception) {
exception.printStackTrace();
-} catch (IndexOutOfBoundsException e) {
+} catch (IndexOutOfBoundsException | IllegalArgumentException e) {
Review Comment:
The comment below doesn't apply to the new exception. It's probably better
to make this a spearate catch block with a more descriptive error message.
> 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: Improvement
> 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)
>
[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_r1233258151
##
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DependencyClassFileVisitor.java:
##
@@ -71,7 +71,7 @@ public void visitClass(String className, InputStream in) {
reader.accept(classVisitor, 0);
} catch (IOException exception) {
exception.printStackTrace();
-} catch (IndexOutOfBoundsException e) {
+} catch (IndexOutOfBoundsException | IllegalArgumentException e) {
Review Comment:
The comment below doesn't apply to the new exception. It's probably better
to make this a spearate catch block with a more descriptive error message.
--
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-193) No checked exceptions for rendering
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733886#comment-17733886 ] Herve Boutemy commented on MSHARED-193: --- if prepare stores result to file (after huge computation), renderer has to read it back perhaps looking at concrete examples where renderers were forced to work around the miss would be useful, to avoid endless theoretical discussions > 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)
[jira] [Comment Edited] (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=17733878#comment-17733878 ] Herve Boutemy edited comment on MNG-7808 at 6/18/23 9:28 AM: - vague assertion that I don't understand stopping discussion given I can't get any concrete example as asked for a long time: when not needed does not exist, then against removing anything (if a problem exists, removing warning is not the solution) was (Author: hboutemy): vague assertion that I don't understand stopping discussion given I can't get any concrete example as asked for a long time: when not needed does not exist, then against removing anything > 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] [Comment Edited] (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=17733878#comment-17733878 ] Herve Boutemy edited comment on MNG-7808 at 6/18/23 9:26 AM: - vague assertion that I don't understand stopping discussion given I can't get any concrete example as asked for a long time: when not needed does not exist, then against removing anything was (Author: hboutemy): vague assertion that I don't understand stopping discussion given I can't get any concrete example as asked for a long time > 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-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733878#comment-17733878 ] Herve Boutemy commented on MNG-7808: vague assertion that I don't understand stopping discussion given I can't get any concrete example as asked for a long time > 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] [Updated] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIASITETOOLS-254:
-
Description:
[https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
* Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
should they appear? Why is no {{position}} like with other similar elements
(logo, item)?
* Does {{href}} truly only apply to the image?
* Why is there no {{target}}?
* Must {{title}}/{{alt}} only be used on the image?
* Why not apply here the same logic as with the other imaged elements?
* Why {{src}} instead of {{img}} like the rest?
* Why does it use subelements and not attributes like the rest?
logo/link item/menu/menu item:
* Does {{href}} truly only apply to the text? (different to banner)
* Must {{title}}/{{alt}} only be used on the image?
was:
[https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
bannerLeft/bannerRight:
* Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
should they appear? Why is no {{position}} like with other similar elements
(logo, item)?
* Does {{href}} truly only apply to the image?
* Why is there no {{target}}?
* Must {{title}}/{{alt}} only be used on the image?
* Why not apply here the same logic as with the other imaged elements?
* Why {{src}} instead of {{img}} like the rest?
* Why does it use subelements and not attributes like the rest?
logo/link item/menu/menu item:
* Does {{href}} truly only apply to the text? (different to banner)
* Must {{title}}/{{alt}} only be used on the image?
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight (see also DOXIASITETOOLS-253):
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
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=17733875#comment-17733875 ] Michael Osipov commented on MSHARED-193: The IO you mention I would expect to happen in the report, don't you think? At least in all of our reporting plugins we prepare everything **outside** of the renderer. > 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)
[jira] [Updated] (DOXIASITETOOLS-253) Clarify "border", "width" and "height" for Banner and LinkItem
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIASITETOOLS-253: - Description: The elements "border", "width" and "height" in # https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_bannerLeft # https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_bannerRight # https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_item have a very vague description (same in renamed doxia-site-model https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html ). It should be clarified with regards to whether 1. this is the format of the same named CSS properties (https://www.w3.org/TR/CSS2/box.html#border-properties, https://www.w3.org/TR/CSS2/visudet.html#the-width-property and https://www.w3.org/TR/CSS2/visudet.html#the-height-property) 2. or the HTML4 attributes (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) 3. or another custom format. Currently the skins use the values as-is for either CSS property or HTML attribute, but although they are named the same, the supported values differ a lot. This came up in the context of https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. was: The elements "border", "width" and "height" in # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerRight # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_item have a very vague description. It should be clarified with regards to whether 1. this is the format of the same named CSS properties (https://www.w3.org/TR/CSS2/box.html#border-properties, https://www.w3.org/TR/CSS2/visudet.html#the-width-property and https://www.w3.org/TR/CSS2/visudet.html#the-height-property) 2. or the HTML4 attributes (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) 3. or another custom format. Currently the skins use the values as-is for either CSS property or HTML attribute, but although they are named the same, the supported values differ a lot. This came up in the context of https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. > Clarify "border", "width" and "height" for Banner and LinkItem > -- > > Key: DOXIASITETOOLS-253 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-253 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Reporter: Konrad Windszus >Priority: Major > Labels: doxia-2.0.0-stack > > The elements "border", "width" and "height" in > # > https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_bannerLeft > # > https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_bannerRight > # > https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html#class_item > have a very vague description (same in renamed doxia-site-model > https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html ). > It should be clarified with regards to whether > 1. this is the format of the same named CSS properties > (https://www.w3.org/TR/CSS2/box.html#border-properties, > https://www.w3.org/TR/CSS2/visudet.html#the-width-property and > https://www.w3.org/TR/CSS2/visudet.html#the-height-property) > 2. or the HTML4 attributes > (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and > https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) > 3. or another custom format. > Currently the skins use the values as-is for either CSS property or HTML > attribute, but although they are named the same, the supported values differ > a lot. > This came up in the context of > https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-253) Clarify "border", "width" and "height" for Banner and LinkItem
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIASITETOOLS-253: - Description: The elements "border", "width" and "height" in # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerRight # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_item have a very vague description. It should be clarified with regards to whether 1. this is the format of the same named CSS properties (https://www.w3.org/TR/CSS2/box.html#border-properties, https://www.w3.org/TR/CSS2/visudet.html#the-width-property and https://www.w3.org/TR/CSS2/visudet.html#the-height-property) 2. or the HTML4 attributes (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) 3. or another custom format. Currently the skins use the values as-is for either CSS property or HTML attribute, but although they are named the same, the supported values differ a lot. This came up in the context of https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. was: The elements "border", "width" and "height" in # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerRight # https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_item have a very vague description. It should be clarified with regards to whether this is the format of the same named CSS properties (https://www.w3.org/TR/CSS2/box.html#border-properties, https://www.w3.org/TR/CSS2/visudet.html#the-width-property and https://www.w3.org/TR/CSS2/visudet.html#the-height-property) or the HTML4 attributes (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) or another custom format. Currently the skins use the values as is for either CSS property or HTML attribute, but although the are named the same the supported values differ a lot. This came up in the context of https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. > Clarify "border", "width" and "height" for Banner and LinkItem > -- > > Key: DOXIASITETOOLS-253 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-253 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Reporter: Konrad Windszus >Priority: Major > Labels: doxia-2.0.0-stack > > The elements "border", "width" and "height" in > # > https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerLeft > # > https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_bannerRight > # > https://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html#class_item > have a very vague description. > It should be clarified with regards to whether > 1. this is the format of the same named CSS properties > (https://www.w3.org/TR/CSS2/box.html#border-properties, > https://www.w3.org/TR/CSS2/visudet.html#the-width-property and > https://www.w3.org/TR/CSS2/visudet.html#the-height-property) > 2. or the HTML4 attributes > (https://www.w3.org/TR/html401/struct/objects.html#h-13.7.1 and > https://www.w3.org/TR/html401/struct/objects.html#h-13.7.3) > 3. or another custom format. > Currently the skins use the values as-is for either CSS property or HTML > attribute, but although they are named the same, the supported values differ > a lot. > This came up in the context of > https://github.com/apache/maven-fluido-skin/pull/23#discussion_r866169720. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733874#comment-17733874
]
Herve Boutemy commented on DOXIASITETOOLS-254:
--
and we should cover DOXIASITETOOLS-254 and DOXIASITETOOLS-253 at the same time
"of course"
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight:
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
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=17733873#comment-17733873 ] Herve Boutemy commented on MSHARED-193: --- bq. A renderer (view in MVC) is the last layer, there is no logic, no data retrieval. Data (model) must be fetched and prepared by the controller, here the report and passed to the view (renderer) and the view's sole purpose is to print it out. yes, I agree but "it should" does not mean that there is never a small IO call, like reading a file that was prepared previously then yes, in general IO should not happen, but it happens sometimes and is a pain when it arrives that's why adding a MavenReportingException is IMHO a good thing (while adding the same to canGenerate() in MSHARED-1032), to make maven-reporting-api easier to use when something unexpected happens (and avoid stupid unchecked exceptions) > 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)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733872#comment-17733872
]
Herve Boutemy commented on MSHARED-1032:
now I re-read the issue from the start: "of course", not "throw Exception"
but something like renderexception (precise exception has to be chosen)
and "of course", we're talking about changing reporting-api , and it will
impact m-site-p and reporting-impl (which is the mini site:site implementation)
I've been confused with the related MSHARED-193 that has the same discussion
for another API call of reporting-api
notice: these issues should be associated to reporting-api only
impact on maven-site-plugin and reporting-api will be when they upgrade their
dependency on reporting-api
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17733870#comment-17733870 ] Romain Manni-Bucau commented on MNG-7808: - Let's make it simple: warning about defaults means maven does not support defaults anymore so is no more about convention which I think is wrong, still. > 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] [Comment Edited] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733868#comment-17733868
]
Herve Boutemy edited comment on MSHARED-1032 at 6/18/23 7:44 AM:
-
execute() and generate() does not mean executed twice: it means called in 2
conditions, either from a direct goal invocation or as from a report in
site:site goal
generate() is the important case (as execute() just adds a basic site:site
simplified goal to call generate as site does)
was (Author: hboutemy):
execute() and generate() does not mean executed twice: it means executed as a
direct goal or executed as a report in site:site goal
generate() is the important case (as execute() just adds a basic site:site
simplified goal to call generate as site does)
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733869#comment-17733869
]
Michael Osipov commented on DOXIASITETOOLS-254:
---
Correct, otherwise it will be just guessing for everyone.
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight:
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733868#comment-17733868
]
Herve Boutemy edited comment on MSHARED-1032 at 6/18/23 7:37 AM:
-
execute() and generate() does not mean executed twice: it means executed as a
direct goal or executed as a report in site:site goal
generate() is the important case (as execute() just adds a basic site:site
simplified goal to call generate as site does)
was (Author: hboutemy):
execute() and generate() does not mean executed twice: it means executed as a
direct goal or executed as a report in site:site goal
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733868#comment-17733868
]
Herve Boutemy commented on MSHARED-1032:
execute() and generate() does not mean executed twice: it means executed as a
direct goal or executed as a report in site:site goal
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> Hi everyone,
> the [{{AbstractReportMojo}} in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [{{canGenerateReport()}} from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{MavenReportEx}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on {{canGenerateReport()}}
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-254) Clarify inconsistencies in Doxia site model
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733867#comment-17733867
]
Herve Boutemy commented on DOXIASITETOOLS-254:
--
we need a clear written mapping of the initial descriptor to typical HTML
generated from skins to clarify
I don't know if a wiki page is best, or a shared whiteboard
> Clarify inconsistencies in Doxia site model
> ---
>
> Key: DOXIASITETOOLS-254
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-254
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Decoration model
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> [https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.11.1/doxia-decoration-model/decoration.html]
> bannerLeft/bannerRight:
> * Are {{name}} and {{src}} (image) mutually exclusive? If yes, in what order
> should they appear? Why is no {{position}} like with other similar elements
> (logo, item)?
> * Does {{href}} truly only apply to the image?
> * Why is there no {{target}}?
> * Must {{title}}/{{alt}} only be used on the image?
> * Why not apply here the same logic as with the other imaged elements?
> * Why {{src}} instead of {{img}} like the rest?
> * Why does it use subelements and not attributes like the rest?
> logo/link item/menu/menu item:
> * Does {{href}} truly only apply to the text? (different to banner)
> * Must {{title}}/{{alt}} only be used on the image?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-174) rename site.xml root tag from "project" to "site"
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733866#comment-17733866
]
Herve Boutemy commented on DOXIASITETOOLS-174:
--
yes (alias is key, to ease users transition)
> rename site.xml root tag from "project" to "site"
> -
>
> Key: DOXIASITETOOLS-174
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-174
> Project: Maven Doxia Sitetools
> Issue Type: Wish
> Components: Decoration model
>Affects Versions: 1.7.4
>Reporter: Herve Boutemy
>Priority: Major
> Labels: doxia-2.0.0-stack
>
> when looking at [decoration model
> descriptor|http://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-1.7/doxia-decoration-model/decoration.html],
> naming the root element as {{project}} (like for {{pom.xml}}) is misleading
> if the root element could be renamed as {{doxia-decoration}}, the obvious
> (this descriptor is about site decoration, done with Doxia) could perhaps
> become obvious
> (in IT, calling everything a "project" is an issue...)
> I know that this change of xsd schema will break compatibility, but I think
> it can really make a big difference in usability (and I should have had this
> idea for Doxia Sitetools 1.7, when we already made some breaking changes...)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[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=17733865#comment-17733865 ] Herve Boutemy commented on MNG-7808: [~romain.manni-bucau] I asked for concrete example of warnings: I said I was not able to get them any more. quickstart archetype has been updated to do the right thing, even if, yes, it is cumbersome bq. So overall we should probably just keep our philosophy and work OOTB without any side effects which don't enhance the user stability but keep it at status quo with the same downside than not having them. this sentence is so complex, when we can't be clear on simple things, that I don't know what to understand from it: keep the warnings (once we have clarified them) or not? > 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)
