[jira] [Updated] (MNG-7883) Also print groupId and version in the Reactor Build Order
[
https://issues.apache.org/jira/browse/MNG-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reto Hoehener updated MNG-7883:
---
Priority: Trivial (was: Major)
> Also print groupId and version in the Reactor Build Order
> -
>
> Key: MNG-7883
> URL: https://issues.apache.org/jira/browse/MNG-7883
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Reto Hoehener
>Priority: Trivial
>
> This would be useful information when debugging a build process:
> {code:java}
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] my-groupmy-parent1.0.0-SNAPSHOT
> [pom]
> [INFO] my-groupmy-lib 1.0.0-SNAPSHOT
> [jar]
> [INFO] my-groupmy-app 1.0.4
> [jar] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7884) Add a command line option to just print the reactor build order
Reto Hoehener created MNG-7884: -- Summary: Add a command line option to just print the reactor build order Key: MNG-7884 URL: https://issues.apache.org/jira/browse/MNG-7884 Project: Maven Issue Type: New Feature Reporter: Reto Hoehener This would be a useful flag to analyze a build process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7885) Plugin dependencies should be part in dependency management
Lars Uffmann created MNG-7885:
-
Summary: Plugin dependencies should be part in dependency
management
Key: MNG-7885
URL: https://issues.apache.org/jira/browse/MNG-7885
Project: Maven
Issue Type: Improvement
Components: Dependencies
Reporter: Lars Uffmann
It would be a great improvement in dependency management if plugin dependencies
could be part of the standard dependency management resolution. In the example
below I could manage the version of the rewrite-maven-plugin using
pluginManagement, the version of the rewrite-spring plugin dependency however
has to be set in place.
{code:java}
org.openrewrite.maven
rewrite-maven-plugin
org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration
org.openrewrite.recipe
rewrite-spring
4.35.0
{code}
Other plugins are using special configurations to declare extra dependencies.
The version. management issue however is the same. A good example is
_annotationProcessorPaths_ of the compiler plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7886) Do not warn (or improve warning message) if a profile exists only in the reactor pom, but not in the selected module.
Reto Hoehener created MNG-7886:
--
Summary: Do not warn (or improve warning message) if a profile
exists only in the reactor pom, but not in the selected module.
Key: MNG-7886
URL: https://issues.apache.org/jira/browse/MNG-7886
Project: Maven
Issue Type: Improvement
Reporter: Reto Hoehener
No warning:
{code:java}
mvn -f aggregator/pom.xml -P test-profile validate{code}
Warning:
{code:java}
mvn -f aggregator/pom.xml -P test-profile -pl :module-1 validate
[INFO] Scanning for projects...
[WARNING] The requested profile "test-profile" could not be activated because
it does not exist. {code}
The build is successful, and the aggregator profile is activated correctly.
*Improvement suggestion:*
Do not warn at all, or:
{code:java}
[WARNING] The requested profile "test-profile" could only be activated in the
reactor pom, but does not exist in the selected module "module-1" (this can be
intended).{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7886) Do not warn (or improve warning message) if a profile exists only in the reactor pom, but not in the selected module.
[
https://issues.apache.org/jira/browse/MNG-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reto Hoehener updated MNG-7886:
---
Attachment: test.zip
> Do not warn (or improve warning message) if a profile exists only in the
> reactor pom, but not in the selected module.
> -
>
> Key: MNG-7886
> URL: https://issues.apache.org/jira/browse/MNG-7886
> Project: Maven
> Issue Type: Improvement
>Reporter: Reto Hoehener
>Priority: Minor
> Attachments: test.zip
>
>
> No warning:
> {code:java}
> mvn -f aggregator/pom.xml -P test-profile validate{code}
> Warning:
> {code:java}
> mvn -f aggregator/pom.xml -P test-profile -pl :module-1 validate
> [INFO] Scanning for projects...
> [WARNING] The requested profile "test-profile" could not be activated because
> it does not exist. {code}
> The build is successful, and the aggregator profile is activated correctly.
> *Improvement suggestion:*
> Do not warn at all, or:
> {code:java}
> [WARNING] The requested profile "test-profile" could only be activated in the
> reactor pom, but does not exist in the selected module "module-1" (this can
> be intended).{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7886) Do not warn (or improve warning message) if a profile exists only in the reactor pom, but not in the selected module.
[
https://issues.apache.org/jira/browse/MNG-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reto Hoehener updated MNG-7886:
---
Affects Version/s: 3.9.4
> Do not warn (or improve warning message) if a profile exists only in the
> reactor pom, but not in the selected module.
> -
>
> Key: MNG-7886
> URL: https://issues.apache.org/jira/browse/MNG-7886
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.9.4
>Reporter: Reto Hoehener
>Priority: Minor
> Attachments: test.zip
>
>
> No warning:
> {code:java}
> mvn -f aggregator/pom.xml -P test-profile validate{code}
> Warning:
> {code:java}
> mvn -f aggregator/pom.xml -P test-profile -pl :module-1 validate
> [INFO] Scanning for projects...
> [WARNING] The requested profile "test-profile" could not be activated because
> it does not exist. {code}
> The build is successful, and the aggregator profile is activated correctly.
> *Improvement suggestion:*
> Do not warn at all, or:
> {code:java}
> [WARNING] The requested profile "test-profile" could only be activated in the
> reactor pom, but does not exist in the selected module "module-1" (this can
> be intended).{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7885) Plugin dependencies should be part in dependency management
[
https://issues.apache.org/jira/browse/MNG-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765486#comment-17765486
]
Lars Uffmann commented on MNG-7885:
---
The maven compiler-plugin use case. I could add mapstruct-processor and lombok
as an optional compile time dependency and their versions would be part of
standard dependency management mechanism.
{code:java}
org.apache.maven.plugins
maven-compiler-plugin
org.mapstruct
mapstruct-processor
${mapstruct.version}
org.projectlombok
lombok
${lombok.version}
{code}
> Plugin dependencies should be part in dependency management
> ---
>
> Key: MNG-7885
> URL: https://issues.apache.org/jira/browse/MNG-7885
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Lars Uffmann
>Priority: Major
>
> It would be a great improvement in dependency management if plugin
> dependencies could be part of the standard dependency management resolution.
> In the example below I could manage the version of the rewrite-maven-plugin
> using pluginManagement, the version of the rewrite-spring plugin dependency
> however has to be set in place.
>
>
> {code:java}
>
>
>
> org.openrewrite.maven
> rewrite-maven-plugin
>
>
>
> org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration
>
>
>
>
> org.openrewrite.recipe
> rewrite-spring
> 4.35.0
>
>
>
>
> {code}
>
>
> Other plugins are using special configurations to declare extra dependencies.
> The version. management issue however is the same. A good example is
> _annotationProcessorPaths_ of the compiler plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7885) Plugin dependencies should be part in dependency management
[
https://issues.apache.org/jira/browse/MNG-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765490#comment-17765490
]
Slawomir Jaranowski commented on MNG-7885:
--
[~cachescrubber] for annotationProcessorPaths we have a fix: MCOMPILER-391
> Plugin dependencies should be part in dependency management
> ---
>
> Key: MNG-7885
> URL: https://issues.apache.org/jira/browse/MNG-7885
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Lars Uffmann
>Priority: Major
>
> It would be a great improvement in dependency management if plugin
> dependencies could be part of the standard dependency management resolution.
> In the example below I could manage the version of the rewrite-maven-plugin
> using pluginManagement, the version of the rewrite-spring plugin dependency
> however has to be set in place.
>
>
> {code:java}
>
>
>
> org.openrewrite.maven
> rewrite-maven-plugin
>
>
>
> org.openrewrite.java.spring.boot2.SpringBoot2JUnit4to5Migration
>
>
>
>
> org.openrewrite.recipe
> rewrite-spring
> 4.35.0
>
>
>
>
> {code}
>
>
> Other plugins are using special configurations to declare extra dependencies.
> The version. management issue however is the same. A good example is
> _annotationProcessorPaths_ of the compiler plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MINSTALL-191) Metadata for submodules seems to be incomplete
Dorian Vallant created MINSTALL-191:
---
Summary: Metadata for submodules seems to be incomplete
Key: MINSTALL-191
URL: https://issues.apache.org/jira/browse/MINSTALL-191
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 3.1.1, 3.1.0, 3.0.0, 3.0.0-M1
Environment: Apache Maven 3.8.8
(4c87b05d9aedce574290d1acc98575ed5eb6cd39)
Java version: 11.0.18, vendor: Eclipse Adoptium
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
Reporter: Dorian Vallant
Attachments: maven-install-plugin-bug.tgz
maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a bug
when generating maven-metadata-*.xml for submodules containing custom
maven-plugins.
With version 2.5.2 maven-install-plugin generates the local metadata as follows:
{code:xml}
at.dvallant.maven
plugins
0.1.0-SNAPSHOT
20230831082036
my-maven-plugin
my
my-maven-plugin
{code}
After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
generated file looks this:
{code:xml}
at.dvallant.maven
plugins
0.1.0-SNAPSHOT
20230831082207
{code}
A test-project to reproduce the issue is attached.
To reproduce build the project by calling `mvn clean install` and then check
the contents of
`~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
If you downgrade the version to 2.5.2, metadata generation works as expected.
If you could give me a hint where the problem might be in the code I can try to
fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] olamy commented on a diff in pull request #449: Improvements to release procedure
olamy commented on code in PR #449:
URL: https://github.com/apache/maven-site/pull/449#discussion_r1326967875
##
content/apt/developers/release/maven-project-release-procedure.apt:
##
@@ -60,6 +62,38 @@ Performing a Maven Project Release
If the item you are planning to release is not using the most recent version
of its parent
(see {{{../../pom/}parent POMs}} index), consider taking this opportunity to
update to it.
+* Consider updating the project dependencies
+
+ Generally it is a good that project use tha latest available versions of
used dependencies.
+
+* Prepare release notes
+
+ * check all commits since latest release, all mentioned issue should be
connected with release notes
+
+ * all issues should be fixed and <>
+
+ * all issues should be <> to responsible person, which fixed or
merged fix
+
+ * check existing issues with <> priority, consider to fix it or
change priority if reasonable
+
+ []
+
+** Check release note at GitHub
+
+ If a component has a history of release notes at <>, we should to
continue maintain it in order to avoid user confusing.
+
+ We can maintain release notes at <>, by one of:
+
+ * use release-drafter to help prepare release notes - in such case all PRs
should a proper label
Review Comment:
just look at this
https://github.com/apache/maven-compiler-plugin/releases/tag/maven-compiler-plugin-3.11.0
each PR have an appropriate label/category so there are ordered
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765512#comment-17765512
]
Michael Osipov commented on MINSTALL-191:
-
[~cstamas]
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] GitPopcorn opened a new issue, #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
GitPopcorn opened a new issue, #883: URL: https://github.com/apache/maven-mvnd/issues/883 The same problem has been solved as issue #567, but don't know why it now appears again. Here is my console output when test, you can see the platform encoding can not be changed with command line argument "-Dfile.encoding" or "-DjvmArgs". No enviroment variable like `MVN_OPTS` or `JAVA_TOOLS_OPTIONS` affects. And the same arguments in `~/.m2/mvnd.properties` will not work either. ``` E:\>"E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\bin\mvnd.exe" -v mvnd 0.8.2 windows-amd64 native client (2bba2d6a4d3a5012ddf9f1f42a22784cad4011e3) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\bin\mvnd.exe" -Dfile.encoding=GBK -v mvnd 0.8.2 windows-amd64 native client (2bba2d6a4d3a5012ddf9f1f42a22784cad4011e3) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: GBK OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\bin\mvnd.exe" -Dfile.encoding=UTF-8 -v mvnd 0.8.2 windows-amd64 native client (2bba2d6a4d3a5012ddf9f1f42a22784cad4011e3) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: E:\choco\mvndaemon\maven-mvnd-0.8.2-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\bin\mvnd.exe" -v Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it. Apache Maven Daemon (mvnd) 1.0-m7 windows-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) Maven home: E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\bin\mvnd.exe" -Dfile.encoding=GBK -v Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it. Apache Maven Daemon (mvnd) 1.0-m7 windows-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) Maven home: E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\bin\mvnd.exe" -Dfile.encoding=UTF-8 -v Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it. Apache Maven Daemon (mvnd) 1.0-m7 windows-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) Maven home: E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\mvn Java version: 19, vendor: Oracle Corporation, runtime: D:\Program Files\Java\jdk-19 Default locale: zh_CN, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" E:\>"E:\choco\mvndaemon\maven-mvnd-1.0-m7-m40-windows-amd64\bin\mvnd.exe" -DjvmArgs=-Dfile.encoding\=GBK -v Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it. Apache Maven Daemon (mvnd) 1.0-m7 w
[GitHub] [maven-mvnd] GitPopcorn opened a new issue, #885: The CJK characters in stderr are displayed as "?" after mvnd 1.0-m6-39 in Windows
GitPopcorn opened a new issue, #885:
URL: https://github.com/apache/maven-mvnd/issues/885
The CJK characters in stderr are displayed as "?" after mvnd
1.0-m6-39.md in Windows
Probably related issue: #883
Things like:
- Correct display:
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project tfpay-notify-api: Compilation failure
[ERROR]
/E:/workspace-test/maven-group/maven-cjk-char-display-error-demo/src/main/java/org/apache/maven/daemon/test/TestType.java:[17,66]
找不到符号
[ERROR] 符号: 类 TestParam123
[ERROR] 位置: 接口 org.apache.maven.daemon.test.TestType
```
- Wrong display:
```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project tfpay-notify-api: Compilation failure
[ERROR]
/E:/workspace-test/maven-group/maven-cjk-char-display-error-demo/src/main/java/org/apache/maven/daemon/test/TestType.java:[17,66]
?
[ERROR] ??: ? TestParam123
[ERROR] ??: ?? org.apache.maven.daemon.test.TestType
```
The command line tools seems dose not affect to this, I have test with
`CMD/PowerShell/Git Bash/Node.JS process API`. The output from Maven Daemon is
just "?" and can not be decode correctly any way.
The wrong decoding result "?" usually comes from `encode with UTF-8 ->
decode with GBK -> encode with UTF-8 -> decode with GBK`.
At first I think the changes of Maven 4.0.0-alpha caused this, but then I
test it with several different `Mvn Daemon/JDK/Character Page` and finally
found that it is only related to the version of Maven Daemon:
- `Maven Daemon 0.9.0 (Maven 3.8.7) + CHCP 936 (GBK) + JDK
1.8.0 : Correct`
- `Maven Daemon 0.9.0 (Maven 3.8.7) + CHCP 936 (GBK) + JDK
19 : Correct`
- `Maven Daemon 0.9.0 (Maven 3.8.7) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Correct`
- `Maven Daemon 0.9.0 (Maven 3.8.7) + CHCP 65001 (UTF-8) + JDK
19 : Correct`
- `Maven Daemon 1.0.0-m4 (Maven 4.0.0-alpha-4) + CHCP 936 (GBK) + JDK
1.8.0 : Correct`
- `Maven Daemon 1.0.0-m4 (Maven 4.0.0-alpha-4) + CHCP 936 (GBK) + JDK
19 : Correct`
- `Maven Daemon 1.0.0-m4 (Maven 4.0.0-alpha-4) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Correct`
- `Maven Daemon 1.0.0-m4 (Maven 4.0.0-alpha-4) + CHCP 65001 (UTF-8) + JDK
19 : Correct`
- `Maven Daemon 1.0-m6-39 (Maven 3.9.1) + CHCP 936 (GBK) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m6-39 (Maven 3.9.1) + CHCP 936 (GBK) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m6-39 (Maven 3.9.1) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m6-39 (Maven 3.9.1) + CHCP 65001 (UTF-8) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m6-40 (Maven 4.0.0-alpha-5) + CHCP 936 (GBK) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m6-40 (Maven 4.0.0-alpha-5) + CHCP 936 (GBK) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m6-40 (Maven 4.0.0-alpha-5) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m6-40 (Maven 4.0.0-alpha-5) + CHCP 65001 (UTF-8) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m7-39 (Maven 3.9.3) + CHCP 936 (GBK) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m7-39 (Maven 3.9.3) + CHCP 936 (GBK) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m7-39 (Maven 3.9.3) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m7-39 (Maven 3.9.3) + CHCP 65001 (UTF-8) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m7-40 (Maven 4.0.0-alpha-7) + CHCP 936 (GBK) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m7-40 (Maven 4.0.0-alpha-7) + CHCP 936 (GBK) + JDK
19 : Wrong`
- `Maven Daemon 1.0-m7-40 (Maven 4.0.0-alpha-7) + CHCP 65001 (UTF-8) + JDK
1.8.0 : Wrong`
- `Maven Daemon 1.0-m7-40 (Maven 4.0.0-alpha-7) + CHCP 65001 (UTF-8) + JDK
19 : Wrong`
In fact I don't know how to stably print CJK characters in a english
command-line environment, so I'm sorry I cannot provide a smallest demo to
reproduce this issue, cause those CJK characters are all from the compilation
error message. But I'm pretty sure there was something changed from `1.0-m6`
version to cause this issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
Francisco Bento da Silva Neto created MNG-7887:
--
Summary: cannot inject ci-friendly revision/sha1/changelist
properties via MAVEN_OPTS
Key: MNG-7887
URL: https://issues.apache.org/jira/browse/MNG-7887
Project: Maven
Issue Type: Bug
Affects Versions: 3.9.4, 3.9.3, 3.9.2, 3.9.1, 3.9.0
Reporter: Francisco Bento da Silva Neto
h1. Intro
Prior to 3.9.x, it was possible to inject the
[ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
MAVEN_OPTS.
After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
Curiously, setting user properties other than the ci-friendly specific
properties via MAVEN_OPTS never worked, even on 3.8.x.
h1. Reproducing
Given the {_}pom.xml{_}:
{noformat}
4.0.0
com.acme
property-bug
1.0.0
pom
pomValue
pomValue
maven-antrun-plugin
generate-resources
run
echoing revision ${revision} revision2 ${revision2}
{noformat}
If I run:
{noformat}
MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn help:effective-pom
| grep revision{noformat}
On *3.8.9-* I get:
{noformat}
optsValue
pomValue
echoing revision optsValue revision2
pomValue{noformat}
On *3.9.0+* I get:
{code:java}
pomValue
pomValue
echoing revision optsValue revision2 pomValue
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765672#comment-17765672
]
Michael Osipov commented on MNG-7887:
-
This is somewhat deliberate decision: In the past there was a hodgepodge and no
clear definition what is a system property or user property. Starting with
Maven 3.9 we are cleaning this up. User properties can only be passed via CLI,
file or {{MAVEN_ARGS}}. {{MAVEN_OPTS}} are solely designed to pass properties
to the JVM, not Maven.
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
>
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765672#comment-17765672
]
Michael Osipov edited comment on MNG-7887 at 9/15/23 2:41 PM:
--
This is a somewhat deliberate decision: In the past there was a hodgepodge and
no clear definition what is a system property or user property. Starting with
Maven 3.9 we are cleaning this up. User properties can only be passed via CLI,
file or {{MAVEN_ARGS}}. {{MAVEN_OPTS}} are solely designed to pass properties
to the JVM, not Maven.
was (Author: michael-o):
This is somewhat deliberate decision: In the past there was a hodgepodge and no
clear definition what is a system property or user property. Starting with
Maven 3.9 we are cleaning this up. User properties can only be passed via CLI,
file or {{MAVEN_ARGS}}. {{MAVEN_OPTS}} are solely designed to pass properties
to the JVM, not Maven.
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
>
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francisco Bento da Silva Neto updated MNG-7887:
---
Description:
h1. Intro
Prior to 3.9.x, it was possible to inject the
[ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
MAVEN_OPTS.
After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
Curiously, setting user properties other than the ci-friendly specific
properties via MAVEN_OPTS never worked, even on 3.8.x.
h1. Reproducing
Given the {_}pom.xml{_}:
{noformat}
4.0.0
com.acme
property-bug
1.0.0
pom
pomValue
pomValue
maven-antrun-plugin
generate-resources
run
echoing revision ${revision} revision2 ${revision2}
{noformat}
If I run:
{noformat}
MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn help:effective-pom
| grep revision{noformat}
On *3.8.9-* I get:
{noformat}
optsValue
pomValue
echoing revision optsValue revision2
pomValue{noformat}
On *3.9.0+* I get:
{code:java}
pomValue
pomValue
echoing revision optsValue revision2 pomValue
{code}
was:
h1. Intro
Prior to 3.9.x, it was possible to inject the
[ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
MAVEN_OPTS.
After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
Curiously, setting user properties other than the ci-friendly specific
properties via MAVEN_OPTS never worked, even on 3.8.x.
h1. Reproducing
Given the {_}pom.xml{_}:
{noformat}
4.0.0
com.acme
property-bug
1.0.0
pom
pomValue
pomValue
maven-antrun-plugin
generate-resources
run
echoing revision ${revision} revision2 ${revision2}
{noformat}
If I run:
{noformat}
MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn help:effective-pom
| grep revision{noformat}
On *3.8.9-* I get:
{noformat}
optsValue
pomValue
echoing revision optsValue revision2
pomValue{noformat}
On *3.9.0+* I get:
{code:java}
pomValue
pomValue
echoing revision optsValue revision2 pomValue
{code}
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765678#comment-17765678
]
Francisco Bento da Silva Neto commented on MNG-7887:
Fair enough.
But this behavior broke our pipelines and I could not find any info around this
in the 'potentially breaking' changes in the 3.9.x release notes. E.g:
[https://maven.apache.org/docs/3.9.0/release-notes.html#potentially-breaking-core-changes-if-migrating-from-3-8-x]
Has this been published somewhere ? If not, shouldn't it be ?
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765679#comment-17765679
]
Michael Osipov commented on MNG-7887:
-
That should have been done by the release manager, actually. Feel free to raise
a PR to fix that issue in the release notes. I will merge it.
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765688#comment-17765688
]
Francisco Bento da Silva Neto commented on MNG-7887:
Sure. Where can I find release notes ? Did a quick lookup on github and could
not find anything.
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765688#comment-17765688
]
Francisco Bento da Silva Neto edited comment on MNG-7887 at 9/15/23 3:10 PM:
-
Sure. Where can I find the release notes src ? Did a quick lookup on github and
could not find anything.
was (Author: chicobe...@gmail.com):
Sure. Where can I find release notes ? Did a quick lookup on github and could
not find anything.
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7887) cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
[
https://issues.apache.org/jira/browse/MNG-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765691#comment-17765691
]
Michael Osipov commented on MNG-7887:
-
Here it is: https://github.com/apache/maven-site/
> cannot inject ci-friendly revision/sha1/changelist properties via MAVEN_OPTS
>
>
> Key: MNG-7887
> URL: https://issues.apache.org/jira/browse/MNG-7887
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4
>Reporter: Francisco Bento da Silva Neto
>Priority: Minor
>
> h1. Intro
> Prior to 3.9.x, it was possible to inject the
> [ci-friendly|https://maven.apache.org/maven-ci-friendly.html] properties via
> MAVEN_OPTS.
> After 3.9.x it is possible only via command-line args or MAVEN_ARGS env.
> Curiously, setting user properties other than the ci-friendly specific
> properties via MAVEN_OPTS never worked, even on 3.8.x.
> h1. Reproducing
> Given the {_}pom.xml{_}:
> {noformat}
>
> 4.0.0
> com.acme
> property-bug
> 1.0.0
> pom
>
> pomValue
> pomValue
>
>
>
>
> maven-antrun-plugin
>
>
> generate-resources
>
> run
>
>
>
> echoing revision ${revision} revision2
> ${revision2}
>
>
>
>
>
>
>
> {noformat}
> If I run:
> {noformat}
> MAVEN_OPTS='-Drevision=optsValue -Drevision2=optsValue2' mvn
> help:effective-pom | grep revision{noformat}
> On *3.8.9-* I get:
> {noformat}
> optsValue
> pomValue
> echoing revision optsValue revision2
> pomValue{noformat}
> On *3.9.0+* I get:
> {code:java}
> pomValue
> pomValue
> echoing revision optsValue revision2 pomValue
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-764) javadoc:aggregate fails after Java 11 upgrade
[
https://issues.apache.org/jira/browse/MJAVADOC-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-764:
Priority: Critical (was: Blocker)
> javadoc:aggregate fails after Java 11 upgrade
> --
>
> Key: MJAVADOC-764
> URL: https://issues.apache.org/jira/browse/MJAVADOC-764
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Sirisha Pratha
>Priority: Critical
> Labels: jpms
>
> We have a multi-module project that is failing for javadoc:aggregate goal
> after upgrading to Java 11 for maven-javadoc-plugin versions 3.4.1 and 3.5.0.
> It worked fine without any issues for Java 1.8.
> This is our maven-javadoc plugin configuration for Java 8 -
> {color:#00875a}*SUCCESS*{color}
>
> {noformat}
> 8
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/javase/8/docs/api/
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
>
> {noformat}
> This is our maven-javadoc plugin configuration for Java 11 - (the only
> difference is values in source and links tags) -
> *{color:#ff}FAILS{color}* {color:#ff}(See error below){color}
>
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> ${maven.compiler.source}
> Eclipse Collections -
> ${project.version}
> Eclipse Collections -
> ${project.version}
> public
> true
>
> https://junit.org/junit4/javadoc/latest
>
> https://docs.oracle.com/en/java/javase/11/docs/api
>
> ${project.version}
> html,syntax,accessibility
>
>
> org.openjdk,org.eclipse.collections.impl.jmh,org.eclipse.collections.codegenerator,org.eclipse.collections.codegenerator.maven
>
>
>
>
> aggregate
> false
>
> aggregate
>
>
>
> {noformat}
>
> _javadoc:aggregate_ fails with the following error on our GitHub workflow
> (nothing changed in the way we run this job - we have always used Java 17 to
> run this)
>
> {noformat}
> Error: 6:236 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.1:aggregate (default-cli)
> on project eclipse-collections-parent: An error has occurred in Javadoc
> report generation:
> 515Error: 6:236 [ERROR] Exit code: 2 - Loading source files for package
> org.eclipse.collections.codegenerator.model...
> 516Error: 02:14:46:236 [ERROR] error: No source files for package
> org.eclipse.collections.codegenerator.model
> 517Error: 02:14:46:237 [ERROR] 1 error
> 518Error: 6:237 [ERROR]
> 519Error: 6:238 [ERROR] Command line was:
> /opt/hostedtoolcache/Java_Zulu_jdk/17.0.7-7/x64/bin/javadoc @options @packages
> 520Error: 6:238 [ERROR]
> 521Error: 6:238 [ERROR] Refer to the generated Javadoc files in
> '/home/runner/work/eclipse-collections/eclipse-collections/target/site/apidocs/12.0.0-SNAPSHOT'
> dir.
> 522Error: 6:239 [ERROR]
> 523Error: 6:240 [ERROR] -> [Help 1]{noformat}
>
>
> Solutions we tried -
> # Configuring sourcePath (see below) - in this case, *no Javadoc was
> created* in target/site/apidocs.
> {noformat}
> ${project.build.sourceDirectory}{noformat}
> # Tried both plugin versions 3.4.1 and 3.5.0 - *fails* with both versions.
> # Tried to add source = 1.8 but maven.compiler.source = 11, which seems to
> be the only combination that {*}works{*}. Like so -
> {noformat}
> 11
>
> maven-javadoc-plugin
>
> 1.8
> Ecl
[jira] [Updated] (MJAVADOC-747) jar goal fails with automatic module (Regression from 3.2.0)
[
https://issues.apache.org/jira/browse/MJAVADOC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-747:
Priority: Critical (was: Blocker)
> jar goal fails with automatic module (Regression from 3.2.0)
> -
>
> Key: MJAVADOC-747
> URL: https://issues.apache.org/jira/browse/MJAVADOC-747
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1, 3.5.0
>Reporter: Geoffrey De Smet
>Priority: Critical
> Labels: jpms
>
> In optaplanner, we provide automatic module names for all our modules.
> But some modules have a dependency with classes in the no-name package.
> That was not a problem for the maven-javadoc-plugin, except since
> maven-javadoc-plugin 3.3.0 (including 3.5.0) it crashes the entire build.
> This happens with dependencies on quarkus and on rewrite.
> For example, for optaplanner-migrator that depends on rewrite-maven and
> rewrite-gradle:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar (default) on project
> reproducer:
> Execution default of goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.5.0:jar failed:
> Unable to derive module descriptor for
> /.../.m2/repository/org/openrewrite/rewrite-gradle/7.38.0/rewrite-gradle-7.38.0.jar:
> PluginSpec.class found in top-level directory (unnamed package not allowed in
> module) -> [Help 1]{code}
> Isolated reproducer:
> [https://github.com/ge0ffrey/maven-javadoc-plugin-3.5.0-reproducer]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1244: [MNG-7820] Get rid of plexus-utils Os, DAG and ReflectionValueExtractor
michael-o commented on code in PR #1244:
URL: https://github.com/apache/maven/pull/1244#discussion_r1327501134
##
maven-model-builder/src/main/java/org/apache/maven/utils/Os.java:
##
@@ -0,0 +1,213 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils;
+
+import java.util.Locale;
+import java.util.stream.Stream;
+
+/**
+ * OS support
+ */
+public class Os {
Review Comment:
Would it make sense to skip this class?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7820) Remove dependency on plexus-utils
[
https://issues.apache.org/jira/browse/MNG-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765708#comment-17765708
]
ASF GitHub Bot commented on MNG-7820:
-
michael-o commented on code in PR #1244:
URL: https://github.com/apache/maven/pull/1244#discussion_r1327501134
##
maven-model-builder/src/main/java/org/apache/maven/utils/Os.java:
##
@@ -0,0 +1,213 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.utils;
+
+import java.util.Locale;
+import java.util.stream.Stream;
+
+/**
+ * OS support
+ */
+public class Os {
Review Comment:
Would it make sense to skip this class?
> Remove dependency on plexus-utils
> -
>
> Key: MNG-7820
> URL: https://issues.apache.org/jira/browse/MNG-7820
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-8
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7864) Fix the S390x to use IT branches
[ https://issues.apache.org/jira/browse/MNG-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765751#comment-17765751 ] ASF GitHub Bot commented on MNG-7864: - vivkong commented on PR #1239: URL: https://github.com/apache/maven/pull/1239#issuecomment-1721642457 > The problem is really with PRs that use a custom IT branch, so nightly builds for the master branch would be fine with me. Thanks @gnodet. In that case, I will close this PR and create a new one to reinstate the previous Jenkinsfile.s390x file and ask for help with changing the Jenkins setup (disable PR checks). > Fix the S390x to use IT branches > > > Key: MNG-7864 > URL: https://issues.apache.org/jira/browse/MNG-7864 > Project: Maven > Issue Type: Bug >Reporter: Guillaume Nodet >Priority: Major > > When testing a PR, the maven-integration-testing branch with the same name > should be used instead of master if it exists. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MJAVADOC-757) Unresolvable link in javadoc tag with value ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo
[ https://issues.apache.org/jira/browse/MJAVADOC-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MJAVADOC-757: Assignee: Elliotte Rusty Harold > Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo > -- > > Key: MJAVADOC-757 > URL: https://issues.apache.org/jira/browse/MJAVADOC-757 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MJAVADOC-757) Unresolvable link in javadoc tag with value ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo
[ https://issues.apache.org/jira/browse/MJAVADOC-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MJAVADOC-757. Resolution: Fixed > Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo > -- > > Key: MJAVADOC-757 > URL: https://issues.apache.org/jira/browse/MJAVADOC-757 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-757) Unresolvable link in javadoc tag with value ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo
[ https://issues.apache.org/jira/browse/MJAVADOC-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MJAVADOC-757: - Fix Version/s: 3.6.0 > Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in ResourcesBundleMojo > -- > > Key: MJAVADOC-757 > URL: https://issues.apache.org/jira/browse/MJAVADOC-757 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.6.0 > > > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] > [WARNING] Unresolvable link in javadoc tag with value > ResourcesBundleMojo#getAttachmentClassifier() found in > src/main/java/org/apache/maven/plugins/javadoc/ResourcesBundleMojo.java:69: > Could not resolve javadoc reference JavadocReference > [moduleName=Optional.empty, > packageNameClassName=Optional[ResourcesBundleMojo], > member=Optional[getAttachmentClassifier()], label=Optional.empty] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-767) javadoc creates invalid --patch-module statements
[
https://issues.apache.org/jira/browse/MJAVADOC-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MJAVADOC-767:
-
Fix Version/s: 3.6.0
(was: 4.0.0)
> javadoc creates invalid --patch-module statements
> -
>
> Key: MJAVADOC-767
> URL: https://issues.apache.org/jira/browse/MJAVADOC-767
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.6.0
>
>
> Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar
> that contains all the javadocs for all modules in a doc step. This works ok
> for non-JPMS (Java 8 target).
> When introducing JPMS into our project, the javadoc plugin starts adding
> --patch-module options like this:
> {{--patch-module
> org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
> However, in our configuration, we exclude the kotlin specific modules:
> {code:xml}
>
> maven-javadoc-plugin
>
>
> javadoc-jar
>
> jar
>
> package
>
> true
> false
>
>
> org.jdbi:*
>
>
>
> org.jdbi:jdbi3-kotlin
>
> org.jdbi:jdbi3-kotlin-sqlobject
>
>
> jdbi3-kotlin,jdbi3-kotlin-sqlobject
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
>
>
>
> {code}
> which results in the maven-javadoc-plugin creating command line options like
> this:
> {{--patch-module org.jdbi.v3.kotlin=}}
> which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAVADOC-767) javadoc creates invalid --patch-module statements
[
https://issues.apache.org/jira/browse/MJAVADOC-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MJAVADOC-767.
> javadoc creates invalid --patch-module statements
> -
>
> Key: MJAVADOC-767
> URL: https://issues.apache.org/jira/browse/MJAVADOC-767
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.6.0
>
>
> Jdbi is a mixed Java/Kotlin multi-module project. We aggregate a final jar
> that contains all the javadocs for all modules in a doc step. This works ok
> for non-JPMS (Java 8 target).
> When introducing JPMS into our project, the javadoc plugin starts adding
> --patch-module options like this:
> {{--patch-module
> org.jdbi.v3.caffeine='/Users/henning/code/jdbi/cache/caffeine-cache/src/main/java:/Users/henning/code/jdbi/cache/caffeine-cache/target/generated-sources/annotations'}}
> However, in our configuration, we exclude the kotlin specific modules:
> {code:xml}
>
> maven-javadoc-plugin
>
>
> javadoc-jar
>
> jar
>
> package
>
> true
> false
>
>
> org.jdbi:*
>
>
>
> org.jdbi:jdbi3-kotlin
>
> org.jdbi:jdbi3-kotlin-sqlobject
>
>
> jdbi3-kotlin,jdbi3-kotlin-sqlobject
> Jdbi3 ${project.version} API
> Jdbi3 ${project.version} API
>
>
>
>
> {code}
> which results in the maven-javadoc-plugin creating command line options like
> this:
> {{--patch-module org.jdbi.v3.kotlin=}}
> which in turn crash the javadoc command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRRESOURCES-140) Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
[ https://issues.apache.org/jira/browse/MRRESOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MRRESOURCES-140. --- Resolution: Fixed > Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0 > -- > > Key: MRRESOURCES-140 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-140 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRRESOURCES-140) Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
[ https://issues.apache.org/jira/browse/MRRESOURCES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765808#comment-17765808 ] ASF GitHub Bot commented on MRRESOURCES-140: slawekjaranowski merged PR #44: URL: https://github.com/apache/maven-remote-resources-plugin/pull/44 > Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0 > -- > > Key: MRRESOURCES-140 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-140 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRRESOURCES-141) Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
Slawomir Jaranowski created MRRESOURCES-141: --- Summary: Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0 Key: MRRESOURCES-141 URL: https://issues.apache.org/jira/browse/MRRESOURCES-141 Project: Maven Remote Resources Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7888) maven releases do not resolve URL in pom
Henning Schmiedehausen created MNG-7888:
---
Summary: maven releases do not resolve URL in pom
Key: MNG-7888
URL: https://issues.apache.org/jira/browse/MNG-7888
Project: Maven
Issue Type: Bug
Reporter: Henning Schmiedehausen
The released poms contain
{{https://github.com/apache/maven-javadoc-plugin/tree/${project.scm.tag}}}.
As a result, tools that do not actively parse and resolve the pom can't
display a valid URL but only show a link with the placeholder.
E.g.
https://search.maven.org/artifact/org.apache.maven.plugins/maven-javadoc-plugin/3.4.1/maven-plugin
This seems to be a fundamental problem with the maven parent pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17765906#comment-17765906 ] Christopher Tubbs commented on MJAVADOC-707: Tried with 3.6.0 and legacyMode seems to work fine. > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > Labels: jpms > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
