[jira] [Resolved] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIASITETOOLS-348.
Fix Version/s: version-next
Resolution: Fixed
Fixed in
https://github.com/apache/maven-doxia-sitetools/commit/004b948e77cc8ed2e6aa74548ea259f1e2b6fa73.
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: version-next, 2.0.0
>
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-397) Deprecate Guice modules
[ https://issues.apache.org/jira/browse/MRESOLVER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884406#comment-17884406 ] ASF GitHub Bot commented on MRESOLVER-397: -- cstamas commented on PR #328: URL: https://github.com/apache/maven-resolver/pull/328#issuecomment-2372003980 @basil something along these lines? https://github.com/jenkinsci/acceptance-test-harness/pull/1733 > Deprecate Guice modules > --- > > Key: MRESOLVER-397 > URL: https://issues.apache.org/jira/browse/MRESOLVER-397 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 1.9.16 > > > So far resolver supported instantiation via: > * sisu components (JSR330) -- as used in Maven > * Guice module > * ServiceLocator > We should drop all non-major ones (guice, sl), as we provided replacement in > for of resolver provider module, so we provide: > * sisu components (JSR330) > * maven-resolver-provider MRESOLVER-387 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884392#comment-17884392 ] Gili commented on MGPG-136: --- Question: why does this even need to be a user-configurable option? To me, this should be an internal implementation detail that is not configurable by end-users. > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Assignee: Tamas Cservenak >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.6 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-397) Deprecate Guice modules
[ https://issues.apache.org/jira/browse/MRESOLVER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884381#comment-17884381 ] ASF GitHub Bot commented on MRESOLVER-397: -- basil commented on PR #328: URL: https://github.com/apache/maven-resolver/pull/328#issuecomment-2371874963 @cstamas This is a test framework, so the added Sisu dependency would be fine for us. Thanks for confirming that Sisu is the preferred migration path for heavy Guice users. As far as building instructions, https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/DOCKER.md is the best place to start. For testing Guice integration, you could probably even avoid Docker and simply use e.g. `run.sh firefox latest -Dtest=plugins.AntPluginTest#autoInstallAnt`. > Deprecate Guice modules > --- > > Key: MRESOLVER-397 > URL: https://issues.apache.org/jira/browse/MRESOLVER-397 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 1.9.16 > > > So far resolver supported instantiation via: > * sisu components (JSR330) -- as used in Maven > * Guice module > * ServiceLocator > We should drop all non-major ones (guice, sl), as we provided replacement in > for of resolver provider module, so we provide: > * sisu components (JSR330) > * maven-resolver-provider MRESOLVER-387 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-397) Deprecate Guice modules
[ https://issues.apache.org/jira/browse/MRESOLVER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884373#comment-17884373 ] ASF GitHub Bot commented on MRESOLVER-397: -- cstamas commented on PR #328: URL: https://github.com/apache/maven-resolver/pull/328#issuecomment-2371857312 Given you use Guice already, [Sisu](https://repo.maven.apache.org/maven2/org/eclipse/sisu/org.eclipse.sisu.inject/0.9.0.M3/) is "just" +300KB (if using no_asm and you provide ASM), or +500KB extra dependency. If you can live with that, I'd say "go with Sisu". @basil can you point me at some building instructions where I can test some ideas for migration? > Deprecate Guice modules > --- > > Key: MRESOLVER-397 > URL: https://issues.apache.org/jira/browse/MRESOLVER-397 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 1.9.16 > > > So far resolver supported instantiation via: > * sisu components (JSR330) -- as used in Maven > * Guice module > * ServiceLocator > We should drop all non-major ones (guice, sl), as we provided replacement in > for of resolver provider module, so we provide: > * sisu components (JSR330) > * maven-resolver-provider MRESOLVER-387 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-397) Deprecate Guice modules
[ https://issues.apache.org/jira/browse/MRESOLVER-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884368#comment-17884368 ] ASF GitHub Bot commented on MRESOLVER-397: -- basil commented on PR #328: URL: https://github.com/apache/maven-resolver/pull/328#issuecomment-2371842156 Hi @cstamas, we are currently relying on this deprecated functionality in the Jenkins Acceptance Test Harness (ATH), a Guice-based project that also uses Maven Resolver to fetch Jenkins plugins for tesitng purposes. The relevant functionality is here: https://github.com/jenkinsci/acceptance-test-harness/blob/9b7b87da2b1d5873876d156756f8849b26fcbc16/src/main/java/org/jenkinsci/test/acceptance/utils/aether/AetherModule.java Thank you very much for including this note: > This class is about to be dropped in 2.0.0 release. Use [Sisu](https://projects.eclipse.org/projects/technology.sisu) or use [Maven Resolver Supplier](https://maven.apache.org/resolver/third-party-integrations.html) to get `Resolver` instances. However, I am not sure whether Sisu or Maven Resolver Supplier would be better for our use case. Since we are already using Guice, would Sisu be the preferred migration path? And if so, are there any examples you could point to? > Deprecate Guice modules > --- > > Key: MRESOLVER-397 > URL: https://issues.apache.org/jira/browse/MRESOLVER-397 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 1.9.16 > > > So far resolver supported instantiation via: > * sisu components (JSR330) -- as used in Maven > * Guice module > * ServiceLocator > We should drop all non-major ones (guice, sl), as we provided replacement in > for of resolver provider module, so we provide: > * sisu components (JSR330) > * maven-resolver-provider MRESOLVER-387 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8265) Dependency should inherit properties like parent
abccbaandy created MNG-8265:
---
Summary: Dependency should inherit properties like parent
Key: MNG-8265
URL: https://issues.apache.org/jira/browse/MNG-8265
Project: Maven
Issue Type: Improvement
Reporter: abccbaandy
Now only parent have these feature, but sometimes we need some properties from
the dependency too.
For ex:
We have a spring project
{code:xml}
org.springframework.boot
spring-boot-starter-parent
3.3.4
org.springframework.boot
spring-boot-starter-data-neo4j
{code}
If I want reuse the properties in the child of
`spring-boot-starter-data-neo4j`, it's not possible right now.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2268) Tests run under classpath if JDK 23 is used
[
https://issues.apache.org/jira/browse/SUREFIRE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned SUREFIRE-2268:
-
Assignee: Slawomir Jaranowski
> Tests run under classpath if JDK 23 is used
> ---
>
> Key: SUREFIRE-2268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2268
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.5.0
>Reporter: Gili
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.5.1
>
>
> Something odd is going on with JDK 23. If I run my tests under JDK 21 or JDK
> 22 they run under the module-path. If I change "maven.compiler.release" to
> 23, then all of a sudden Surefire is running the tests on the classpath. It's
> odd. I'm not changing anything else about my code. If I run:
>
> LoggerFactory.getLogger(getClass()).info("class: {}, module: {}", getClass(),
> getClass().getModule().toString());
>
> under JDK 21, I get a module name. Under JDK 23, I get "unnamed module" and
> module-specific functionality breaks (e.g. Module.getDescriptor() returns
> null).
>
> Have you tried running any of the integration tests under JDK 23? I'm hoping
> you can reproduce the problem on your end...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIASITETOOLS-348:
---
Fix Version/s: 2.0.0
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MGPG-144) (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0
[ https://issues.apache.org/jira/browse/MGPG-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MGPG-144: Assignee: Tamas Cservenak > (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0 > --- > > Key: MGPG-144 > URL: https://issues.apache.org/jira/browse/MGPG-144 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MGPG-144) (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0
[ https://issues.apache.org/jira/browse/MGPG-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-144. Resolution: Fixed > (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0 > --- > > Key: MGPG-144 > URL: https://issues.apache.org/jira/browse/MGPG-144 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-145) (IT suite) IT did not catch issue on Windows OS
[ https://issues.apache.org/jira/browse/MGPG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-145: - Summary: (IT suite) IT did not catch issue on Windows OS (was: (IT suite)) > (IT suite) IT did not catch issue on Windows OS > --- > > Key: MGPG-145 > URL: https://issues.apache.org/jira/browse/MGPG-145 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 >Reporter: Tamas Cservenak >Priority: Blocker > > Since version 3.2.0 two things happened: > * we started terminating passphrase using "line separator" (as part of fix > for MGPG-99) > * this caused that on Windows we corrupted passwords by extra "\r" present > (see MGPG-136) > The problem we must fix: we DO have IT "sign-release-best-practices" and we > have Windows in OS matrix, but this IT never failed, while user setup matrix > did: https://github.com/ralfkonrad/test-mvn-gpg-plugin > WHY? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-145) (IT suite)
Tamas Cservenak created MGPG-145: Summary: (IT suite) Key: MGPG-145 URL: https://issues.apache.org/jira/browse/MGPG-145 Project: Maven GPG Plugin Issue Type: Bug Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0 Reporter: Tamas Cservenak Since version 3.2.0 two things happened: * we started terminating passphrase using "line separator" (as part of fix for MGPG-99) * this caused that on Windows we corrupted passwords by extra "\r" present (see MGPG-136) The problem we must fix: we DO have IT "sign-release-best-practices" and we have Windows in OS matrix, but this IT never failed, while user setup matrix did: https://github.com/ralfkonrad/test-mvn-gpg-plugin WHY? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-144) (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0
Tamas Cservenak created MGPG-144: Summary: (test) Bump commons-io:commons-io from 2.16.1 to 2.17.0 Key: MGPG-144 URL: https://issues.apache.org/jira/browse/MGPG-144 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.2.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MGPG-143) Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1
[ https://issues.apache.org/jira/browse/MGPG-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-143. Resolution: Fixed > Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1 > > > Key: MGPG-143 > URL: https://issues.apache.org/jira/browse/MGPG-143 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-136. Assignee: Tamas Cservenak Resolution: Fixed > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Assignee: Tamas Cservenak >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.6 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MGPG-143) Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1
[ https://issues.apache.org/jira/browse/MGPG-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MGPG-143: Assignee: Tamas Cservenak > Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1 > > > Key: MGPG-143 > URL: https://issues.apache.org/jira/browse/MGPG-143 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-143) Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1
Tamas Cservenak created MGPG-143: Summary: Bump com.kohlschutter.junixsocket:junixsocket-core from 2.10.0 to 2.10.1 Key: MGPG-143 URL: https://issues.apache.org/jira/browse/MGPG-143 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.2.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884262#comment-17884262 ] ASF GitHub Bot commented on MGPG-136: - cstamas merged PR #120: URL: https://github.com/apache/maven-gpg-plugin/pull/120 > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.6 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-136: - Description: Version 3.2.0 - 3.2.6 fail with "gpg: signing failed: Bad passphrase" on GitHub Windows Runners. Using Linux or downgrading to version 3.1.0 seems to work fine. It's not clear what changed in these newer versions but [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] looks like a highly supicious way of reading environment variables. It's possible that this approach does not work properly under Powershell. If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get back the correct value, so it sounds like there is a bug in the way that this plugin is choosing to read the environment variable. What makes this a bit tricky, however, is that the environment variable is called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell variant. Can you guys please look into this? was: Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on GitHub Windows Runners. Using Linux or downgrading to version 3.1.0 seems to work fine. It's not clear what changed in these newer versions but [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] looks like a highly supicious way of reading environment variables. It's possible that this approach does not work properly under Powershell. If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get back the correct value, so it sounds like there is a bug in the way that this plugin is choosing to read the environment variable. What makes this a bit tricky, however, is that the environment variable is called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell variant. Can you guys please look into this? > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.6 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-136: - Affects Version/s: 3.2.6 > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-812) [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884242#comment-17884242
]
ASF GitHub Bot commented on MJAVADOC-812:
-
michael-o merged PR #320:
URL: https://github.com/apache/maven-javadoc-plugin/pull/320
> [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
> ---
>
> Key: MJAVADOC-812
> URL: https://issues.apache.org/jira/browse/MJAVADOC-812
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Armin Krezovic
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
> Attachments: maven-javadoc-invocation.log
>
>
> After updating to maven-javadoc-plugin 3.10.0, I am getting empty javadoc
> jars created.
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d.jar
> [INFO]
> [INFO] --- javadoc:3.10.0:jar (attach-javadocs) @ configuration ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d-javadoc.jar
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ configuration ---
> [INFO] No sources in project. Archive not created.{code}
>
> Prior version, 3.8.0, had no such problem
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192102.595f143.jar
> [INFO]
> [INFO] --- javadoc:3.8.0:jar (attach-javadocs) @ configuration ---
> [INFO]
> [INFO] >>> source:3.3.1:jar (attach-sources) > generate-sources @
> configuration >>>{code}
>
> Plugin configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.10.0
>
>all,-missing
>
>
>
> attach-javadocs
>
> jar
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-812) [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-812.
---
Resolution: Fixed
Fixed with
[cde7c56baff9d14b7ab98ced4137488048589419|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git&a=commit&h=cde7c56baff9d14b7ab98ced4137488048589419].
> [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
> ---
>
> Key: MJAVADOC-812
> URL: https://issues.apache.org/jira/browse/MJAVADOC-812
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Armin Krezovic
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
> Attachments: maven-javadoc-invocation.log
>
>
> After updating to maven-javadoc-plugin 3.10.0, I am getting empty javadoc
> jars created.
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d.jar
> [INFO]
> [INFO] --- javadoc:3.10.0:jar (attach-javadocs) @ configuration ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d-javadoc.jar
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ configuration ---
> [INFO] No sources in project. Archive not created.{code}
>
> Prior version, 3.8.0, had no such problem
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192102.595f143.jar
> [INFO]
> [INFO] --- javadoc:3.8.0:jar (attach-javadocs) @ configuration ---
> [INFO]
> [INFO] >>> source:3.3.1:jar (attach-sources) > generate-sources @
> configuration >>>{code}
>
> Plugin configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.10.0
>
> all,-missing
>
>
>
> attach-javadocs
>
> jar
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-812) [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884241#comment-17884241
]
ASF GitHub Bot commented on MJAVADOC-812:
-
michael-o closed pull request #320: [MJAVADOC-812] [REGRESSION]
maven-javadoc-plugin 3.10.0 creates empty…
URL: https://github.com/apache/maven-javadoc-plugin/pull/320
> [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
> ---
>
> Key: MJAVADOC-812
> URL: https://issues.apache.org/jira/browse/MJAVADOC-812
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Armin Krezovic
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
> Attachments: maven-javadoc-invocation.log
>
>
> After updating to maven-javadoc-plugin 3.10.0, I am getting empty javadoc
> jars created.
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d.jar
> [INFO]
> [INFO] --- javadoc:3.10.0:jar (attach-javadocs) @ configuration ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d-javadoc.jar
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ configuration ---
> [INFO] No sources in project. Archive not created.{code}
>
> Prior version, 3.8.0, had no such problem
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192102.595f143.jar
> [INFO]
> [INFO] --- javadoc:3.8.0:jar (attach-javadocs) @ configuration ---
> [INFO]
> [INFO] >>> source:3.3.1:jar (attach-sources) > generate-sources @
> configuration >>>{code}
>
> Plugin configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.10.0
>
>all,-missing
>
>
>
> attach-javadocs
>
> jar
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-811.
---
Resolution: Fixed
Fixed with
[db6d7f6ec355dd26c7f4841ad2c63ff4df456422|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git&a=commit&h=db6d7f6ec355dd26c7f4841ad2c63ff4df456422].
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884239#comment-17884239
]
ASF GitHub Bot commented on MJAVADOC-811:
-
michael-o closed pull request #321: [MJAVADOC-811] javadoc.bat fails to execute
on Windows when project i…
URL: https://github.com/apache/maven-javadoc-plugin/pull/321
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-812) [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-812:
Fix Version/s: 3.10.1
> [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
> ---
>
> Key: MJAVADOC-812
> URL: https://issues.apache.org/jira/browse/MJAVADOC-812
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Armin Krezovic
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
> Attachments: maven-javadoc-invocation.log
>
>
> After updating to maven-javadoc-plugin 3.10.0, I am getting empty javadoc
> jars created.
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d.jar
> [INFO]
> [INFO] --- javadoc:3.10.0:jar (attach-javadocs) @ configuration ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d-javadoc.jar
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ configuration ---
> [INFO] No sources in project. Archive not created.{code}
>
> Prior version, 3.8.0, had no such problem
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192102.595f143.jar
> [INFO]
> [INFO] --- javadoc:3.8.0:jar (attach-javadocs) @ configuration ---
> [INFO]
> [INFO] >>> source:3.3.1:jar (attach-sources) > generate-sources @
> configuration >>>{code}
>
> Plugin configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.10.0
>
>all,-missing
>
>
>
> attach-javadocs
>
> jar
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884227#comment-17884227 ] Tamas Cservenak commented on MGPG-137: -- Moreover, I think we should stop supporting ancient GPG versions (2.0 or older), and just move to latest stable like 2.2+ is? Unsure what platforms like "super stable" debian or BSD offers today. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884224#comment-17884224 ] Tamas Cservenak edited comment on MGPG-137 at 9/24/24 11:02 AM: BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing (supply the signing key and passphrase as env variables! So as "secrets" in case of GH). On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. was (Author: cstamas): BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing (supply the key and passphrase as env variables! So as "secrets" in case of GH). On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884224#comment-17884224 ] Tamas Cservenak edited comment on MGPG-137 at 9/24/24 11:02 AM: BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing (supply the signing key and passphrase as env variables! So both may be "secrets" in case of GH). On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. was (Author: cstamas): BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing (supply the signing key and passphrase as env variables! So as "secrets" in case of GH). On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884224#comment-17884224 ] Tamas Cservenak edited comment on MGPG-137 at 9/24/24 11:02 AM: BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing (supply the key and passphrase as env variables! So as "secrets" in case of GH). On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. was (Author: cstamas): BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing. On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884224#comment-17884224 ] Tamas Cservenak commented on MGPG-137: -- BC signer was basically added for CI use case, to solve the misery of signing (skip things like installation of gpg, then you need to add key to it, make passphrase in settings/properties, yada yada). BC does super simple "headless" signing. On the other hand, on dev workstations (like when we release ASF projects), signing should use existing GPG environment of user, that includes working GPG Agent as well, and Agent will be used to ask user for passphrase, in a secure manner. Again, no need to save to disk anything in this use case. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884221#comment-17884221 ] Tamas Cservenak commented on MGPG-137: -- Just to clear up: in case of CI runs, the environment variable is recommended as source of sensitive "passphrase". While in case of dev workstation runs use of gpg-agent is best practice and recommended. In any case, no sensitive data like passphrase should (or is even needed) to be stored in settings.xml or POM properties, never ever. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCLEAN-124) Provide more accurate reason when can not delete a resource
[
https://issues.apache.org/jira/browse/MCLEAN-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884207#comment-17884207
]
Slawomir Jaranowski commented on MCLEAN-124:
{quote}What do you if Java does not provide more information?
{quote}
We need to try ... I see that we use {{exception.addSuppressed(e);}} but in
stactrace is not printed ...
> Provide more accurate reason when can not delete a resource
> ---
>
> Key: MCLEAN-124
> URL: https://issues.apache.org/jira/browse/MCLEAN-124
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Currently we have only in stack trace something like:
> {noformat}
> Caused by: java.io.IOException: Failed to delete
> /Users/runner/work/maven-surefire/maven-surefire/surefire-its/target
> at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:300)
> at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:250)
> at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:124)
> {noformat}
> It will be usable if we have reported a reason ... why can not be deleted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[
https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884200#comment-17884200
]
ASF GitHub Bot commented on MGPG-136:
-
michael-o commented on code in PR #120:
URL: https://github.com/apache/maven-gpg-plugin/pull/120#discussion_r1773041660
##
src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java:
##
@@ -270,6 +270,20 @@ public abstract class AbstractGpgMojo extends AbstractMojo
{
@Parameter(property = "gpg.bestPractices", defaultValue = "false")
private boolean bestPractices;
+/**
+ * Whether to append the passphrase with LF character or not, as on some
systems and some GPG executable combinations
+ * lack of this character may cause GPG to not detect passphrase on STDIN.
Since 3.2.0 it was always appended, unless
+ * passphrase itself ended with line separator. This parameter affects
ONLY the GPG signer, not the BC signer.
+ *
+ * By default, this parameter is {@code true} to retain same behaviour as
before.
+ *
+ * @since 3.2.7
+ * @see https://issues.apache.org/jira/browse/MGPG-99";>MGPG-99
+ * @see https://issues.apache.org/jira/browse/MGPG-136";>MGPG-136
+ */
+@Parameter(property = "gpg.passphraseLf", defaultValue = "true")
+private boolean passphraseLf;
Review Comment:
I think this parameter should just be `terminatePassphrase`
##
src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java:
##
@@ -270,6 +270,20 @@ public abstract class AbstractGpgMojo extends AbstractMojo
{
@Parameter(property = "gpg.bestPractices", defaultValue = "false")
private boolean bestPractices;
+/**
+ * Whether to append the passphrase with LF character or not, as on some
systems and some GPG executable combinations
Review Comment:
Whether to to terminate the passphrase with the LF character or not,
> "gpg: signing failed: Bad passphrase" on GitHub Windows runners
> ---
>
> Key: MGPG-136
> URL: https://issues.apache.org/jira/browse/MGPG-136
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home:
> C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6
> Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime:
> C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows server 2022", version: "10.0", arch: "aarch64", family:
> "windows"
>Reporter: Gili
>Priority: Critical
> Fix For: 3.2.7
>
>
> Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on
> GitHub Windows Runners.
> Using Linux or downgrading to version 3.1.0 seems to work fine.
> It's not clear what changed in these newer versions but
> [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368]
> looks like a highly supicious way of reading environment variables. It's
> possible that this approach does not work properly under Powershell.
> If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get
> back the correct value, so it sounds like there is a bug in the way that this
> plugin is choosing to read the environment variable.
> What makes this a bit tricky, however, is that the environment variable is
> called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and
> $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell
> variant.
> Can you guys please look into this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-136: - Fix Version/s: 3.2.7 > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > Fix For: 3.2.7 > > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884192#comment-17884192 ] Tamas Cservenak commented on MGPG-136: -- [~michael-o][~cowwoc] seems it was rogue CR! See https://github.com/ralfkonrad/test-mvn-gpg-plugin/pull/28 > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-605) FileTransporter should offer symlink, hardlink ops aside of existing copy
[ https://issues.apache.org/jira/browse/MRESOLVER-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-605: - Assignee: Tamas Cservenak > FileTransporter should offer symlink, hardlink ops aside of existing copy > - > > Key: MRESOLVER-605 > URL: https://issues.apache.org/jira/browse/MRESOLVER-605 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.2 > > > FileTransport is a "remote repository" transport that is using FS, hence, is > most probably "local" to Resolver process (does not have to be, ie. use of > NFS mount or alike). > Hence, FileTransport should offer some means to not copy but link the files. > FileTranport is usually used in tests and alike, so doing this would lessen > disk store usage and even execution times. > Still, given FileTranport is "remote" transport, checksumming must happen, > hence file being transported must be read (so gain is not "just link it", is > way less). > Big fat note: this change will cause that symlinks may land in local > repository. This change does NOT enforce rest of Maven plugins knows how to > handle them, is out of scope. > Other alternative for "local test setups" is ChainedLocalRepository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-605) FileTransporter should offer symlink, hardlink ops aside of existing copy
[ https://issues.apache.org/jira/browse/MRESOLVER-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-605: -- Description: FileTransport is a "remote repository" transport that is using FS, hence, is most probably "local" to Resolver process (does not have to be, ie. use of NFS mount or alike). Hence, FileTransport should offer some means to not copy but link the files. FileTranport is usually used in tests and alike, so doing this would lessen disk store usage and even execution times. Still, given FileTranport is "remote" transport, checksumming must happen, hence file being transported must be read (so gain is not "just link it", is way less). Big fat note: this change will cause that symlinks may land in local repository. This change does NOT enforce rest of Maven plugins knows how to handle them, is out of scope. Other alternative for "local test setups" is ChainedLocalRepository. was: FileTransport is a "remote repository" transport that is using FS, hence, is most probably "local" to Resolver process (does not have to be, ie. use of NFS mount or alike). Hence, FileTransport should offer some means to not copy but link the files. FileTranport is usually used in tests and alike, so doing this would lessen disk store usage and even execution times. Still, given FileTranport is "remote" transport, checksumming must happen, hence file being transported must be read (so gain is not "just link it", is way less). Other alternative for "local test setups" is ChainedLocalRepository. > FileTransporter should offer symlink, hardlink ops aside of existing copy > - > > Key: MRESOLVER-605 > URL: https://issues.apache.org/jira/browse/MRESOLVER-605 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.2 > > > FileTransport is a "remote repository" transport that is using FS, hence, is > most probably "local" to Resolver process (does not have to be, ie. use of > NFS mount or alike). > Hence, FileTransport should offer some means to not copy but link the files. > FileTranport is usually used in tests and alike, so doing this would lessen > disk store usage and even execution times. > Still, given FileTranport is "remote" transport, checksumming must happen, > hence file being transported must be read (so gain is not "just link it", is > way less). > Big fat note: this change will cause that symlinks may land in local > repository. This change does NOT enforce rest of Maven plugins knows how to > handle them, is out of scope. > Other alternative for "local test setups" is ChainedLocalRepository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-605) FileTransporter should offer symlink, hardlink ops aside of existing copy
Tamas Cservenak created MRESOLVER-605: - Summary: FileTransporter should offer symlink, hardlink ops aside of existing copy Key: MRESOLVER-605 URL: https://issues.apache.org/jira/browse/MRESOLVER-605 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.2 FileTransport is a "remote repository" transport that is using FS, hence, is most probably "local" to Resolver process (does not have to be, ie. use of NFS mount or alike). Hence, FileTransport should offer some means to not copy but link the files. FileTranport is usually used in tests and alike, so doing this would lessen disk store usage and even execution times. Still, given FileTranport is "remote" transport, checksumming must happen, hence file being transported must be read (so gain is not "just link it", is way less). Other alternative for "local test setups" is ChainedLocalRepository. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCLEAN-124) Provide more accurate reason when can not delete a resource
Slawomir Jaranowski created MCLEAN-124:
--
Summary: Provide more accurate reason when can not delete a
resource
Key: MCLEAN-124
URL: https://issues.apache.org/jira/browse/MCLEAN-124
Project: Maven Clean Plugin
Issue Type: Improvement
Reporter: Slawomir Jaranowski
Currently we have only in stack trace something like:
{noformat}
Caused by: java.io.IOException: Failed to delete
/Users/runner/work/maven-surefire/maven-surefire/surefire-its/target
at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:300)
at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:250)
at org.apache.maven.plugins.clean.Cleaner.delete (Cleaner.java:124)
{noformat}
It will be usable if we have reported a reason ... why can not be deleted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRELEASE-1154) [REGRESSION] MRELEASE-1109 breaks release of Maven Surefire
[
https://issues.apache.org/jira/browse/MRELEASE-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884167#comment-17884167
]
Konrad Windszus commented on MRELEASE-1154:
---
Fixed in
https://github.com/apache/maven-release/commit/e2745edcc2e6ced132a4fec2e9648d54e2bb895e
by just skipping every locally unresolvable property in version values.
> [REGRESSION] MRELEASE-1109 breaks release of Maven Surefire
> ---
>
> Key: MRELEASE-1154
> URL: https://issues.apache.org/jira/browse/MRELEASE-1154
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: next-release
>
>
> Upgraded Maven Surefire to Parent 43 and failed to prepare release with {{mvn
> release:prepare -e}}:
> {noformat}
> [INFO] Ignoring artifact version update for expression ${project.version}
> [INFO]
>
> [INFO] Reactor Summary for Apache Maven Surefire 3.5.1-SNAPSHOT:
> [INFO]
> [INFO] Apache Maven Surefire .. FAILURE [ 58.812
> s]
> [INFO] Surefire Shared Utils .. SKIPPED
> [INFO] Surefire Logger API SKIPPED
> [INFO] Surefire API ... SKIPPED
> [INFO] Surefire Extensions API SKIPPED
> [INFO] Surefire Extensions SPI SKIPPED
> [INFO] Surefire Booter SKIPPED
> [INFO] Maven Surefire Test-Grouping Support ... SKIPPED
> [INFO] Surefire Providers . SKIPPED
> [INFO] Shared JUnit3 Provider Code SKIPPED
> [INFO] Shared Java 5 Provider Base SKIPPED
> [INFO] Shared JUnit4 Provider Code SKIPPED
> [INFO] Shared JUnit48 Provider Code ... SKIPPED
> [INFO] Surefire JUnit Runner .. SKIPPED
> [INFO] Surefire JUnit4 Runner . SKIPPED
> [INFO] Maven Surefire Common .. SKIPPED
> [INFO] Surefire JUnitCore Runner .. SKIPPED
> [INFO] Surefire JUnit Platform Runner . SKIPPED
> [INFO] Surefire TestNG Utils .. SKIPPED
> [INFO] Surefire TestNG Runner . SKIPPED
> [INFO] ShadeFire JUnit3 Provider .. SKIPPED
> [INFO] Surefire Report Parser . SKIPPED
> [INFO] Maven Surefire Plugin .. SKIPPED
> [INFO] Maven Failsafe Plugin .. SKIPPED
> [INFO] Maven Surefire Report Plugin ... SKIPPED
> [INFO] Maven Surefire Integration Tests ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:02 min
> [INFO] Finished at: 2024-08-23T11:32:04+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.1.0:prepare (default-cli) on
> project surefire: Could not find properties resolving version expression :
> ${surefire-shared-utils.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:3.1.0:prepare
> (default-cli) on project surefire: Could not find properties resolving
> version expression : ${surefire-shared-utils.version}
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojo
[jira] [Resolved] (MRELEASE-1154) [REGRESSION] MRELEASE-1109 breaks release of Maven Surefire
[
https://issues.apache.org/jira/browse/MRELEASE-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MRELEASE-1154.
---
Resolution: Fixed
> [REGRESSION] MRELEASE-1109 breaks release of Maven Surefire
> ---
>
> Key: MRELEASE-1154
> URL: https://issues.apache.org/jira/browse/MRELEASE-1154
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 3.1.0, 3.1.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: next-release
>
>
> Upgraded Maven Surefire to Parent 43 and failed to prepare release with {{mvn
> release:prepare -e}}:
> {noformat}
> [INFO] Ignoring artifact version update for expression ${project.version}
> [INFO]
>
> [INFO] Reactor Summary for Apache Maven Surefire 3.5.1-SNAPSHOT:
> [INFO]
> [INFO] Apache Maven Surefire .. FAILURE [ 58.812
> s]
> [INFO] Surefire Shared Utils .. SKIPPED
> [INFO] Surefire Logger API SKIPPED
> [INFO] Surefire API ... SKIPPED
> [INFO] Surefire Extensions API SKIPPED
> [INFO] Surefire Extensions SPI SKIPPED
> [INFO] Surefire Booter SKIPPED
> [INFO] Maven Surefire Test-Grouping Support ... SKIPPED
> [INFO] Surefire Providers . SKIPPED
> [INFO] Shared JUnit3 Provider Code SKIPPED
> [INFO] Shared Java 5 Provider Base SKIPPED
> [INFO] Shared JUnit4 Provider Code SKIPPED
> [INFO] Shared JUnit48 Provider Code ... SKIPPED
> [INFO] Surefire JUnit Runner .. SKIPPED
> [INFO] Surefire JUnit4 Runner . SKIPPED
> [INFO] Maven Surefire Common .. SKIPPED
> [INFO] Surefire JUnitCore Runner .. SKIPPED
> [INFO] Surefire JUnit Platform Runner . SKIPPED
> [INFO] Surefire TestNG Utils .. SKIPPED
> [INFO] Surefire TestNG Runner . SKIPPED
> [INFO] ShadeFire JUnit3 Provider .. SKIPPED
> [INFO] Surefire Report Parser . SKIPPED
> [INFO] Maven Surefire Plugin .. SKIPPED
> [INFO] Maven Failsafe Plugin .. SKIPPED
> [INFO] Maven Surefire Report Plugin ... SKIPPED
> [INFO] Maven Surefire Integration Tests ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 01:02 min
> [INFO] Finished at: 2024-08-23T11:32:04+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:3.1.0:prepare (default-cli) on
> project surefire: Could not find properties resolving version expression :
> ${surefire-shared-utils.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:3.1.0:prepare
> (default-cli) on project surefire: Could not find properties resolving
> version expression : ${surefire-shared-utils.version}
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
&
[jira] [Closed] (MNG-7900) wrapper lifecycle in multi module project should be executed only in root module
[
https://issues.apache.org/jira/browse/MNG-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-7900.
Resolution: Won't Fix
As we remove wrapper lifecycle in MNG-8263 we can close it
> wrapper lifecycle in multi module project should be executed only in root
> module
>
>
> Key: MNG-7900
> URL: https://issues.apache.org/jira/browse/MNG-7900
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 4.0.0-alpha-7
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Execute
> {code:java}
> mvn wrapper
> {code}
> should have the same result as goal:
> {code:java}
> mvn wrapper:wrapper
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8263) Remove last remnants of wrapper integration into core
[ https://issues.apache.org/jira/browse/MNG-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8263. Resolution: Fixed > Remove last remnants of wrapper integration into core > - > > Key: MNG-8263 > URL: https://issues.apache.org/jira/browse/MNG-8263 > Project: Maven > Issue Type: Task > Components: Bootstrap & Build, Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-5 > > > At early beginning of ingesting Takari Wrapper, several ideas were tried > until wrapper arrived to it's final place. > Still, there are some remnants in master that complicates our lives and also > results in strange side effects: > * lifecycle - this makes Maven4 be fixed regarding used Wrapper (unless > explicitly set in POM, but wrapper is not a lifecycle plugin, so should not > be set in POM) > * mvn/mvn.cmd scripts - they were split to make them reusable for wrapper, > but today there is no need for this. Still, split scripts are hard to > manage/edit/validate with tools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-812) [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
[
https://issues.apache.org/jira/browse/MJAVADOC-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884160#comment-17884160
]
ASF GitHub Bot commented on MJAVADOC-812:
-
michael-o commented on PR #320:
URL:
https://github.com/apache/maven-javadoc-plugin/pull/320#issuecomment-2370475121
@pzygielo IT added.
> [REGRESSION] maven-javadoc-plugin 3.10.0 creates empty JARs
> ---
>
> Key: MJAVADOC-812
> URL: https://issues.apache.org/jira/browse/MJAVADOC-812
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Armin Krezovic
>Assignee: Michael Osipov
>Priority: Major
> Attachments: maven-javadoc-invocation.log
>
>
> After updating to maven-javadoc-plugin 3.10.0, I am getting empty javadoc
> jars created.
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d.jar
> [INFO]
> [INFO] --- javadoc:3.10.0:jar (attach-javadocs) @ configuration ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192051.4892c3d-javadoc.jar
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ configuration ---
> [INFO] No sources in project. Archive not created.{code}
>
> Prior version, 3.8.0, had no such problem
> {code:java}
> [INFO] --- jar:3.4.2:jar (default-jar) @ configuration ---
> [INFO] Building jar:
> C:\path\to\configuration\target\configuration-10.1.0-SNAPSHOT-2409192102.595f143.jar
> [INFO]
> [INFO] --- javadoc:3.8.0:jar (attach-javadocs) @ configuration ---
> [INFO]
> [INFO] >>> source:3.3.1:jar (attach-sources) > generate-sources @
> configuration >>>{code}
>
> Plugin configuration
> {code:java}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.10.0
>
>all,-missing
>
>
>
> attach-javadocs
>
> jar
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIA-740.
---
Resolution: Fixed
Fixed in
https://github.com/apache/maven-doxia/commit/c93d1425bd0203496d1e75ec49a41874a8d9f84e.
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884155#comment-17884155
]
ASF GitHub Bot commented on DOXIA-740:
--
kwin merged PR #228:
URL: https://github.com/apache/maven-doxia/pull/228
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2268) Tests run under classpath if JDK 23 is used
[
https://issues.apache.org/jira/browse/SUREFIRE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884144#comment-17884144
]
Slawomir Jaranowski commented on SUREFIRE-2268:
---
Without more checking I guess that we need new release of
https://github.com/codehaus-plexus/plexus-languages
> Tests run under classpath if JDK 23 is used
> ---
>
> Key: SUREFIRE-2268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2268
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.5.0
>Reporter: Gili
>Priority: Major
>
> Something odd is going on with JDK 23. If I run my tests under JDK 21 or JDK
> 22 they run under the module-path. If I change "maven.compiler.release" to
> 23, then all of a sudden Surefire is running the tests on the classpath. It's
> odd. I'm not changing anything else about my code. If I run:
>
> LoggerFactory.getLogger(getClass()).info("class: {}, module: {}", getClass(),
> getClass().getModule().toString());
>
> under JDK 21, I get a module name. Under JDK 23, I get "unnamed module" and
> module-specific functionality breaks (e.g. Module.getDescriptor() returns
> null).
>
> Have you tried running any of the integration tests under JDK 23? I'm hoping
> you can reproduce the problem on your end...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2268) Tests run under classpath if JDK 23 is used
[
https://issues.apache.org/jira/browse/SUREFIRE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated SUREFIRE-2268:
--
Fix Version/s: 3.5.1
> Tests run under classpath if JDK 23 is used
> ---
>
> Key: SUREFIRE-2268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2268
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.5.0
>Reporter: Gili
>Priority: Major
> Fix For: 3.5.1
>
>
> Something odd is going on with JDK 23. If I run my tests under JDK 21 or JDK
> 22 they run under the module-path. If I change "maven.compiler.release" to
> 23, then all of a sudden Surefire is running the tests on the classpath. It's
> odd. I'm not changing anything else about my code. If I run:
>
> LoggerFactory.getLogger(getClass()).info("class: {}, module: {}", getClass(),
> getClass().getModule().toString());
>
> under JDK 21, I get a module name. Under JDK 23, I get "unnamed module" and
> module-specific functionality breaks (e.g. Module.getDescriptor() returns
> null).
>
> Have you tried running any of the integration tests under JDK 23? I'm hoping
> you can reproduce the problem on your end...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2271) No logs from testcases visible when running integration tests
mikael petterson created SUREFIRE-2271: -- Summary: No logs from testcases visible when running integration tests Key: SUREFIRE-2271 URL: https://issues.apache.org/jira/browse/SUREFIRE-2271 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 3.5.0 Reporter: mikael petterson Attachments: maven-failsafe-plugin_log.txt Hi, I am running our integration tests with the failsafe plugin using: mvn clean verify I can see that logging messages ( slf4j + log4j2) for the unit tests ( testng) is present in the console. Then when it comes to the integration tests I don't see any output at all until a test fails, then I see the error message. I have log4j2-test.xml files located in the maven modules. I attach logs when running: mvn -X failsafe:integration-test //mikael -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884134#comment-17884134
]
Michael Osipov commented on MJAVADOC-811:
-
[~seb], branch created, please test.
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884133#comment-17884133
]
ASF GitHub Bot commented on MJAVADOC-811:
-
michael-o opened a new pull request, #321:
URL: https://github.com/apache/maven-javadoc-plugin/pull/321
…s not on drive C and AutoRun is configured
This closes #321
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MJAVADOC) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MJAVADOC-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A
more thorough check will
be performed on your pull request automatically.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licensed under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-811:
Fix Version/s: 3.10.1
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.10.1
>
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8258:
---
Description:
Reproducible Builds is a good practice that is easy to enable: it would be nice
to enable it by default, and have projects disable it of they really have a
problem with the default bahaviour
result can be checked by running {{mvn artifact:check-buildplan}} on a minimal
pom.xml:
- before: {{[ERROR] Reproducible Build not activated by
project.build.outputTimestamp property: see
https://maven.apache.org/guides/mini/guide-reproducible-builds.html}}
- after: {{[WARNING] property is inherited, it
should be defined in pom.xml}}
was:
Reproducible Builds is a good practice that is easy to enable: it would be nice
to enable it by default, and have projects disable it of they really have a
problem with the default bahaviour
result can be checked by running {{mvn artifact:check-buildplan}}
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects disable it of they really
> have a problem with the default bahaviour
> result can be checked by running {{mvn artifact:check-buildplan}} on a
> minimal pom.xml:
> - before: {{[ERROR] Reproducible Build not activated by
> project.build.outputTimestamp property: see
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html}}
> - after: {{[WARNING] property is inherited,
> it should be defined in pom.xml}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8258:
---
Description:
Reproducible Builds is a good practice that is easy to enable: it would be nice
to enable it by default, and have projects disable it of they really have a
problem with the default bahaviour
result can be checked by running {{mvn artifact:check-buildplan}}
was:Reproducible Builds is a good practice that is easy to enable: it would
be nice to enable it by default, and have projects disable it if they really
have a problem with the default reproducible behaviour
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects disable it of they really
> have a problem with the default bahaviour
> result can be checked by running {{mvn artifact:check-buildplan}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8258) activate Reproducible Builds by default
[ https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-8258: --- Description: Reproducible Builds is a good practice that is easy to enable: it would be nice to enable it by default, and have projects disable it if they really have a problem with the default reproducible behaviour (was: Reproducible Builds is a good practice that is easy to enable: it would be nice to enable it by default, and have projects disable it of they really have a problem with the default bahaviour) > activate Reproducible Builds by default > --- > > Key: MNG-8258 > URL: https://issues.apache.org/jira/browse/MNG-8258 > Project: Maven > Issue Type: New Feature > Components: Core >Affects Versions: 3.9.9, 4.0.0-beta-4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.0-beta-5 > > > Reproducible Builds is a good practice that is easy to enable: it would be > nice to enable it by default, and have projects disable it if they really > have a problem with the default reproducible behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRELEASE-1154) [REGRESSION] MRELEASE-1109 breaks release of Maven Surefire
[
https://issues.apache.org/jira/browse/MRELEASE-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884089#comment-17884089
]
ASF GitHub Bot commented on MRELEASE-1154:
--
gnodet commented on code in PR #230:
URL: https://github.com/apache/maven-release/pull/230#discussion_r1772487584
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -517,128 +517,177 @@ private void rewriteArtifactVersions(
if (elements == null) {
return;
}
-String projectId =
ArtifactUtils.versionlessKey(projectModel.getGroupId(),
projectModel.getArtifactId());
for (MavenCoordinate coordinate : elements) {
-String rawVersion = coordinate.getVersion();
-if (rawVersion == null) {
-// managed dependency or unversioned plugin
-continue;
-}
+rewriteArtifactVersion(coordinate, projectModel, properties,
result, releaseDescriptor, simulate);
+}
+}
-String rawGroupId = coordinate.getGroupId();
-if (rawGroupId == null) {
-if ("plugin".equals(coordinate.getName())) {
-rawGroupId = "org.apache.maven.plugins";
-} else {
-// incomplete dependency
-continue;
-}
-}
-String groupId = ReleaseUtil.interpolate(rawGroupId, projectModel);
+private void rewriteArtifactVersion(
+MavenCoordinate artifact,
+Model projectModel,
+Properties properties,
+ReleaseResult result,
+ReleaseDescriptor releaseDescriptor,
+boolean simulate)
+throws ReleaseExecutionException, ReleaseFailureException {
+String projectId =
ArtifactUtils.versionlessKey(projectModel.getGroupId(),
projectModel.getArtifactId());
+String rawVersion = artifact.getVersion();
+if (rawVersion == null) {
+// managed dependency or unversioned plugin
+return;
+}
-String rawArtifactId = coordinate.getArtifactId();
-if (rawArtifactId == null) {
-// incomplete element
-continue;
-}
-String artifactId = ReleaseUtil.interpolate(rawArtifactId,
projectModel);
-
-String key = ArtifactUtils.versionlessKey(groupId, artifactId);
-String resolvedSnapshotVersion = getResolvedSnapshotVersion(key,
releaseDescriptor);
-String mappedVersion = getNextVersion(releaseDescriptor, key);
-String originalVersion = getOriginalVersion(releaseDescriptor,
key, simulate);
-if (originalVersion == null) {
-originalVersion = getOriginalResolvedSnapshotVersion(key,
releaseDescriptor);
+String rawGroupId = artifact.getGroupId();
+if (rawGroupId == null) {
+if ("plugin".equals(artifact.getName())) {
+rawGroupId = "org.apache.maven.plugins";
+} else {
+// incomplete dependency
+return;
}
+}
+String groupId = ReleaseUtil.interpolate(rawGroupId, projectModel);
-// MRELEASE-220
-if (mappedVersion != null
-&& mappedVersion.endsWith(Artifact.SNAPSHOT_VERSION)
-&& !rawVersion.endsWith(Artifact.SNAPSHOT_VERSION)
-&& !releaseDescriptor.isUpdateDependencies()) {
-continue;
-}
+String rawArtifactId = artifact.getArtifactId();
+if (rawArtifactId == null) {
+// incomplete element
+return;
+}
+String artifactId = ReleaseUtil.interpolate(rawArtifactId,
projectModel);
+
+String key = ArtifactUtils.versionlessKey(groupId, artifactId);
+String resolvedSnapshotVersion = getResolvedSnapshotVersion(key,
releaseDescriptor);
+String mappedVersion = getNextVersion(releaseDescriptor, key);
+String originalVersion = getOriginalVersion(releaseDescriptor, key,
simulate);
+if (originalVersion == null) {
+originalVersion = getOriginalResolvedSnapshotVersion(key,
releaseDescriptor);
+}
-if (mappedVersion != null) {
-if (rawVersion.equals(originalVersion)) {
-logInfo(result, " Updating " + artifactId + " to " +
mappedVersion);
-coordinate.setVersion(mappedVersion);
-} else {
-String property =
extractPropertyFromExpression(rawVersion);
-if (property != null) {
-if (property.startsWith("project.")
-
[jira] [Commented] (MPLUGINTESTING-95) Upgrade parent POM to version 43
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884055#comment-17884055 ] ASF GitHub Bot commented on MPLUGINTESTING-95: -- slachiewicz opened a new pull request, #45: URL: https://github.com/apache/maven-plugin-testing/pull/45 Cleanup deprecated code. Update to Maven 3.9.9 > Upgrade parent POM to version 43 > > > Key: MPLUGINTESTING-95 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-95 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGINTESTING-95) Upgrade parent POM to version 43
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884056#comment-17884056 ] ASF GitHub Bot commented on MPLUGINTESTING-95: -- slachiewicz merged PR #45: URL: https://github.com/apache/maven-plugin-testing/pull/45 > Upgrade parent POM to version 43 > > > Key: MPLUGINTESTING-95 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-95 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGINTESTING-95) Upgrade parent POM to version 43
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MPLUGINTESTING-95. -- Resolution: Fixed > Upgrade parent POM to version 43 > > > Key: MPLUGINTESTING-95 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-95 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MPLUGINTESTING-95) Upgrade parent POM to version 43
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MPLUGINTESTING-95: -- Assignee: Sylwester Lachiewicz > Upgrade parent POM to version 43 > > > Key: MPLUGINTESTING-95 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-95 > Project: Maven Plugin Testing > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884043#comment-17884043
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
michael-o commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1772034411
##
doxia-site-model/pom.xml:
##
@@ -84,7 +84,7 @@ under the License.
src/main/mdo/site.mdo
Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884044#comment-17884044
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
michael-o commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1772034411
##
doxia-site-model/pom.xml:
##
@@ -84,7 +84,7 @@ under the License.
src/main/mdo/site.mdo
Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884042#comment-17884042
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
michael-o commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1771964660
##
doxia-site-model/src/main/mdo/site.mdo:
##
@@ -66,6 +66,15 @@ under the License.
String
merge
+
+
+ enforceParentDescriptor
Review Comment:
Instead of `enforce` I'd use the term `requre`. E.g., `requireParentSite`.
The term `descriptor` is too confusing and too abstract for most.
##
doxia-integration-tools/src/test/java/org/apache/maven/doxia/tools/SiteToolTest.java:
##
@@ -70,46 +66,16 @@
@PlexusTest
public class SiteToolTest {
-@Inject
-private PlexusContainer container;
-
-@Inject
-private ArtifactRepositoryFactory artifactRepositoryFactory;
-
-@Inject
-@Named("default")
-private ArtifactRepositoryLayout defaultArtifactRepositoryLayout;
-
@Inject
private DefaultSiteTool tool;
-/**
- * @return the repo.
- *
- * @throws Exception
- */
-protected ArtifactRepository getLocalRepo() throws Exception {
-String updatePolicyFlag =
ArtifactRepositoryPolicy.UPDATE_POLICY_ALWAYS;
-String checksumPolicyFlag =
ArtifactRepositoryPolicy.CHECKSUM_POLICY_WARN;
-ArtifactRepositoryPolicy snapshotsPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-ArtifactRepositoryPolicy releasesPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-return artifactRepositoryFactory.createArtifactRepository(
-"local",
-getTestFile("target/local-repo").toURI().toURL().toString(),
-defaultArtifactRepositoryLayout,
-snapshotsPolicy,
-releasesPolicy);
-}
-
Review Comment:
Accepted.
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884041#comment-17884041
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
michael-o commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1771964660
##
doxia-site-model/src/main/mdo/site.mdo:
##
@@ -66,6 +66,15 @@ under the License.
String
merge
+
+
+ enforceParentDescriptor
Review Comment:
Instead of `enforce` I'd use the term 'requre'. E.g., `requireParentSite`.
The term `descriptor` is too confusing and too abstract for most.
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884040#comment-17884040
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
kwin commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1772031993
##
doxia-site-model/pom.xml:
##
@@ -84,7 +84,7 @@ under the License.
src/main/mdo/site.mdo
Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884039#comment-17884039 ] Lenny Primak commented on MGPG-137: --- Ok, I can't seem to close this by myself. Feel free to close it. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884038#comment-17884038
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
kwin commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1772030115
##
doxia-integration-tools/src/test/java/org/apache/maven/doxia/tools/SiteToolTest.java:
##
@@ -70,46 +66,16 @@
@PlexusTest
public class SiteToolTest {
-@Inject
-private PlexusContainer container;
-
-@Inject
-private ArtifactRepositoryFactory artifactRepositoryFactory;
-
-@Inject
-@Named("default")
-private ArtifactRepositoryLayout defaultArtifactRepositoryLayout;
-
@Inject
private DefaultSiteTool tool;
-/**
- * @return the repo.
- *
- * @throws Exception
- */
-protected ArtifactRepository getLocalRepo() throws Exception {
-String updatePolicyFlag =
ArtifactRepositoryPolicy.UPDATE_POLICY_ALWAYS;
-String checksumPolicyFlag =
ArtifactRepositoryPolicy.CHECKSUM_POLICY_WARN;
-ArtifactRepositoryPolicy snapshotsPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-ArtifactRepositoryPolicy releasesPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-return artifactRepositoryFactory.createArtifactRepository(
-"local",
-getTestFile("target/local-repo").toURI().toURL().toString(),
-defaultArtifactRepositoryLayout,
-snapshotsPolicy,
-releasesPolicy);
-}
-
Review Comment:
Because it was unused in the test.
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884037#comment-17884037
]
ASF GitHub Bot commented on DOXIA-740:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-doxia/pull/228#discussion_r1772028770
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexingSink.java:
##
@@ -150,14 +158,20 @@ public void text(String text, SinkEventAttributes
attributes) {
case SECTION_3:
case SECTION_4:
case SECTION_5:
+case SECTION_6:
//
---
// Sanitize the id. The most important step is to remove
any blanks
//
---
// append text to current entry
IndexEntry entry = stack.lastElement();
-String title = entry.getTitle() + text;
+String title;
Review Comment:
Done in
https://github.com/apache/maven-doxia/pull/228/commits/bd1e61ea7705af4a6a6f19ad28355a5c6807c343.
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOURCES-299) Inaccuracy on docu page for Apache Maven Resources Plugin / Filtering
[
https://issues.apache.org/jira/browse/MRESOURCES-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884029#comment-17884029
]
ASF GitHub Bot commented on MRESOURCES-299:
---
pzygielo opened a new pull request, #81:
URL: https://github.com/apache/maven-resources-plugin/pull/81
- like #80 but for master
> Inaccuracy on docu page for Apache Maven Resources Plugin / Filtering
> -
>
> Key: MRESOURCES-299
> URL: https://issues.apache.org/jira/browse/MRESOURCES-299
> Project: Maven Resources Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 3.3.1
>Reporter: Gerold Broser
>Priority: Minor
>
> {-}NB: _3.1.2_ is the max. _Affects Version/s_ that can be selected above,
> but the current docu page is for _3.3.1_ (though the following most probably
> applies since...ever){-}[does not apply here at the now right plugin; see
> comments]
> On the docu page
> [https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html]
> there's:
> {quote}However, if we add a {{}} tag to our POM and set it to
> {{true}} like this:
> {quote}
> While just {{}} really is a {_}tag{_}, we have to add a
> {{filtering}} {_}element{_}, consisting of a _start tag_ *and* an _end tag_
> (and some content in between, but that's not the point here anyway).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884025#comment-17884025
]
ASF GitHub Bot commented on DOXIA-740:
--
michael-o commented on code in PR #228:
URL: https://github.com/apache/maven-doxia/pull/228#discussion_r1772001187
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexingSink.java:
##
@@ -150,14 +158,20 @@ public void text(String text, SinkEventAttributes
attributes) {
case SECTION_3:
case SECTION_4:
case SECTION_5:
+case SECTION_6:
//
---
// Sanitize the id. The most important step is to remove
any blanks
//
---
// append text to current entry
IndexEntry entry = stack.lastElement();
-String title = entry.getTitle() + text;
+String title;
Review Comment:
I mean for the if else clause:
```
String title = entry.getTitle();
if (title != null) {
title += text;
} else {
title = text;
}
```
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884024#comment-17884024
]
ASF GitHub Bot commented on DOXIA-740:
--
kwin commented on code in PR #228:
URL: https://github.com/apache/maven-doxia/pull/228#discussion_r1771991131
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexingSink.java:
##
@@ -150,14 +158,20 @@ public void text(String text, SinkEventAttributes
attributes) {
case SECTION_3:
case SECTION_4:
case SECTION_5:
+case SECTION_6:
//
---
// Sanitize the id. The most important step is to remove
any blanks
//
---
// append text to current entry
IndexEntry entry = stack.lastElement();
-String title = entry.getTitle() + text;
+String title;
Review Comment:
Because entry.getTitle() might return null
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-740) Rendering Markdown silently truncates files that skip a heading level
[
https://issues.apache.org/jira/browse/DOXIA-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884015#comment-17884015
]
ASF GitHub Bot commented on DOXIA-740:
--
michael-o commented on code in PR #228:
URL: https://github.com/apache/maven-doxia/pull/228#discussion_r1771968627
##
doxia-core/src/main/java/org/apache/maven/doxia/index/IndexingSink.java:
##
@@ -150,14 +158,20 @@ public void text(String text, SinkEventAttributes
attributes) {
case SECTION_3:
case SECTION_4:
case SECTION_5:
+case SECTION_6:
//
---
// Sanitize the id. The most important step is to remove
any blanks
//
---
// append text to current entry
IndexEntry entry = stack.lastElement();
-String title = entry.getTitle() + text;
+String title;
Review Comment:
Why not `title = entry.getTitle()` and then `title += text`/`title = text`?
> Rendering Markdown silently truncates files that skip a heading level
> -
>
> Key: DOXIA-740
> URL: https://issues.apache.org/jira/browse/DOXIA-740
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: John Dimeo
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0
>
>
> I am using a fork of the latest Doxia site tools because I am testing my
> performance fix, so it's possible this is related to my fork, but I don't
> _think_ so...
> If your Markdown skips a heading level i.e.
> {noformat}
> # Heading 1
> Text
> ### Heading 3
> Text 2{noformat}
> Then the rendered HTML only contains Heading 1 and Text. This is a major
> regression compared to past versions, so I must be missing something. Thank
> you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-348) Extend site descriptor to enforce a parent
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884013#comment-17884013
]
ASF GitHub Bot commented on DOXIASITETOOLS-348:
---
michael-o commented on code in PR #173:
URL:
https://github.com/apache/maven-doxia-sitetools/pull/173#discussion_r1771965492
##
doxia-integration-tools/src/test/java/org/apache/maven/doxia/tools/SiteToolTest.java:
##
@@ -70,46 +66,16 @@
@PlexusTest
public class SiteToolTest {
-@Inject
-private PlexusContainer container;
-
-@Inject
-private ArtifactRepositoryFactory artifactRepositoryFactory;
-
-@Inject
-@Named("default")
-private ArtifactRepositoryLayout defaultArtifactRepositoryLayout;
-
@Inject
private DefaultSiteTool tool;
-/**
- * @return the repo.
- *
- * @throws Exception
- */
-protected ArtifactRepository getLocalRepo() throws Exception {
-String updatePolicyFlag =
ArtifactRepositoryPolicy.UPDATE_POLICY_ALWAYS;
-String checksumPolicyFlag =
ArtifactRepositoryPolicy.CHECKSUM_POLICY_WARN;
-ArtifactRepositoryPolicy snapshotsPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-ArtifactRepositoryPolicy releasesPolicy =
-new ArtifactRepositoryPolicy(true, updatePolicyFlag,
checksumPolicyFlag);
-return artifactRepositoryFactory.createArtifactRepository(
-"local",
-getTestFile("target/local-repo").toURI().toURL().toString(),
-defaultArtifactRepositoryLayout,
-snapshotsPolicy,
-releasesPolicy);
-}
-
Review Comment:
Why is this block gone?
##
doxia-site-model/src/main/mdo/site.mdo:
##
@@ -66,6 +66,15 @@ under the License.
String
merge
+
+
+ enforceParentDescriptor
Review Comment:
Instead of `enforce` I'd use the term 'requre`. E.g., `requireParentSite`.
The term `descriptor` is too confusing and too abstract for most.
> Extend site descriptor to enforce a parent
> --
>
> Key: DOXIASITETOOLS-348
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-348
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site model
>Affects Versions: 2.0.0-M19
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently the [site
> descriptor|https://maven.apache.org/doxia/doxia-sitetools/doxia-site-model/site.html]
> does not allow to enforce a parent {{site.xml}}.
> The attribute {{combine.self}} does not lead to a failure in case no parent
> {{site.xml}} can be found.
> This may easily lead to broken sites without breaking the site build as
> a) the site transparently inherits the {{site.xml}} attached to the parent
> POM.
> b) attaching the {{site.xml}} to a project is a manual step
> (https://maven.apache.org/plugins/maven-site-plugin/attach-descriptor-mojo.html)
> As at the time when the descriptor of the derived {{site.xml}} is created it
> is known whether the descriptor works standalone or requires a parent
> {{site.xml}}, therefore this should be made explicit in the site descriptor.
> I propose to add an additional attribute {{requireParent}} on the top level
> element which is {{false}} by default (current behaviour). If set to {{true}}
> it should lead to a build failure in case the parent {{site.xml}} cannot be
> resolved (for whatever reason).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-811) javadoc.bat fails to execute on Windows when project is not on drive C and AutoRun is configured
[
https://issues.apache.org/jira/browse/MJAVADOC-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884007#comment-17884007
]
Michael Osipov commented on MJAVADOC-811:
-
Can't release anything for Codehaus Plexus, need someone else to push the new
release.
> javadoc.bat fails to execute on Windows when project is not on drive C and
> AutoRun is configured
>
>
> Key: MJAVADOC-811
> URL: https://issues.apache.org/jira/browse/MJAVADOC-811
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.8.0
> Environment: Windows 10, Java 11, Maven 3.9.9
>Reporter: Sebastian T
>Assignee: Michael Osipov
>Priority: Major
>
> Trying to execute the javadoc plugin in a Maven build on Windows results in
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.8.0:jar (attach-javadocs) on
> project myproject: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - cannot read options (The system
> cannot find the file specified)
> [ERROR]
> [ERROR] Command line was: cmd.exe /X /C
> "F:\java\temurin_jdk11\bin\javadoc.exe @options @packages"[ERROR]
> [ERROR] Refer to the generated Javadoc files in
> 'F:\projects\myproject\target\apidocs' dir.
> {noformat}
> when the project is not on the system drive and
> {{HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun}} is
> configured to some directory on drive C. Then cmd.exe will not execute in the
> current directory but in the directory specified via AutoRun. This is the
> case in a corporate environment I am working in.
> The solution is trivial by adding the /D flag to cmd.exe
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883977#comment-17883977 ] Michael Osipov commented on MGPG-137: - [~cstamas], we should deprecate Plexus Cipher or reduce the amount of feature in the midrun. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883963#comment-17883963 ] Tamas Cservenak commented on MGPG-137: -- Coz it is fundamentally broken. See https://cwiki.apache.org/confluence/display/MAVEN/Handling+sensitive+data+in+Maven > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883946#comment-17883946 ] Lenny Primak commented on MGPG-137: --- So why not fix encryption? Nowhere in the public documentation does it say that it doesn't work or broken. > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8264) Deprecate m-model-builder, m-settings-builder, m-resolver-provider modules and classes
[ https://issues.apache.org/jira/browse/MNG-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-8264: Assignee: Guillaume Nodet > Deprecate m-model-builder, m-settings-builder, m-resolver-provider modules > and classes > -- > > Key: MNG-8264 > URL: https://issues.apache.org/jira/browse/MNG-8264 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-813) [REGRESSION] The given File link: X is not a dir
[
https://issues.apache.org/jira/browse/MJAVADOC-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MJAVADOC-813:
Summary: [REGRESSION] The given File link: X is not a dir (was:
[regression] The given File link: X is not a dir)
> [REGRESSION] The given File link: X is not a dir
>
>
> Key: MJAVADOC-813
> URL: https://issues.apache.org/jira/browse/MJAVADOC-813
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.10.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Attachments: javadoc-test.zip
>
>
> Given:
> {noformat}
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
> ${rootBaseDir}/java/target/apidocs/
>
> {noformat}
>
>
> Running the "attach-javadocs" goal works fine in version 3.8.0 but if I
> update to version 3.10.0 the execution fails with:
>
>
> {noformat}
> [ERROR] The given File link:
> C:\Users\Gili\Documents\requirements.java\guava\..\java\target\apidocs is not
> a dir.
> [ERROR] Error fetching link:
> C:\Users\Gili\Documents\requirements.java\guava/../java/target/apidocs/.
> Ignored it. {noformat}
>
> Under version 3.8.0 the target/apidocs directory is created and the javadoc
> is generated. Under version 3.10.0 the error is thrown and the apidocs
> directory is never created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MJAVADOC-813) [regression] The given File link: X is not a dir
[
https://issues.apache.org/jira/browse/MJAVADOC-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883913#comment-17883913
]
Michael Osipov edited comment on MJAVADOC-813 at 9/23/24 3:21 PM:
--
Well, the actual reproducer creates a chicken-and-egg problem. You cannot link
to something which is not there, but if it is not there you cannot generate it.
Here it makes on sense to do, but if you are using the wrong directory. Fix:
{noformat}
$ diff pom.xml.orig pom.xml --ignore-all-space
--- pom.xml.orig2024-09-23 17:12:31.497543000 +0200
+++ pom.xml 2024-09-23 17:16:13.386163000 +0200
@@ -35,7 +35,7 @@
https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
-
${project.basedir}/target/apidocs/
+
${project.build.directory}/reports/apidocs/
{noformat}
You haven't paid attention to the announcement:
https://www.mail-archive.com/announce@maven.apache.org/msg01478.html
MJAVADOC-560 which in turn is also
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235836144#TowardsDoxia2.0.0Stack-MavenReportingImpl4.0.0
was (Author: michael-o):
Well, the actual reproducer creates a chicken-and-egg problem. You cannot link
to something which is not there, but if it is not there you cannot generate it.
Here it makes on sense to do, but if you are using the wrong directory. Fix:
{code:patch}
$ diff pom.xml.orig pom.xml --ignore-all-space
--- pom.xml.orig2024-09-23 17:12:31.497543000 +0200
+++ pom.xml 2024-09-23 17:16:13.386163000 +0200
@@ -35,7 +35,7 @@
https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
-
${project.basedir}/target/apidocs/
+
${project.build.directory}/reports/apidocs/
{code}
You haven't paid attention to the announcement:
https://www.mail-archive.com/announce@maven.apache.org/msg01478.html
MJAVADOC-560 which in turn is also
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235836144#TowardsDoxia2.0.0Stack-MavenReportingImpl4.0.0
> [regression] The given File link: X is not a dir
>
>
> Key: MJAVADOC-813
> URL: https://issues.apache.org/jira/browse/MJAVADOC-813
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.10.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Attachments: javadoc-test.zip
>
>
> Given:
> {noformat}
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
> ${rootBaseDir}/java/target/apidocs/
>
> {noformat}
>
>
> Running the "attach-javadocs" goal works fine in version 3.8.0 but if I
> update to version 3.10.0 the execution fails with:
>
>
> {noformat}
> [ERROR] The given File link:
> C:\Users\Gili\Documents\requirements.java\guava\..\java\target\apidocs is not
> a dir.
> [ERROR] Error fetching link:
> C:\Users\Gili\Documents\requirements.java\guava/../java/target/apidocs/.
> Ignored it. {noformat}
>
> Under version 3.8.0 the target/apidocs directory is created and the javadoc
> is generated. Under version 3.10.0 the error is thrown and the apidocs
> directory is never created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-813) [regression] The given File link: X is not a dir
[
https://issues.apache.org/jira/browse/MJAVADOC-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-813.
---
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
Resolution: Information Provided
Well, the actual reproducer creates a chicken-and-egg problem. You cannot link
to something which is not there, but if it is not there you cannot generate it.
Here it makes on sense to do, but if you are using the wrong directory. Fix:
{code:patch}
$ diff pom.xml.orig pom.xml --ignore-all-space
--- pom.xml.orig2024-09-23 17:12:31.497543000 +0200
+++ pom.xml 2024-09-23 17:16:13.386163000 +0200
@@ -35,7 +35,7 @@
https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
-
${project.basedir}/target/apidocs/
+
${project.build.directory}/reports/apidocs/
{code}
You haven't paid attention to the announcement:
https://www.mail-archive.com/announce@maven.apache.org/msg01478.html
MJAVADOC-560 which in turn is also
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=235836144#TowardsDoxia2.0.0Stack-MavenReportingImpl4.0.0
> [regression] The given File link: X is not a dir
>
>
> Key: MJAVADOC-813
> URL: https://issues.apache.org/jira/browse/MJAVADOC-813
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.10.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Attachments: javadoc-test.zip
>
>
> Given:
> {noformat}
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
> ${rootBaseDir}/java/target/apidocs/
>
> {noformat}
>
>
> Running the "attach-javadocs" goal works fine in version 3.8.0 but if I
> update to version 3.10.0 the execution fails with:
>
>
> {noformat}
> [ERROR] The given File link:
> C:\Users\Gili\Documents\requirements.java\guava\..\java\target\apidocs is not
> a dir.
> [ERROR] Error fetching link:
> C:\Users\Gili\Documents\requirements.java\guava/../java/target/apidocs/.
> Ignored it. {noformat}
>
> Under version 3.8.0 the target/apidocs directory is created and the javadoc
> is generated. Under version 3.10.0 the error is thrown and the apidocs
> directory is never created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-99) Passcode byte array provided to gpg executable on stdin is not terminated
[ https://issues.apache.org/jira/browse/MGPG-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883904#comment-17883904 ] Tamas Cservenak commented on MGPG-99: - I know this issue is closed, but possible would like to know following: * OS * Java * env (anything specific) * Maven version > 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 >Assignee: Tamas Cservenak >Priority: Minor > Fix For: 3.2.0 > > 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] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883902#comment-17883902 ] Tamas Cservenak commented on MGPG-136: -- [~cowwoc] I created this https://github.com/ralfkonrad/test-mvn-gpg-plugin/pull/27 but needs auth. You can try same if you can. > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883900#comment-17883900 ] Gili commented on MGPG-136: --- Hi Tamas, Thanks for the follow-up... The reason that I see *** in place of the secret is that I'm running the command under a GitHub Action. It is GitHub that is hiding the output, not toolbox itself. With respect to my passphrase, the unencrypted version is purely alphanumeric so no, I don't expect any characters outside the 7bit range. Let me know if there is anything else I can do to help tracking down this issue. If you release a snapshot version or something I can try running it under Github again. > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-813) [regression] The given File link: X is not a dir
[
https://issues.apache.org/jira/browse/MJAVADOC-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883897#comment-17883897
]
Gili commented on MJAVADOC-813:
---
Please extract javadoc-test.zip and run "mvn clean install". I'm not sure why
this error would be expected. Do you expect the user to somehow create this
directory on behalf of the plugin?
> [regression] The given File link: X is not a dir
>
>
> Key: MJAVADOC-813
> URL: https://issues.apache.org/jira/browse/MJAVADOC-813
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.10.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: wontfix-candidate, waiting-for-feedback
>
> Attachments: javadoc-test.zip
>
>
> Given:
> {noformat}
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
> ${rootBaseDir}/java/target/apidocs/
>
> {noformat}
>
>
> Running the "attach-javadocs" goal works fine in version 3.8.0 but if I
> update to version 3.10.0 the execution fails with:
>
>
> {noformat}
> [ERROR] The given File link:
> C:\Users\Gili\Documents\requirements.java\guava\..\java\target\apidocs is not
> a dir.
> [ERROR] Error fetching link:
> C:\Users\Gili\Documents\requirements.java\guava/../java/target/apidocs/.
> Ignored it. {noformat}
>
> Under version 3.8.0 the target/apidocs directory is created and the javadoc
> is generated. Under version 3.10.0 the error is thrown and the apidocs
> directory is never created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-813) [regression] The given File link: X is not a dir
[
https://issues.apache.org/jira/browse/MJAVADOC-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated MJAVADOC-813:
--
Attachment: javadoc-test.zip
> [regression] The given File link: X is not a dir
>
>
> Key: MJAVADOC-813
> URL: https://issues.apache.org/jira/browse/MJAVADOC-813
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.10.0
>Reporter: Gili
>Assignee: Michael Osipov
>Priority: Major
> Fix For: wontfix-candidate, waiting-for-feedback
>
> Attachments: javadoc-test.zip
>
>
> Given:
> {noformat}
>
>
>
> https://cowwoc.github.io/requirements.java/${project.version}/docs/api/
> ${rootBaseDir}/java/target/apidocs/
>
> {noformat}
>
>
> Running the "attach-javadocs" goal works fine in version 3.8.0 but if I
> update to version 3.10.0 the execution fails with:
>
>
> {noformat}
> [ERROR] The given File link:
> C:\Users\Gili\Documents\requirements.java\guava\..\java\target\apidocs is not
> a dir.
> [ERROR] Error fetching link:
> C:\Users\Gili\Documents\requirements.java\guava/../java/target/apidocs/.
> Ignored it. {noformat}
>
> Under version 3.8.0 the target/apidocs directory is created and the javadoc
> is generated. Under version 3.10.0 the error is thrown and the apidocs
> directory is never created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883881#comment-17883881 ] ASF GitHub Bot commented on MGPG-136: - cstamas opened a new pull request, #120: URL: https://github.com/apache/maven-gpg-plugin/pull/120 This is shot in a dark, but should make possible to at least eliminate (if not even figure out) the issue on Windows with passphrase. --- https://issues.apache.org/jira/browse/MGPG-136 > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-405) No release notes for 3.25.0 on https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html
[ https://issues.apache.org/jira/browse/MPMD-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883856#comment-17883856 ] Michael Osipov commented on MPMD-405: - I agree with you Gary. Either provide correct information or no information at all. > No release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html > -- > > Key: MPMD-405 > URL: https://issues.apache.org/jira/browse/MPMD-405 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > HI All, > There are no release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-405) No release notes for 3.25.0 on https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html
[ https://issues.apache.org/jira/browse/MPMD-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883847#comment-17883847 ] Gary D. Gregory commented on MPMD-405: -- Up to you guys of course ;-) just think of us users trying to find out what went wrong where and how... > No release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html > -- > > Key: MPMD-405 > URL: https://issues.apache.org/jira/browse/MPMD-405 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > HI All, > There are no release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[
https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883844#comment-17883844
]
Tamas Cservenak commented on MGPG-136:
--
[~cowwoc] *wait a sec...* you say "I used the command you mentioned and it
confirms that "env.MAVEN_GPG_PASSPHRASE" contains a secret value (the value
shows up as ***)."?
That is weird, as Toolbox (the command I said to run), does not hide sensitive
values as it have no idea which one is sensitive!
I just tested it:
{noformat}
$ MAVEN_GPG_PASSPHRASE=bigSecretNobodyCanSee mvn
eu.maveniverse.maven.plugins:toolbox:0.3.2:dump -Dverbosity=CHATTER
...
[INFO] env.MAVEN_CMD_LINE_ARGS=
eu.maveniverse.maven.plugins:toolbox:0.3.2:dump -Dverbosity=CHATTER
[INFO] env.MAVEN_GPG_PASSPHRASE=bigSecretNobodyCanSee
[INFO]
env.MAVEN_HOME=/home/cstamas/.sdkman/candidates/maven/current
...
{noformat}
This means your passphrase is ""
> "gpg: signing failed: Bad passphrase" on GitHub Windows runners
> ---
>
> Key: MGPG-136
> URL: https://issues.apache.org/jira/browse/MGPG-136
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home:
> C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6
> Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime:
> C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows server 2022", version: "10.0", arch: "aarch64", family:
> "windows"
>Reporter: Gili
>Priority: Critical
>
> Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on
> GitHub Windows Runners.
> Using Linux or downgrading to version 3.1.0 seems to work fine.
> It's not clear what changed in these newer versions but
> [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368]
> looks like a highly supicious way of reading environment variables. It's
> possible that this approach does not work properly under Powershell.
> If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get
> back the correct value, so it sounds like there is a bug in the way that this
> plugin is choosing to read the environment variable.
> What makes this a bit tricky, however, is that the environment variable is
> called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and
> $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell
> variant.
> Can you guys please look into this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883841#comment-17883841 ] Tamas Cservenak commented on MGPG-136: -- So two issues: * possible encoding issues here: Java def encoding is used to fill in ByteArrayInputStream, that is later as-is used to feed process. On Linux/mac the java encoding is usually == console encoding == utf8, while this AFAIK is not true for window? https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L115-L120 * possible passphrase corruption as well, by adding System.lineSeparator() ? > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883839#comment-17883839 ] Tamas Cservenak commented on MGPG-136: -- In 3.1.0 the process input creation was like this: https://github.com/apache/maven-gpg-plugin/blob/maven-gpg-plugin-3.1.0/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L105-L106 So it seems Windows is getting passphrase+newline? Hence GPG declares it as "bad passphrase"? Again, am unsure how Windows behave in this respect... [~michael-o] Help! > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-405) No release notes for 3.25.0 on https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html
[ https://issues.apache.org/jira/browse/MPMD-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883836#comment-17883836 ] Michael Osipov commented on MPMD-405: - [~ggregory], I agree with you, but that decision should be taken for the entire Maven TLP to make it consistent. In this specific case I'd simply delete it. Done. > No release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html > -- > > Key: MPMD-405 > URL: https://issues.apache.org/jira/browse/MPMD-405 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > HI All, > There are no release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[
https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883832#comment-17883832
]
Tamas Cservenak commented on MGPG-136:
--
But I found a "sus" place myself, but for this to confirm, I'd need some
answers: do your passphrases contains some character that is beyond 7bit ASCII?
https://github.com/apache/maven-gpg-plugin/blob/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L115-L120
This place smells like it lacks some encoding, as "usually" Mac and Linuxes are
UTF8, but AFAIK Windows is stubborn on that {{chcp 65001}}?
> "gpg: signing failed: Bad passphrase" on GitHub Windows runners
> ---
>
> Key: MGPG-136
> URL: https://issues.apache.org/jira/browse/MGPG-136
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home:
> C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6
> Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime:
> C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows server 2022", version: "10.0", arch: "aarch64", family:
> "windows"
>Reporter: Gili
>Priority: Critical
>
> Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on
> GitHub Windows Runners.
> Using Linux or downgrading to version 3.1.0 seems to work fine.
> It's not clear what changed in these newer versions but
> [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368]
> looks like a highly supicious way of reading environment variables. It's
> possible that this approach does not work properly under Powershell.
> If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get
> back the correct value, so it sounds like there is a bug in the way that this
> plugin is choosing to read the environment variable.
> What makes this a bit tricky, however, is that the environment variable is
> called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and
> $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell
> variant.
> Can you guys please look into this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883827#comment-17883827 ] Tamas Cservenak edited comment on MGPG-136 at 9/23/24 11:10 AM: Howdy Gili, thanks for reaching back with new info, and sorry for a bit late response. You pointed at line that is "highly suspicious way of reading environment variables", so let me start there: Maven at "boot" collects Java System Properties and env variables into Maven System Properties (not to be confused with Java System Properties, that are ONE SOURCE of these). Same things happens in Toolbox (and there you confirmed that env.MAVEN_GPG_PASSPHRASE contains a secret value). And don't be confused, the "env." prefix is nothing to do with PowerShell or whatever, it is really just Maven: See https://github.com/apache/maven/blob/45201347c417896b57159221130333f5fa4bbfb6/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1485 And https://github.com/apache/maven/blob/45f9b81b4a8451a75864ef1c861c5bb201a54790/maven-core/src/main/java/org/apache/maven/properties/internal/EnvironmentUtils.java#L34 In short, Maven system properties contain Java System Properties (as is) AND env variables where key are prefixed with "env.". Hence the way of "reading". Also, just like between Linux/MacOS/Windows, these differences _should_ be handled by Java, am pretty sceptic that in Java you should key env variable differently based on cmd/powershell... or if this is the case on Windows, than this platform is eeek. was (Author: cstamas): Howdy Gili, thanks for reaching back with new info, and sorry for a bit late response. You pointed at line that is "highly suspicious way of reading environment variables", so let me start there: Maven at "boot" collects Java System Properties and env variables into Maven System Properties (not to be confused with Java System Properties, that are ONE SOURCE of these). Same things happens in Toolbox (and there you confirmed that env.MAVEN_GPG_PASSPHRASE contains a secret value). And don't be confused, the "env." prefix is nothing to do with PowerShell or whatever, it is really just Maven: See https://github.com/apache/maven/blob/45201347c417896b57159221130333f5fa4bbfb6/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1485 And https://github.com/apache/maven/blob/45f9b81b4a8451a75864ef1c861c5bb201a54790/maven-core/src/main/java/org/apache/maven/properties/internal/EnvironmentUtils.java#L34 In short, Maven system properties contain Java System Properties (as is) AND env variables where key are prefixed with "env.". Hence the way of "reading". Also, just like between Linux/MacOS/Windows, these differences _should_ be handled by Java, am pretty sceptic that in Java you should key env variable differently based on cmd/powershell... or if this is the case on Windows, that this platform is eeek. > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-136) "gpg: signing failed: Bad passphrase" on GitHub Windows runners
[ https://issues.apache.org/jira/browse/MGPG-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883827#comment-17883827 ] Tamas Cservenak commented on MGPG-136: -- Howdy Gili, thanks for reaching back with new info, and sorry for a bit late response. You pointed at line that is "highly suspicious way of reading environment variables", so let me start there: Maven at "boot" collects Java System Properties and env variables into Maven System Properties (not to be confused with Java System Properties, that are ONE SOURCE of these). Same things happens in Toolbox (and there you confirmed that env.MAVEN_GPG_PASSPHRASE contains a secret value). And don't be confused, the "env." prefix is nothing to do with PowerShell or whatever, it is really just Maven: See https://github.com/apache/maven/blob/45201347c417896b57159221130333f5fa4bbfb6/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1485 And https://github.com/apache/maven/blob/45f9b81b4a8451a75864ef1c861c5bb201a54790/maven-core/src/main/java/org/apache/maven/properties/internal/EnvironmentUtils.java#L34 In short, Maven system properties contain Java System Properties (as is) AND env variables where key are prefixed with "env.". Hence the way of "reading". Also, just like between Linux/MacOS/Windows, these differences _should_ be handled by Java, am pretty sceptic that in Java you should key env variable differently based on cmd/powershell... or if this is the case on Windows, that this platform is eeek. > "gpg: signing failed: Bad passphrase" on GitHub Windows runners > --- > > Key: MGPG-136 > URL: https://issues.apache.org/jira/browse/MGPG-136 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5 > Environment: Apache Maven 3.9.6 > (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: > C:\Users\runneradmin\.m2\wrapper\dists\apache-maven-3.9.6-bin\3311e1d4\apache-maven-3.9.6 > Java version: 1.8.0_422, vendor: Azul Systems, Inc., runtime: > C:\hostedtoolcache\windows\Java_Zulu_jdk\8.0.422-5\x64\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows server 2022", version: "10.0", arch: "aarch64", family: > "windows" >Reporter: Gili >Priority: Critical > > Version 3.2.0 - 3.2.5 fail with "gpg: signing failed: Bad passphrase" on > GitHub Windows Runners. > Using Linux or downgrading to version 3.1.0 seems to work fine. > It's not clear what changed in these newer versions but > [https://github.com/apache/maven-gpg-plugin/blob/3a31714e9cbdde86a6b12f1ef05d5c60252fef4a/src/main/java/org/apache/maven/plugins/gpg/AbstractGpgMojo.java#L368] > looks like a highly supicious way of reading environment variables. It's > possible that this approach does not work properly under Powershell. > If I echo "$env:MAVEN_GPG_PASSPHRASE" on the GitHub Windows runner, I get > back the correct value, so it sounds like there is a bug in the way that this > plugin is choosing to read the environment variable. > What makes this a bit tricky, however, is that the environment variable is > called $MAVEN_GPG_PASSPHRASE on Linux, %MAVEN_GPG_PASSPHRASE% on cmd.exe and > $env:MAVEN_GPG_PASSPHRASE on Powershell. GitHub is using the Powershell > variant. > Can you guys please look into this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-405) No release notes for 3.25.0 on https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html
[ https://issues.apache.org/jira/browse/MPMD-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883821#comment-17883821 ] Gary D. Gregory commented on MPMD-405: -- I think it would be nice for the site to point to the release notes history, wherever they live. > No release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html > -- > > Key: MPMD-405 > URL: https://issues.apache.org/jira/browse/MPMD-405 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > HI All, > There are no release notes for 3.25.0 on > https://maven.apache.org/plugins/maven-pmd-plugin/releasenotes.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MGPG-137) Un-deprecate passphraseServerId
[ https://issues.apache.org/jira/browse/MGPG-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883817#comment-17883817 ] Tamas Cservenak commented on MGPG-137: -- Is not safer at all, "encryption" is really just obfuscation by obscurity, moreover, that "encryption" is even broken (as can be seen from plexus-cipher changes). > Un-deprecate passphraseServerId > --- > > Key: MGPG-137 > URL: https://issues.apache.org/jira/browse/MGPG-137 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.2.5 >Reporter: Lenny Primak >Priority: Major > > IMHO this parameter has been deprecated in error. > It is used to referenced the "server" field in settings.xml, where > passphrases are stored in an encrypted fashion. This is actually safer than > setting clear-text passwords in environment variables in practice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
