[jira] [Updated] (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:all-tabpanel
]
Lenny Primak updated MNG-7818:
--
Description:
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}
was:
junit 4 has exclusions for hamcrest-core, which causes ClassNotFouncException
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
[jira] [Created] (MNG-7818) Regression: maven improperly exclude hamcrest-core from junit
Lenny Primak created MNG-7818:
-
Summary: 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
junit 4 has exclusions for hamcrest-core, which causes ClassNotFouncException
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] (MNG-7670) Upgrade misc dependencies
[
https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733837#comment-17733837
]
Lenny Primak commented on MNG-7670:
---
JUnit 4 still requires hamcrest-core 1.3
{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}
> Upgrade misc dependencies
> -
>
> Key: MNG-7670
> URL: https://issues.apache.org/jira/browse/MNG-7670
> Project: Maven
> Issue Type: Dependency upgrade
> Components: Dependencies
>Reporter: Sylwester Lachiewicz
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.9.2
>
>
> [INFO] The following dependencies in Dependency Management have newer
> versions:
> [INFO] com.google.guava:guava .. 30.1-jre -> 31.1-jre
> [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> 3.12.0
> [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> 2.7.0
> -[INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 ->
> 2.1.1-
> -[INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 ->
> 3.5.1-
> [INFO] org.hamcrest:hamcrest-core 1.3 -> 2.2
> [INFO] org.hamcrest:hamcrest-library . 1.3 -> 2.2
> [INFO] org.mockito:mockito-core 2.21.0 -> 4.11.0
> [INFO] org.powermock:powermock-reflect ... 1.7.4 -> 2.0.9
> [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> 2.9.1
> [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> 2.9.1
>
[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=17733818#comment-17733818 ] ASF GitHub Bot commented on MSHARED-1215: - elharo opened a new pull request, #157: URL: https://github.com/apache/maven-shared-utils/pull/157 … and is badly out of date. Also separates implementation and history details from API doc. > 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)
[GitHub] [maven-shared-utils] elharo opened a new pull request, #157: [MSHARED-1215] deprecate Os class that hasn't been maintained for over a decade
elharo opened a new pull request, #157: URL: https://github.com/apache/maven-shared-utils/pull/157 … and is badly out of date. Also separates implementation and history details from API doc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (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 reassigned MSHARED-1215: -- Assignee: Elliotte Rusty Harold > 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-1271) deprecate fileutils
[ https://issues.apache.org/jira/browse/MSHARED-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733816#comment-17733816 ] ASF GitHub Bot commented on MSHARED-1271: - elharo opened a new pull request, #156: URL: https://github.com/apache/maven-shared-utils/pull/156 (no comment) > 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 opened a new pull request, #156: [MSHARED-1271] deprecate forceMkdir since a close replacement exists in Commons IO
elharo opened a new pull request, #156: URL: https://github.com/apache/maven-shared-utils/pull/156 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1271) deprecate fileutils
[ https://issues.apache.org/jira/browse/MSHARED-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733815#comment-17733815 ] ASF GitHub Bot commented on MSHARED-1271: - elharo merged PR #155: URL: https://github.com/apache/maven-shared-utils/pull/155 > 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 #155: [MSHARED-1271] deprecate contentEquals method that also exists in Apache Commons
elharo merged PR #155: URL: https://github.com/apache/maven-shared-utils/pull/155 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MSHARED-1261) CommandLine Cloneable or not
[ https://issues.apache.org/jira/browse/MSHARED-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHARED-1261: --- Description: The CommandLine class declares that it implements Cloneable. Yet its clone method always throws a RuntimeException, not even a CloneNotSupportedException. Why? Either remove the interface or make it Cloneable. was: The CommandLine class declares that it implements Cloneable. Yet it's clone method always throws a RuntimeException, not even a CloneNotSupportedException. Why? Either remove the interface or make it Cloneable. > CommandLine Cloneable or not > > > Key: MSHARED-1261 > URL: https://issues.apache.org/jira/browse/MSHARED-1261 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Minor > > The CommandLine class declares that it implements Cloneable. Yet its clone > method always throws a RuntimeException, not even a > CloneNotSupportedException. Why? > Either remove the interface or make it Cloneable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1255) Do something about Hamcrest
[ https://issues.apache.org/jira/browse/MSHARED-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1255. -- > Do something about Hamcrest > --- > > Key: MSHARED-1255 > URL: https://issues.apache.org/jira/browse/MSHARED-1255 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Currently there's a weird situation with Hamcrest deps that the dependency > analyzer doesn't truly grok and which leads to false positive warnings like: > [WARNING] Unused declared dependencies found: > [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test > This happens in maven-shared-utils for intance. > This is a result of moving classes between artifacts from version 1 to 2, and > appears when JUnit 4 is used and thus an older version of hamcrest-core gets > pulled in unless the empty org.hamcrest:hamcrest-core:jar:2.2 is added: > https://hamcrest.org/JavaHamcrest/distributables > Options: > 1. special case this one > 2. Notice when a dependency appears unused but does upgrade a version lower > in the tree > 3. use dependency management instead to upgrade hamcrest-core? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MSHARED-1255) Do something about Hamcrest
[ https://issues.apache.org/jira/browse/MSHARED-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1255. Resolution: Fixed > Do something about Hamcrest > --- > > Key: MSHARED-1255 > URL: https://issues.apache.org/jira/browse/MSHARED-1255 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-analyzer, maven-shared-utils >Reporter: Elliotte Rusty Harold >Priority: Major > > Currently there's a weird situation with Hamcrest deps that the dependency > analyzer doesn't truly grok and which leads to false positive warnings like: > [WARNING] Unused declared dependencies found: > [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test > This happens in maven-shared-utils for intance. > This is a result of moving classes between artifacts from version 1 to 2, and > appears when JUnit 4 is used and thus an older version of hamcrest-core gets > pulled in unless the empty org.hamcrest:hamcrest-core:jar:2.2 is added: > https://hamcrest.org/JavaHamcrest/distributables > Options: > 1. special case this one > 2. Notice when a dependency appears unused but does upgrade a version lower > in the tree > 3. use dependency management instead to upgrade hamcrest-core? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHARED-1269. -- > 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] [Resolved] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHARED-1269. Resolution: Won't Do > 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] [Commented] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733799#comment-17733799 ] ASF GitHub Bot commented on MSHARED-1269: - elharo closed pull request #154: [MSHARED-1269] Deprecate maven-shared-utils URL: https://github.com/apache/maven-shared-utils/pull/154 > 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] [Commented] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733798#comment-17733798 ] ASF GitHub Bot commented on MSHARED-1269: - elharo commented on PR #154: URL: https://github.com/apache/maven-shared-utils/pull/154#issuecomment-1595827363 The more I look at this the more places I find where these two have diverged. E.g. plexus-utils does not seem to have any equivalent of org.apache.maven.shared.utils.logging. Even after a package rename it's not a drop-in replacement. I don't think this proposal is feasible. > 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)
[GitHub] [maven-shared-utils] elharo closed pull request #154: [MSHARED-1269] Deprecate maven-shared-utils
elharo closed pull request #154: [MSHARED-1269] Deprecate maven-shared-utils URL: https://github.com/apache/maven-shared-utils/pull/154 -- 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-989) Undeprecate DirectoryScanner and MatchPattern(s)
[
https://issues.apache.org/jira/browse/MSHARED-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733797#comment-17733797
]
Elliotte Rusty Harold commented on MSHARED-989:
---
Ant-style globs for includes/excludes would be added by
DirectoryStream.Filter. There's an argument to be made that what we really want
here is an implementation of DirectoryStream.Filter that supports includes and
excludes and prrhaps DEFAULTEXCLUDES. Maven specific filtering no longer
requires implementing our own error prone, platform-cautious file tree walking.
Leave that effort to the projects that specialize in understanding the
idiosyncrasies of various file systems.
> Undeprecate DirectoryScanner and MatchPattern(s)
>
>
> Key: MSHARED-989
> URL: https://issues.apache.org/jira/browse/MSHARED-989
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.4
>Reporter: Konrad Windszus
>Priority: Major
>
> In MSHARED-898 {{DirectoryScanner}} has been deprecated. Instead using the
> {{java.nio.file.DirectoryStream}} is now recommended.
> The latter is often no replacement as the parametrization of DirectoryScanner
> with Ant-style globs for includes/excludes is not supported. Also the
> {{DEFAULTEXCLUDES}} are not part of Java NIO {{DirectoryStream}} either.
> The same applies to {{MatchPatterns}}, which is deprecated and now recommends
> using {{java.nio.filejava.nio.file.DirectoryStream.Filter}}. Please
> instead provide a Filter for Java NIO for those patterns (regex and ant) and
> make {{DirectoryScanner}} use File NIO internally while keeping API
> compatibility.
> Otherwise every consumer of DirectoryScanner needs to come up with a custom
> implementation of pattern matching and a lot of glue code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-compiler-plugin] ebourg commented on pull request #193: [MCOMPILER-397] Use relative paths in jpms.args to make the builds reproducible
ebourg commented on PR #193: URL: https://github.com/apache/maven-compiler-plugin/pull/193#issuecomment-1595767468 This is incomplete, the path separators have to be normalized too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733771#comment-17733771
]
ASF GitHub Bot commented on MCOMPILER-397:
--
ebourg commented on PR #193:
URL:
https://github.com/apache/maven-compiler-plugin/pull/193#issuecomment-1595767468
This is incomplete, the path separators have to be normalized too.
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
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=17733763#comment-17733763 ] Romain Manni-Bucau commented on MNG-7808: - [~hboutemy] do you know a lot of archetypes not triggering these warnings? Most will do and as an archetype writer you do *not* want to put versions there but just override what maven provides OOTB to limit the maintainance (it is how maven was designed after all). So yes, we shouted in our foot. You are right about 3.8.8 and 3.9.3, this is an intended instability by design and assume you pin the version with 3.8.8, you don't know if it will work with 3.9.3 so you didn't get anything pinning, you just ensure it will not work faster cause plugins tends to be more stable accross versions when doing upgrades than pinning versions which can have internal breakages. 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. > 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] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733760#comment-17733760
]
Emmanuel Bourg commented on MCOMPILER-397:
--
I've opened a PR with the patch currently applied to maven-compiler-plugin in
Debian.
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733759#comment-17733759
]
ASF GitHub Bot commented on MCOMPILER-397:
--
ebourg opened a new pull request, #193:
URL: https://github.com/apache/maven-compiler-plugin/pull/193
PR for https://issues.apache.org/jira/browse/MCOMPILER-397
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-397) Use relative paths in jpms.args to make the builds reproducible
[
https://issues.apache.org/jira/browse/MCOMPILER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733758#comment-17733758
]
Emmanuel Bourg commented on MCOMPILER-397:
--
> I understand the request, but if we change it, then the solution should be
> usable at runtime as well
I'm not sure to understand, how an absolute path from the developer computer
building the artifact could have any impact at runtime on someone else system?
> Use relative paths in jpms.args to make the builds reproducible
> ---
>
> Key: MCOMPILER-397
> URL: https://issues.apache.org/jira/browse/MCOMPILER-397
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Emmanuel Bourg
>Priority: Major
> Labels: reproducibility
>
> The {{jpms.args}} file generated since the version 3.7 contains absolute
> paths, for example here is the file generated for jaxb-core:
> {code}
> --add-modules
> java.xml.bind
> --upgrade-module-path
> /home/ebourg/jaxb/jaxb-ri/core/target/endorsed
> {code}
> The absolute path affects the reproducibility of the builds. Someone else
> rebuilding the project is unlikely to have the same base path and will not
> get a byte identical artifact. I suggest using a relative path instead
> (starting at the root of the project or at the root of the module) and
> normalizing the path separators (such that builds on Windows and Unix
> generate the same file).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1271) deprecate fileutils
Elliotte Rusty Harold created MSHARED-1271: -- Summary: 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 Seems all the methods have replacements in apache commons -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1271) deprecate fileutils
[ https://issues.apache.org/jira/browse/MSHARED-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MSHARED-1271: -- Assignee: Elliotte Rusty Harold > 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)
[jira] [Commented] (MSTAGE-25) Modernize IO
[ https://issues.apache.org/jira/browse/MSTAGE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733745#comment-17733745 ] ASF GitHub Bot commented on MSTAGE-25: -- elharo opened a new pull request, #13: URL: https://github.com/apache/maven-stage-plugin/pull/13 (no comment) > Modernize IO > - > > Key: MSTAGE-25 > URL: https://issues.apache.org/jira/browse/MSTAGE-25 > Project: Maven Stage Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.0 > > > # Use try with resources to make sure everything's closed and we don't leak > # Don't use PrintWriter since it swallows exceptions > # Prefer Apache Commons IO over Plexus IO -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-stage-plugin] elharo opened a new pull request, #13: [MSTAGE-25] use Apache Commons IO instead of Plexus
elharo opened a new pull request, #13: URL: https://github.com/apache/maven-stage-plugin/pull/13 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (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=17733742#comment-17733742
]
Michael Osipov commented on DOXIASITETOOLS-174:
---
This is straight forward, but must be done together wie DOXIASITETOOLS-254 to
touch the model once. The other question, what to do with old models? Should be
convert them on the fly or simply reject and request a one time rewrite by the
developer?
> 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] (MSITE-833) Remove dependency to maven-compat
[
https://issues.apache.org/jira/browse/MSITE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733741#comment-17733741
]
ASF GitHub Bot commented on MSITE-833:
--
elharo commented on code in PR #155:
URL: https://github.com/apache/maven-site-plugin/pull/155#discussion_r1232855063
##
src/test/java/org/apache/maven/plugins/site/deploy/SiteDeployMojoTest.java:
##
@@ -30,14 +30,14 @@
*/
@RunWith(JUnit4.class)
public class SiteDeployMojoTest extends AbstractMojoTestCase {
-private WagonManager wagonManager;
+private Wagon wagon;
// private Repository repository;
@Before
public void setUp() throws Exception {
super.setUp();
-wagonManager = getContainer().lookup(WagonManager.class);
+// wagon = getContainer().lookup( Wagon.class, "scp" );
// repository = new Repository( "my-repository",
"scp://repository-host/var/maven2" );
Review Comment:
I respectfully disagree. I would rather see nine wrong things and one right
thing than ten wrong things. It is not a good idea to be consistent with
existing bad practice, and you do not have to fix all bad code practices to fix
one thing.
This applies to everything, and in this specific case, commented out code
should not be left in the repo.
> Remove dependency to maven-compat
> -
>
> Key: MSITE-833
> URL: https://issues.apache.org/jira/browse/MSITE-833
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: Maven 3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0-M9
>
>
> # Remove usages of the maven-compat classes:
> ## org.apache.maven.artifact.manager.WagonManager
> ## org.apache.maven.artifact.repository.ArtifactRepositoryFactory
> # Move maven-compat scope to test
> [https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site-plugin] elharo commented on a diff in pull request #155: [MSITE-833] Remove dependency to maven-compat
elharo commented on code in PR #155:
URL: https://github.com/apache/maven-site-plugin/pull/155#discussion_r1232855063
##
src/test/java/org/apache/maven/plugins/site/deploy/SiteDeployMojoTest.java:
##
@@ -30,14 +30,14 @@
*/
@RunWith(JUnit4.class)
public class SiteDeployMojoTest extends AbstractMojoTestCase {
-private WagonManager wagonManager;
+private Wagon wagon;
// private Repository repository;
@Before
public void setUp() throws Exception {
super.setUp();
-wagonManager = getContainer().lookup(WagonManager.class);
+// wagon = getContainer().lookup( Wagon.class, "scp" );
// repository = new Repository( "my-repository",
"scp://repository-host/var/maven2" );
Review Comment:
I respectfully disagree. I would rather see nine wrong things and one right
thing than ten wrong things. It is not a good idea to be consistent with
existing bad practice, and you do not have to fix all bad code practices to fix
one thing.
This applies to everything, and in this specific case, commented out code
should not be left in the repo.
--
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] (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=17733740#comment-17733740
]
Michael Osipov commented on DOXIASITETOOLS-254:
---
I believe that changes here will require some model changes. We need to set up
a call to discuss all aspects anything else won't work.
> 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] [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
]
Michael Osipov updated DOXIASITETOOLS-254:
--
Description:
[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?
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?
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:
> * 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)
[GitHub] [maven-build-cache-extension] elharo commented on pull request #86: [MBUILDCACHE-60] Remove undeclared Guava dependency with Arrays.asList
elharo commented on PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#issuecomment-1595703835 I can't agree with that. Code review is essential. If it's that trivial, then it's an easy review. If it isn't, it needs review all the more. I've certainly noticed more than one mistake in Maven when code review was skipped, both by myself and others. -- 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] (MBUILDCACHE-60) Remove Guava dependency
[ https://issues.apache.org/jira/browse/MBUILDCACHE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733737#comment-17733737 ] ASF GitHub Bot commented on MBUILDCACHE-60: --- elharo commented on PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#issuecomment-1595703835 I can't agree with that. Code review is essential. If it's that trivial, then it's an easy review. If it isn't, it needs review all the more. I've certainly noticed more than one mistake in Maven when code review was skipped, both by myself and others. > Remove Guava dependency > --- > > Key: MBUILDCACHE-60 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-60 > Project: Maven Build Cache Extension > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Labels: pull-request-available > -- 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
]
Michael Osipov updated DOXIASITETOOLS-254:
--
Summary: Clarify inconsistencies in Doxia site model (was: Clarify
inconsistencies in site decoration model)
> 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?
> 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-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=17733735#comment-17733735
]
Michael Osipov commented on MSHARED-1032:
-
[~bmarwell], looking again at this before GA: Regardless of the exception you
need {{canGenerateReport()}} should not be called twice since it may contain
expensive calls. I'd say that we first need to solve the double call before
this can be discussed. WDYT?
> 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] [Comment Edited] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733734#comment-17733734 ] Elliotte Rusty Harold edited comment on MSHARED-1269 at 6/17/23 10:31 AM: -- This is not a can of worms I want to reopen. The decision to move off plexus was already made. Let's stick with it rather than swapping back and forth every couple of years. A lot of progress has been made in maven-shared-utils that is not reflected in plexus-utils, and many dependencies have already been moved to maven-shared-utils, even if the job is not yet done. I do not want to spend yet more time backporting all that work into plexus. Perhaps most importantly plexus is in a weird half-supported state with no clear ownership or governance. It is not an Apache project. Codehaus is defunct. It is not the way forward. was (Author: elharo): This is not a can of worms I want to reopen. The decision to move off plexus was already made. Let's stick with it rather than swapping back and forth every couple of years. A lot of progress has been made in maven-shared-utils that is not reflected in plexus-utils, and many dependencies have already been moved to maven-shared-utils, even if the job is not yet done. Perhaps most importantly plexus is in a weird half-supported state with no clear ownership or governance. It is not an Apache project. Codehaus is defunct. It is not the way forward. > 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] [Commented] (MSHARED-1269) Deprecate maven-shared-utils
[ https://issues.apache.org/jira/browse/MSHARED-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733734#comment-17733734 ] Elliotte Rusty Harold commented on MSHARED-1269: This is not a can of worms I want to reopen. The decision to move off plexus was already made. Let's stick with it rather than swapping back and forth every couple of years. A lot of progress has been made in maven-shared-utils that is not reflected in plexus-utils, and many dependencies have already been moved to maven-shared-utils, even if the job is not yet done. Perhaps most importantly plexus is in a weird half-supported state with no clear ownership or governance. It is not an Apache project. Codehaus is defunct. It is not the way forward. > 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] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-1032:
Description:
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!
was:
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 {{canGenerateReports()}}
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
> 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-193) No checked exceptions for rendering
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733733#comment-17733733 ] Michael Osipov commented on MSHARED-193: [~hboutemy], after touching all of our renders and looking again at this, I think this should be closed as wontfix and I will explain why: 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. Done. See [here|https://github.com/apache/maven-invoker-plugin/commit/a154e5b13dd7d900829d1d951efff50c41f25738] for a good example. Let me know what you think! > 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] (MSITE-833) Remove dependency to maven-compat
[
https://issues.apache.org/jira/browse/MSITE-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733730#comment-17733730
]
ASF GitHub Bot commented on MSITE-833:
--
michael-o commented on code in PR #155:
URL: https://github.com/apache/maven-site-plugin/pull/155#discussion_r1233017160
##
src/test/java/org/apache/maven/plugins/site/deploy/SiteDeployMojoTest.java:
##
@@ -30,14 +30,14 @@
*/
@RunWith(JUnit4.class)
public class SiteDeployMojoTest extends AbstractMojoTestCase {
-private WagonManager wagonManager;
+private Wagon wagon;
// private Repository repository;
@Before
public void setUp() throws Exception {
super.setUp();
-wagonManager = getContainer().lookup(WagonManager.class);
+// wagon = getContainer().lookup( Wagon.class, "scp" );
// repository = new Repository( "my-repository",
"scp://repository-host/var/maven2" );
Review Comment:
@elharo, please create a followup PR if you want something removed.
> Remove dependency to maven-compat
> -
>
> Key: MSITE-833
> URL: https://issues.apache.org/jira/browse/MSITE-833
> Project: Maven Site Plugin
> Issue Type: Improvement
> Components: Maven 3
>Reporter: Sylwester Lachiewicz
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0-M9
>
>
> # Remove usages of the maven-compat classes:
> ## org.apache.maven.artifact.manager.WagonManager
> ## org.apache.maven.artifact.repository.ArtifactRepositoryFactory
> # Move maven-compat scope to test
> [https://cwiki.apache.org/confluence/display/MAVEN/Plugin+migration+to+Maven3+dependencies]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site-plugin] michael-o commented on a diff in pull request #155: [MSITE-833] Remove dependency to maven-compat
michael-o commented on code in PR #155:
URL: https://github.com/apache/maven-site-plugin/pull/155#discussion_r1233017160
##
src/test/java/org/apache/maven/plugins/site/deploy/SiteDeployMojoTest.java:
##
@@ -30,14 +30,14 @@
*/
@RunWith(JUnit4.class)
public class SiteDeployMojoTest extends AbstractMojoTestCase {
-private WagonManager wagonManager;
+private Wagon wagon;
// private Repository repository;
@Before
public void setUp() throws Exception {
super.setUp();
-wagonManager = getContainer().lookup(WagonManager.class);
+// wagon = getContainer().lookup( Wagon.class, "scp" );
// repository = new Repository( "my-repository",
"scp://repository-host/var/maven2" );
Review Comment:
@elharo, please create a followup PR if you want something removed.
--
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] (SUREFIRE-2180) Surefire not invoking tests with TestNG DataProvider
[
https://issues.apache.org/jira/browse/SUREFIRE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733726#comment-17733726
]
Karl Heinz Marbaise commented on SUREFIRE-2180:
---
Please create a full working example otherwise it's impossible to help.. We
don't know which version of surefire/failsafe plugin you are using, how your
pom file looks like etc. also the code of the test is not includes...
> Surefire not invoking tests with TestNG DataProvider
>
>
> Key: SUREFIRE-2180
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2180
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.1.2
>Reporter: Javier A. Ortiz
>Priority: Major
>
> I'm having a weird issue I can't figure out. It's driving me insane.
> I have a Maven project for which I'm running the same command both locally
> and on Jenkins. The environment is the same as far as I can tell:
> - Maven 3.9.2 (On Jenkins: Docker image maven:3.9.2-eclipse-temurin-11)
> - JDK 11 (On Jenkins: Docker image maven:3.9.2-eclipse-temurin-11)
> - TestNG 7.8.0
> Command:
> {code:java}
> mvn -Ddependency.surefire.verbose=10 -Pcoverage verify -B -U -Dgroup=PLATFORM
> {code}
> Relevant POM section:
> {code:java}
>
>
>
>
> org.jacoco
> jacoco-maven-plugin
> 0.8.10
>
> ...
>
>
> ...
>
> ...
>
>
> coverage
>
>
>
> org.jacoco
> jacoco-maven-plugin
>
>
> com/XXX/framework/dataproviders/**/*
> com/XXX/v2/basetest/**/*
> **/*Exception*
>
>
>
>
>
> prepare-agent
>
>
>
>
> report
> test
>
> report
>
>
>
>
> jacoco-check
>
> check
>
>
>
>
> BUNDLE
>
>
> INSTRUCTION
> COVEREDRATIO
> 60%
>
>
> CLASS
> MISSEDCOUNT
> 0
>
>
>
>
> PACKAGE
>
>
> LINE
> COVEREDRATIO
> 60%
>
>
>
>
> ${skipTests}
>
>
>
>
>
>
>
> {code}
> One of the tests that have the issue (only tests with DataProviders) show
> this pattern in the logs. Enabled verbose to level 10 in hopes that something
> would show up.
> Locally:
> {code:java}
> [2023-06-06 16:55:46.795] [INFO] [TestClass] Creating TestClass for
> [ClassImpl class=com.XXX.framework.utils.TimeUtilsTest]
> [2023-06-06 16:55:46.796] [INFO] Method public java.lang.Object[][]
> com.XXX.framework.utils.TimeUtilsTest.getTimeData() has a @Test annotation
> but also a return value: ignoring it. Use
> to fix this
> [2023-06-06 16:55:46.797] [INFO] [TestClass] Adding method
> TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)[pri:0,
> instance:null] on TestClass class com.XXX.framework.utils.TimeUtilsTest
> {code}
> ...
> {code:java}
> [2023-06-06 16:55:47.316] [INFO] = Test class
> com.XXX.framework.utils.TimeUtilsTest
> [2023-06-06 16:55:47.316] [INFO] @Test
> TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)[pri:0,
> instance:com.XXX.framework.utils.TimeUtilsTest@283eb984]
> [2023-06-06 16:55:47.316] [INFO] ==
> {code}
> ...
> {code:java}
> [TestNG] INVOKING: "Surefire test" -
> com.XXX.framework.utils.TimeUtilsTest.testToFormattedString(java.util.concurrent.TimeUnit,int,java.lang.String,com.XXX.framework.annotations.TestNameParameter)(value(s):
> NANOSECONDS, 60, "60ns", TestNameParameter(customName=60 NANOSECONDS))
> {code}
> ...
> Test executes and results, etc.
> On Jenkins:
> {code:java}
> [2023-06-06 21:02:29.270] [INFO] [TestClass] Creating TestClass for
> [ClassImpl
[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=17733706#comment-17733706 ] Herve Boutemy edited comment on MNG-7808 at 6/17/23 7:13 AM: - I'm totally lost why archetype would be broken, or anything [~bmarwell] can you provide a reproducer project that triggers the warnings you are talking about, please? And copy/paste the unneeded warnings in the issue description? I can't even get any message currently that I'm sure existed in the past What I know is that given updates like MNG-7790 and MNG-7807, a project that does not define any plugin version (like with minimal pom.xml) will get different plugins versions when built with Maven 3.8.8 for example one month ago and in one month with Maven 3.9.3 (that includes MNG-7790 and MNG-7807) = what is called build instability, because it depends on the precise Maven 3 release used to run (then detailed bugs associated) = what I expect we are talking about and that has been reworked so much in the last 10 years that I'm lost about where we currently stand, then what may eventually remain to be realistically improved was (Author: hboutemy): I'm totally lost why archetype would be broken, or anything [~bmarwell] can you provide a reproducer project that triggers the warnings you are talking about, please? And copy/paste the unneeded warnings in the issue description? I can't even get any message currently that I'm sure existed in the past What I know is that given updates like MNG-7790 and MNG-7807, a project that does not define any plugin version (like with minimal pom.xml) will get different plugins versions when built with Maven 3.8.8 for example one month ago and in one month with Maven 3.9.3 (that includes MNG-7790 and MNG-7807) = what is called build instability, because it depends on the precise Maven 3 release used to run (then detailed bugs associated) = what I expect we are talking about > 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=17733706#comment-17733706 ] Herve Boutemy commented on MNG-7808: I'm totally lost why archetype would be broken, or anything [~bmarwell] can you provide a reproducer project that triggers the warnings you are talking about, please? And copy/paste the unneeded warnings in the issue description? I can't even get any message currently that I'm sure existed in the past What I know is that given updates like MNG-7790 and MNG-7807, a project that does not define any plugin version (like with minimal pom.xml) will get different plugins versions when built with Maven 3.8.8 for example one month ago and in one month with Maven 3.9.3 (that includes MNG-7790 and MNG-7807) = what is called build instability, because it depends on the precise Maven 3 release used to run (then detailed bugs associated) = what I expect we are talking about > 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] (MSHARED-193) No checked exceptions for rendering
[ https://issues.apache.org/jira/browse/MSHARED-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-193: -- Description: 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? was: It seems unfortunate that org.apache.maven.reporting.MavenReportRenderer.render() 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? > 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] (MSOURCES-137) umask makes artifacts generated by maven-source-plugin not easy to reproduce
[
https://issues.apache.org/jira/browse/MSOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSOURCES-137:
---
Summary: umask makes artifacts generated by maven-source-plugin not easy to
reproduce (was: umask makes artifacts generated by maven-source-plugin are not
easy to reproduce)
> umask makes artifacts generated by maven-source-plugin not easy to reproduce
>
>
> Key: MSOURCES-137
> URL: https://issues.apache.org/jira/browse/MSOURCES-137
> Project: Maven Source Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Andreas Veithen
>Priority: Minor
>
> It appears that inside the archive created by maven-source-plugin, the
> permissions of {{META-INF/maven/\*/\*/pom.properties}} depend on the current
> umask.
> Steps to reproduce:
> {code:java}
> $ umask 022
> $ mvn clean install
> $ umask 002
> $ mvn clean verify artifact:compare
> {code}
> This can be used on any project attaching a source jar (e.g.
> [https://github.com/apache/ws-axiom/]).
> Example diffoscope output:
> {code:java}
> --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │┄ Archive contents identical but files differ, possibly due to different
> compression levels. Falling back to binary comparison.
> ├── zipinfo {}
> │ @@ -14,9 +14,9 @@
> │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE
> │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/FactoryMethod.java
> │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Inject.java
> │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Mixin.java
> │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Singleton.java
> │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/WeavablePackage.java
> │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml
> │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8%
> │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │ @@ -676,15 +676,15 @@
> │ 2a30: a481 b020 4d45 5441 . ..META
> │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a
> │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons
> │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea
> │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/
> │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK...
> │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._
> │ -2aa0: 0052 00a4 ...R
> │ +2aa0: 0052 00b4 ...R
> │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma
> │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w
> │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/
> │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann
> │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro
> │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK...
> │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$
> {code}
> Note that although maven-jar-plugin adds the same {{pom.properties}} file to
> the archive, it isn't affected by this problem.
> I discovered this while trying to check the reproducibility of Apache Axiom
> builds in a Github Codespace, where file permissions are set in a peculiar
> way; see [https://github.com/orgs/community/discussions/26026].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
