[jira] [Commented] (MCOMPILER-446) Compiler is crashing while setting JPMS module version
[
https://issues.apache.org/jira/browse/MCOMPILER-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754365#comment-17754365
]
Bruno Medeiros commented on MCOMPILER-446:
--
Ticket was closed with:
> As described in the JIRA ticket, the maven-compiler-plugin should always use
> --module-version based on the project version.
Given it's in the original description that:
> Because we set versions in pom to local-SNAPHOT
This issue was never about setting a different version, it's was suggested as a
workaround, it was about `maven-compiler-plugin` crashing when a non-semver
version is being used.
> JDK-8250678 fixed with Java 18
This is an upstream issue, then? No fixes for Java 17 should be expected, right?
> Compiler is crashing while setting JPMS module version
> --
>
> Key: MCOMPILER-446
> URL: https://issues.apache.org/jira/browse/MCOMPILER-446
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Bruno Medeiros
>Assignee: Robert Scholte
>Priority: Major
>
> I have upgraded maven compiler plugin to 3.8.1 and I started getting this
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project common: Fatal error compiling: error: bad value
> for --module-version option: 'local-SNAPSHOT' -> [Help 1]{code}
> Because we set versions in pom to local-SNAPHOT (and use maven-version-plugin
> when we actually realease to set a proper version), all our builds are
> failing locally.
> It seems javac does not like versions that do not have just alpha characters,
> like ours local-SNAPHOT.
> I thought about a few ways to fix that:
> * Allow the use of --module-version to be optional through config
> * Allow the version itself to be configurable
> * Validate if the version is a valid version for --module-version and not
> set it in case it is not
> Let me know what you guys think, I can try to provide a PR with the given
> solution.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-765) Make build pass with Java 20
[ https://issues.apache.org/jira/browse/MJAVADOC-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754357#comment-17754357 ] ASF GitHub Bot commented on MJAVADOC-765: - olamy commented on code in PR #223: URL: https://github.com/apache/maven-javadoc-plugin/pull/223#discussion_r1294095941 ## .github/workflows/maven.yml: ## @@ -26,5 +26,10 @@ jobs: name: Verify uses: apache/maven-gh-actions-shared/.github/workflows/maven-verify.yml@v3 with: + jdk-matrix: '[ "20", "17", "8" ]' + ff-jdk: '20' Review Comment: next LTS will be 21. Should we really care of the intermediary 20? > Make build pass with Java 20 > > > Key: MJAVADOC-765 > URL: https://issues.apache.org/jira/browse/MJAVADOC-765 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.5.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] olamy commented on a diff in pull request #223: [MJAVADOC-765] Fix build with Java 20
olamy commented on code in PR #223: URL: https://github.com/apache/maven-javadoc-plugin/pull/223#discussion_r1294095941 ## .github/workflows/maven.yml: ## @@ -26,5 +26,10 @@ jobs: name: Verify uses: apache/maven-gh-actions-shared/.github/workflows/maven-verify.yml@v3 with: + jdk-matrix: '[ "20", "17", "8" ]' + ff-jdk: '20' Review Comment: next LTS will be 21. Should we really care of the intermediary 20? -- 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] (MGPG-99) Passcode byte array provided to gpg executable on stdin is not terminated
Niels Bertram created MGPG-99: - Summary: Passcode byte array provided to gpg executable on stdin is not terminated Key: MGPG-99 URL: https://issues.apache.org/jira/browse/MGPG-99 Project: Maven GPG Plugin Issue Type: Bug Affects Versions: 3.1.0 Reporter: Niels Bertram Attachments: image-2023-08-15-10-40-10-637.png We ran into a strange issue using the maven-gpg-plugin with gnu gpg 2.3.7. The 2.x versions of gpg prefer to take the passcode for the signing key via stdin and the maven-gpg-plugin does setup the signing process accordingly with the `--passphrase-fd 0` [argument|https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L102] provided to the command process. On [Line 106|https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L106] the passcode is written to as bytes to the input stream that is then provided in [Line 173|https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L173] to the gpg process. Unfortunately it appears that gpg requires a `CR` or `LF` to recognise that the passcode is provided as arg 0 on stdin. In our case it does not and the process fails with following error: `gpg: signing failed: No pinentry` . The use of the loopback pinentry device is properly configured by the plugin but the hint for us was that the gpg executable did not know there was any input on stdin. After some experimentation, we found that appending a `CR` character to the passcode will trigger the stdin to provide the passcode to the program. This "fix" looks like this in the `settings.xml` file. !image-2023-08-15-10-40-10-637.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[ https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MJAVADOC-763. -- > JavadocReportTest.testExceptions is broken > -- > > Key: MJAVADOC-763 > URL: https://issues.apache.org/jira/browse/MJAVADOC-763 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The Mojo lookup fails. This is hidden by bad exception handling in the test > that catches too broad an exception type. > [ERROR] Errors: > [ERROR] > JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426 > » ComponentConfiguration Cannot load implementation hint > 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[ https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MJAVADOC-763. Resolution: Fixed > JavadocReportTest.testExceptions is broken > -- > > Key: MJAVADOC-763 > URL: https://issues.apache.org/jira/browse/MJAVADOC-763 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The Mojo lookup fails. This is hidden by bad exception handling in the test > that catches too broad an exception type. > [ERROR] Errors: > [ERROR] > JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426 > » ComponentConfiguration Cannot load implementation hint > 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[ https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754341#comment-17754341 ] ASF GitHub Bot commented on MJAVADOC-763: - elharo merged PR #219: URL: https://github.com/apache/maven-javadoc-plugin/pull/219 > JavadocReportTest.testExceptions is broken > -- > > Key: MJAVADOC-763 > URL: https://issues.apache.org/jira/browse/MJAVADOC-763 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > The Mojo lookup fails. This is hidden by bad exception handling in the test > that catches too broad an exception type. > [ERROR] Errors: > [ERROR] > JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426 > » ComponentConfiguration Cannot load implementation hint > 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo merged pull request #219: [MJAVADOC-763] remove test that doesn't test what it claims
elharo merged PR #219: URL: https://github.com/apache/maven-javadoc-plugin/pull/219 -- 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] (MJAVADOC-765) Make build pass with Java 20
[ https://issues.apache.org/jira/browse/MJAVADOC-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754262#comment-17754262 ] ASF GitHub Bot commented on MJAVADOC-765: - slachiewicz opened a new pull request, #223: URL: https://github.com/apache/maven-javadoc-plugin/pull/223 (no comment) > Make build pass with Java 20 > > > Key: MJAVADOC-765 > URL: https://issues.apache.org/jira/browse/MJAVADOC-765 > Project: Maven Javadoc Plugin > Issue Type: Task >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.5.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-gh-actions-shared] slachiewicz opened a new pull request, #77: Maven 3.9.4 as default
slachiewicz opened a new pull request, #77: URL: https://github.com/apache/maven-gh-actions-shared/pull/77 (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
[GitHub] [maven-gh-actions-shared] slachiewicz opened a new pull request, #76: Bump maven-parent to 39
slachiewicz opened a new pull request, #76: URL: https://github.com/apache/maven-gh-actions-shared/pull/76 (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] (MJAVADOC-765) Make build pass with Java 20
Sylwester Lachiewicz created MJAVADOC-765: - Summary: Make build pass with Java 20 Key: MJAVADOC-765 URL: https://issues.apache.org/jira/browse/MJAVADOC-765 Project: Maven Javadoc Plugin Issue Type: Task Reporter: Sylwester Lachiewicz Assignee: Sylwester Lachiewicz Fix For: 3.5.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[
https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754256#comment-17754256
]
ASF GitHub Bot commented on MJAVADOC-763:
-
slachiewicz commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293952178
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
ExceptionTestMavenProjectStub project class is missing. agree was bad from
start
> JavadocReportTest.testExceptions is broken
> --
>
> Key: MJAVADOC-763
> URL: https://issues.apache.org/jira/browse/MJAVADOC-763
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> The Mojo lookup fails. This is hidden by bad exception handling in the test
> that catches too broad an exception type.
> [ERROR] Errors:
> [ERROR]
> JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426
> » ComponentConfiguration Cannot load implementation hint
> 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] slachiewicz commented on a diff in pull request #219: [MJAVADOC-763] remove test that doesn't test what it claims
slachiewicz commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293952178
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
ExceptionTestMavenProjectStub project class is missing. agree was bad from
start
--
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] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[
https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754235#comment-17754235
]
ASF GitHub Bot commented on MJAVADOC-763:
-
elharo commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293875949
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
No, the execute method is never invoked. The lookupMojo method fails because
the mojo was poorly written. It's been months since I wrote this, so I'm not
sure if the test case was always broken or the code itself, but this is trying
to test line 604 but instead the exception is thrown before we get there. The
test fails if you catch MojoExecutionException instead of Exception.
> JavadocReportTest.testExceptions is broken
> --
>
> Key: MJAVADOC-763
> URL: https://issues.apache.org/jira/browse/MJAVADOC-763
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> The Mojo lookup fails. This is hidden by bad exception handling in the test
> that catches too broad an exception type.
> [ERROR] Errors:
> [ERROR]
> JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426
> » ComponentConfiguration Cannot load implementation hint
> 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] elharo commented on a diff in pull request #219: [MJAVADOC-763] remove test that doesn't test what it claims
elharo commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293875949
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
No, the execute method is never invoked. The lookupMojo method fails because
the mojo was poorly written. It's been months since I wrote this, so I'm not
sure if the test case was always broken or the code itself, but this is trying
to test line 604 but instead the exception is thrown before we get there. The
test fails if you catch MojoExecutionException instead of Exception.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MRESOLVER-396) Native resolver should retry on http 429
[ https://issues.apache.org/jira/browse/MRESOLVER-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-396: -- Fix Version/s: 1.9.16 > Native resolver should retry on http 429 > > > Key: MRESOLVER-396 > URL: https://issues.apache.org/jira/browse/MRESOLVER-396 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Chris Eldredge >Priority: Minor > Fix For: 1.9.16 > > > The Wagon http transport provider has custom logic to retry with exponential > backoff when putting an artifact to an http endpoint and getting a 429 Too > Many Requests response code from the server: > [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] > The newer "native" http transporter should provide similar retry logic. One > place this could go would be into > [HttpTransporter.implPut|[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427].|https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] > Ideally the transport could be configured to retry on specific error codes, > perhaps with 429 and 503 being defaults. > The lack of retry support on 429s is exacerbate in Maven 3.9 because it > enables parallel put by default, which increases requests per second making > it more likely that a client would encounter rate limiting or other > throttling and overload scenarios. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754210#comment-17754210 ] ASF GitHub Bot commented on MCOMPILER-542: -- hboutemy commented on PR #197: URL: https://github.com/apache/maven-compiler-plugin/pull/197#issuecomment-1677828280 help wanted for patching module-info.class with asm, please... > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > > as seen in MJAR-275, JDK patch version in module-info.class is not included > only when building with a newer JDK release using "--release" flag, see > https://github.com/jvm-repo-rebuild/module-info > we need an issue in JDK to get a proper fix > and waiting for. that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define were is the best place -- > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754209#comment-17754209 ] ASF GitHub Bot commented on MCOMPILER-542: -- hboutemy opened a new pull request, #197: URL: https://github.com/apache/maven-compiler-plugin/pull/197 first draft just contains an IT that checks the issue after that, it's time to work on a fix... > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > > as seen in MJAR-275, JDK patch version in module-info.class is not included > only when building with a newer JDK release using "--release" flag, see > https://github.com/jvm-repo-rebuild/module-info > we need an issue in JDK to get a proper fix > and waiting for. that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define were is the best place -- > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-396) Native resolver should retry on http 429
[ https://issues.apache.org/jira/browse/MRESOLVER-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754200#comment-17754200 ] Michael Osipov commented on MRESOLVER-396: -- Sigh, we are truly reinventing the wheel and putting effort into something which has been already developed...what a waste of resources! > Native resolver should retry on http 429 > > > Key: MRESOLVER-396 > URL: https://issues.apache.org/jira/browse/MRESOLVER-396 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Chris Eldredge >Priority: Minor > > The Wagon http transport provider has custom logic to retry with exponential > backoff when putting an artifact to an http endpoint and getting a 429 Too > Many Requests response code from the server: > [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] > The newer "native" http transporter should provide similar retry logic. One > place this could go would be into > [HttpTransporter.implPut|[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427].|https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] > Ideally the transport could be configured to retry on specific error codes, > perhaps with 429 and 503 being defaults. > The lack of retry support on 429s is exacerbate in Maven 3.9 because it > enables parallel put by default, which increases requests per second making > it more likely that a client would encounter rate limiting or other > throttling and overload scenarios. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (MRELEASE-1135) Mistake JIRA
[ https://issues.apache.org/jira/browse/MRELEASE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted MRELEASE-1135: - > Mistake JIRA > > > Key: MRELEASE-1135 > URL: https://issues.apache.org/jira/browse/MRELEASE-1135 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Matt Pavlovich >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754171#comment-17754171
]
Herve Boutemy commented on MJAR-275:
MJAR-295 moved to MCOMPILER-542 as it is a better place to patch
module-info.class
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating
> reproducible builds per this guide:
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However,
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not
> {{project.build.outputTimestamp}}. I was able to identify the problem using
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I
> determined the timestamp across 2 builds was constant for all but the
> module-info.class:
>
> {code:java}
> -rw 2.0 fat 862 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw 2.0 fat 74 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17
> October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439]
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy moved MJAR-295 to MCOMPILER-542: -- Key: MCOMPILER-542 (was: MJAR-295) Affects Version/s: 3.11.0 (was: 3.3.0) Project: Maven Compiler Plugin (was: Maven JAR Plugin) > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > > as seen in MJAR-275, JDK patch version in module-info.class is not included > only when building with a newer JDK release using "--release" flag, see > https://github.com/jvm-repo-rebuild/module-info > we need an issue in JDK to get a proper fix > and waiting for. that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define were is the best place -- > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRELEASE-1135) Fix console regression when listing consumers on a queue
[
https://issues.apache.org/jira/browse/MRELEASE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Pavlovich updated MRELEASE-1135:
-
Description: (was: n org.apache.activemq.web.BrokerFacadeSupport
@Override
@SuppressWarnings("unchecked")
public Collection getQueueConsumers(String
queueName) throws Exception {
String brokerName = getBrokerName();
queueName = StringUtils.replace(queueName, "\"", "_");
ObjectName query = new
ObjectName("org.apache.activemq:type=Broker,brokerName=\"" + brokerName
+ "\",destinationType=Queue,destinationName=\"" + queueName +
"\",endpoint=Consumer,*");
Set queryResult = queryNames(query, null);
return getManagedObjects(queryResult.toArray(new
ObjectName[queryResult.size()]), SubscriptionViewMBean.class);
}
these quotes are redundant,when i delete these quotes,and replace this class
file to activemq-web-5.16.6.jar and restart active mq . the the consumer list
appears. )
> Fix console regression when listing consumers on a queue
>
>
> Key: MRELEASE-1135
> URL: https://issues.apache.org/jira/browse/MRELEASE-1135
> Project: Maven Release Plugin
> Issue Type: Bug
>Reporter: Matt Pavlovich
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRELEASE-1135) Mistake JIRA
[ https://issues.apache.org/jira/browse/MRELEASE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Pavlovich updated MRELEASE-1135: - Summary: Mistake JIRA (was: Fix console regression when listing consumers on a queue) > Mistake JIRA > > > Key: MRELEASE-1135 > URL: https://issues.apache.org/jira/browse/MRELEASE-1135 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Matt Pavlovich >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1135) Mistake JIRA
[ https://issues.apache.org/jira/browse/MRELEASE-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754152#comment-17754152 ] Matt Pavlovich commented on MRELEASE-1135: -- Please delete this JIRA! > Mistake JIRA > > > Key: MRELEASE-1135 > URL: https://issues.apache.org/jira/browse/MRELEASE-1135 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Matt Pavlovich >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1135) Fix console regression when listing consumers on a queue
Matt Pavlovich created MRELEASE-1135:
Summary: Fix console regression when listing consumers on a queue
Key: MRELEASE-1135
URL: https://issues.apache.org/jira/browse/MRELEASE-1135
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Matt Pavlovich
n org.apache.activemq.web.BrokerFacadeSupport
@Override
@SuppressWarnings("unchecked")
public Collection getQueueConsumers(String
queueName) throws Exception {
String brokerName = getBrokerName();
queueName = StringUtils.replace(queueName, "\"", "_");
ObjectName query = new
ObjectName("org.apache.activemq:type=Broker,brokerName=\"" + brokerName
+ "\",destinationType=Queue,destinationName=\"" + queueName +
"\",endpoint=Consumer,*");
Set queryResult = queryNames(query, null);
return getManagedObjects(queryResult.toArray(new
ObjectName[queryResult.size()]), SubscriptionViewMBean.class);
}
these quotes are redundant,when i delete these quotes,and replace this class
file to activemq-web-5.16.6.jar and restart active mq . the the consumer list
appears.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-396) Native resolver should retry on http 429
[ https://issues.apache.org/jira/browse/MRESOLVER-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Eldredge updated MRESOLVER-396: - Description: The Wagon http transport provider has custom logic to retry with exponential backoff when putting an artifact to an http endpoint and getting a 429 Too Many Requests response code from the server: [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] The newer "native" http transporter should provide similar retry logic. One place this could go would be into [HttpTransporter.implPut|[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427].|https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] Ideally the transport could be configured to retry on specific error codes, perhaps with 429 and 503 being defaults. The lack of retry support on 429s is exacerbate in Maven 3.9 because it enables parallel put by default, which increases requests per second making it more likely that a client would encounter rate limiting or other throttling and overload scenarios. was: The Wagon http transport provider has custom logic to retry with exponential backoff when putting an artifact to an http endpoint and getting a 429 Too Many Requests response code from the server: [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] The newer "native" http transporter should provide similar retry logic. One place this could go would be into [HttpTransporter.implPut]([https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] Ideally the transport could be configured to retry on specific error codes, perhaps with 429 and 503 being defaults. The lack of retry support on 429s is exacerbate in Maven 3.9 because it enables parallel put by default, which increases requests per second making it more likely that a client would encounter rate limiting or other throttling and overload scenarios. > Native resolver should retry on http 429 > > > Key: MRESOLVER-396 > URL: https://issues.apache.org/jira/browse/MRESOLVER-396 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Chris Eldredge >Priority: Minor > > The Wagon http transport provider has custom logic to retry with exponential > backoff when putting an artifact to an http endpoint and getting a 429 Too > Many Requests response code from the server: > [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] > The newer "native" http transporter should provide similar retry logic. One > place this could go would be into > [HttpTransporter.implPut|[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427].|https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] > Ideally the transport could be configured to retry on specific error codes, > perhaps with 429 and 503 being defaults. > The lack of retry support on 429s is exacerbate in Maven 3.9 because it > enables parallel put by default, which increases requests per second making > it more likely that a client would encounter rate limiting or other > throttling and overload scenarios. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-396) Native resolver should retry on http 429
Chris Eldredge created MRESOLVER-396: Summary: Native resolver should retry on http 429 Key: MRESOLVER-396 URL: https://issues.apache.org/jira/browse/MRESOLVER-396 Project: Maven Resolver Issue Type: Improvement Reporter: Chris Eldredge The Wagon http transport provider has custom logic to retry with exponential backoff when putting an artifact to an http endpoint and getting a 429 Too Many Requests response code from the server: [https://github.com/apache/maven-wagon/blob/wagon-3.5.3/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L828] The newer "native" http transporter should provide similar retry logic. One place this could go would be into [HttpTransporter.implPut]([https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java#L427).] Ideally the transport could be configured to retry on specific error codes, perhaps with 429 and 503 being defaults. The lack of retry support on 429s is exacerbate in Maven 3.9 because it enables parallel put by default, which increases requests per second making it more likely that a client would encounter rate limiting or other throttling and overload scenarios. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-763) JavadocReportTest.testExceptions is broken
[
https://issues.apache.org/jira/browse/MJAVADOC-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17753954#comment-17753954
]
ASF GitHub Bot commented on MJAVADOC-763:
-
slachiewicz commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293185054
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
Maybe we should catch MojoExecutionException and check the root cous of the
failing test instead of the generic Exception?
> JavadocReportTest.testExceptions is broken
> --
>
> Key: MJAVADOC-763
> URL: https://issues.apache.org/jira/browse/MJAVADOC-763
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> The Mojo lookup fails. This is hidden by bad exception handling in the test
> that catches too broad an exception type.
> [ERROR] Errors:
> [ERROR]
> JavadocReportTest.testExceptions:603->lookupMojo:103->AbstractMojoTestCase.lookupMojo:355->AbstractMojoTestCase.lookupMojo:426
> » ComponentConfiguration Cannot load implementation hint
> 'org.apache.maven.plugins.javadoc.stubs.ExceptionTestMavenProjectStub'
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] slachiewicz commented on a diff in pull request #219: [MJAVADOC-763] remove test that doesn't test what it claims
slachiewicz commented on code in PR #219:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/219#discussion_r1293185054
##
src/test/java/org/apache/maven/plugins/javadoc/JavadocReportTest.java:
##
@@ -594,27 +595,6 @@ public void testOptionsUmlautEncoding() throws Exception {
}
}
-/**
- * @throws Exception if any
- */
-public void testExceptions() throws Exception {
-try {
-Path testPom =
unit.resolve("default-configuration/exception-test-plugin-config.xml");
-JavadocReport mojo = lookupMojo(testPom);
Review Comment:
Maybe we should catch MojoExecutionException and check the root cous of the
failing test instead of the generic Exception?
--
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-mvnd] nick-ling opened a new issue, #877: Failed to load native library:jansi-2.4.0-d705f3ccea969984-libjansi.so
nick-ling opened a new issue, #877: URL: https://github.com/apache/maven-mvnd/issues/877 There is a problem with the maven configuration environment in Synology ```shell limbo@Limbo-NAS:/opt$ java -version java version "1.8.0_202" Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode) limbo@Limbo-NAS:/opt$ mvn -v Failed to load native library:jansi-2.4.0-320a2697b8944d1c-libjansi.so. The native library file at /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64 java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so: /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so: failed to map segment from shared object Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /opt/maven38 Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: /volume1/container/common/opt/config/jdk8/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.302+", arch: "amd64", family: "unix" limbo@Limbo-NAS:/opt$ ``` > Upgrade the jdk of higher version ```shell limbo@Limbo-NAS:/volume1/container/common/opt/config$ sudo vim /etc/profile limbo@Limbo-NAS:/volume1/container/common/opt/config$ source /etc/profile limbo@Limbo-NAS:/volume1/container/common/opt/config$ java -version java version "17.0.8" 2023-07-18 LTS Java(TM) SE Runtime Environment (build 17.0.8+9-LTS-211) Java HotSpot(TM) 64-Bit Server VM (build 17.0.8+9-LTS-211, mixed mode, sharing) limbo@Limbo-NAS:/volume1/container/common/opt/config$ mvn -v Failed to load native library:jansi-2.4.0-51613297cfd7b049-libjansi.so. The native library file at /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64 java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so: /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so: failed to map segment from shared object Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /opt/maven38 Java version: 17.0.8, vendor: Oracle Corporation, runtime: /volume1/container/common/opt/config/jdk17 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.302+", arch: "amd64", family: "unix" limbo@Limbo-NAS:/volume1/container/common/opt/config$ ``` The problem still exists！ How should I solve the problem？ -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
