[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=17766044#comment-17766044 ] Henning Schmiedehausen commented on MJAVADOC-707: - *happy dance* Can we close this issue in this case? > 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)
[jira] [Commented] (SUREFIRE-2191) surefire crashes on a JPMS modularized project that uses junit5
[
https://issues.apache.org/jira/browse/SUREFIRE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766043#comment-17766043
]
Henning Schmiedehausen commented on SUREFIRE-2191:
--
I have two modules, core and testing (these are defined modules, they have a
module descriptor)
"core" is just a regular build, it uses junit5 as its test framework.
surefire creates a classpath with all the surefire deps (surefire-api,
surefire-extensions, surefire-junit-platform, surefire-logging-api,
surefire-shared-utils) and the junit deps (junit-jupiter-api,
junit-jupiter-engine, junit-jupiter-params, junit-platform-commons,
junit-platform-engine, junit-platform-launcher). The module path only gets the
actual module dependencies of module A
All works well in that case.
Now the "testing" module declares org.junit.jupiter.api as a dependency and has
requires org.junit.jupiter.api in its module descriptor (transitive or not
transitive does not matter) because there is code that implements some of those
APIs.
surefire now creates a classpath with the same surefire deps and only a subset
of junit deps. The missing deps (junit-jupiter-api and junit-platform-commons)
are pulled onto the module path.
This explains the error message:
*java.lang.IllegalAccessError: class
org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in unnamed
module @0x6392827e) cannot access class
org.junit.platform.commons.util.Preconditions (in module
org.junit.platform.commons) because module org.junit.platform.commons does not
export org.junit.platform.commons.util to unnamed module @0x6392827e*
The launcher (in junit-platform-launcher) lives on the classpath and is
therefore in the unnamed module. But the launcher requires the
org.junit.platform.commons module from the junit-platform-commons jar, which is
on the module path. And the junit-platform-commons module has the following
clause in its module descriptor:
exports org.junit.platform.commons.util to
[...]
org.junit.platform.launcher,
[...];
and it does not export the package to the unnamed module. And now JVM fails
with the error above.
I can not see any good solution:
- The current solution does not work (see above)
- The junit-jupiter-api which contains org.junit.jupiter.api can not go on the
class path because now the main artifact which requires it can not find it.
- It can not be patched into the main module because now the
org.junit.jupiter.api module would be invisible to everything on the module
path (packages can't exist twice)
- It can only stay on the module path if everything that depends on it gets
pulled there as well. This requires a "bottom up" resolution of all modules
that depend on this (in this case org.junit.jupiter.api) and may interfere with
the ability of the surefire launcher to launch code.- We could fall back to
"legacy" mode where everything is on the classpath and the module path is
ignored. This is problematic as tests may pass and code later fails because of
not matching entries in the module descriptor
> surefire crashes on a JPMS modularized project that uses junit5
> ---
>
> Key: SUREFIRE-2191
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2191
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, process forking
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: [https://github.com/hgschmie/surefire-2191
> |https://github.com/hgschmie/surefire-2191] and build it.
> The build fails during testing with a large and cryptic error description.
> The code only uses the junit jupiter APIs and imports the with {{ requires
> transitive org.junit.jupiter.api;}}
> This is the surefireargs file that the plugin creates:
> {code}
> --module-path
> "/Users/henning/scratch/surefire-junit-bug/target/classes:/Users/henning/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.10.0/junit-jupiter-api-5.10.0.jar:/Users/henning/.m2/repository/org/opentest4j/opentest4j/1.3.0/opentest4j-1.3.0.jar:/Users/henning/.m2/repository/org/junit/platform/junit-platform-commons/1.10.0/junit-platform-commons-1.10.0.jar:/Users/henning/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar"
> --class-path
>
[jira] [Commented] (MNG-7888) maven releases do not resolve URL in pom
[
https://issues.apache.org/jira/browse/MNG-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766034#comment-17766034
]
Henning Schmiedehausen commented on MNG-7888:
-
then what is the point of having metadata such as doc urls, issue tracker etc.
if they can't be read outside a maven context? We could pretend that the maven
universe is hermetic and only the maven driven tooling exists (e.g. site
generation).
The real world looks different. Case in point are the URIs above. Most projects
get this right (they fully resolve the pom before publishing).
> 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
>Priority: Major
>
> 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-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766016#comment-17766016
]
AO Industries, Inc. commented on MJAVADOC-682:
--
We have tested version 3.6.0 and confirm this issue remains.
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Description:
In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
with the same groupId and artifactId, even when different versions, the javadoc
fails with:
Exit code: 1 - error: module not found: com.aoindustries.example
Plugin 3.0.1 works.
We have created a minimal example project that demonstrates this bug:
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
— Copy from demo project README.md —
h2. To Reproduce:
# Clone this project: {{git clone
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
# Change to project directory: {{cd
maven-javadoc-plugin-failing-multiple-projects-same-name}}
# Perform build to see error in {{jar}} goal: {{mvn verify}}
# Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
h2. Notes:
* Can build individual modules directly, such as {{(cd module-1 && mvn
verify)}}
* Reverting to maven-javadoc-plugin version 3.0.1 makes it work
* Changing the groupId or artifactId in either module-1 or module-2 makes it
work.
* Changing module names, package names, or class names in modules has no
effect.
* We believe this to be distinct from [Issue
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
was:
In versions 3.1.0 through 3.4.1, when a reactor build has multiple projects
with the same groupId and artifactId, even when different versions, the javadoc
fails with:
Exit code: 1 - error: module not found: com.aoindustries.example
Plugin 3.0.1 works.
We have created a minimal example project that demonstrates this bug:
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
— Copy from demo project README.md —
h2. To Reproduce:
# Clone this project: {{git clone
[https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
# Change to project directory: {{cd
maven-javadoc-plugin-failing-multiple-projects-same-name}}
# Perform build to see error in {{jar}} goal: {{mvn verify}}
# Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
h2. Notes:
* Can build individual modules directly, such as {{(cd module-1 && mvn
verify)}}
* Reverting to maven-javadoc-plugin version 3.0.1 makes it work
* Changing the groupId or artifactId in either module-1 or module-2 makes it
work.
* Changing module names, package names, or class names in modules has no
effect.
* We believe this to be distinct from [Issue
#673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.6.0, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Environment:
Debian Linux versions 10.10 through 12.1
OpenJDK 64-bit versions 11.0.11 through 17.0.8
Maven versions 3.8.1 through 3.9.4
was:
Debian Linux versions 10.10 through 11.4
OpenJDK 64-bit versions 11.0.11 through 11.0.16
Maven versions 3.8.1 through 3.8.6
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 12.1
> OpenJDK 64-bit versions 11.0.11 through 17.0.8
> Maven versions 3.8.1 through 3.9.4
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.4.1, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-682) Reactor builds fail when multiple modules with same groupId:artifactId
[
https://issues.apache.org/jira/browse/MJAVADOC-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
AO Industries, Inc. updated MJAVADOC-682:
-
Affects Version/s: 3.6.0
3.5.0
> Reactor builds fail when multiple modules with same groupId:artifactId
> --
>
> Key: MJAVADOC-682
> URL: https://issues.apache.org/jira/browse/MJAVADOC-682
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: jar, javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0, 3.4.1,
> 3.5.0, 3.6.0
> Environment: Debian Linux versions 10.10 through 11.4
> OpenJDK 64-bit versions 11.0.11 through 11.0.16
> Maven versions 3.8.1 through 3.8.6
>Reporter: AO Industries, Inc.
>Priority: Major
> Labels: jpms
>
> In versions 3.1.0 through 3.4.1, when a reactor build has multiple projects
> with the same groupId and artifactId, even when different versions, the
> javadoc fails with:
> Exit code: 1 - error: module not found: com.aoindustries.example
> Plugin 3.0.1 works.
> We have created a minimal example project that demonstrates this bug:
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name]
>
> — Copy from demo project README.md —
> h2. To Reproduce:
> # Clone this project: {{git clone
> [https://github.com/aoindustries/maven-javadoc-plugin-failing-multiple-projects-same-name.git]}}
> # Change to project directory: {{cd
> maven-javadoc-plugin-failing-multiple-projects-same-name}}
> # Perform build to see error in {{jar}} goal: {{mvn verify}}
> # Also fails with {{javadoc}} goal: {{mvn clean compile javadoc:javadoc}}
> h2. Notes:
> * Can build individual modules directly, such as {{(cd module-1 && mvn
> verify)}}
> * Reverting to maven-javadoc-plugin version 3.0.1 makes it work
> * Changing the groupId or artifactId in either module-1 or module-2 makes it
> work.
> * Changing module names, package names, or class names in modules has no
> effect.
> * We believe this to be distinct from [Issue
> #673|https://issues.apache.org/jira/projects/MJAVADOC/issues/MJAVADOC-673]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7889) Preserve MetadataXpp3Reader/Writer for Maven 3 compatible
[
https://issues.apache.org/jira/browse/MNG-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766013#comment-17766013
]
ASF GitHub Bot commented on MNG-7889:
-
slawekjaranowski opened a new pull request, #1246:
URL: https://github.com/apache/maven/pull/1246
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) 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.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`,
where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA
issue.
- [x] Also format the first line of the commit message like `[MNG-XXX]
SUMMARY`.
Best practice is to use the JIRA issue title in both 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.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
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.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Preserve MetadataXpp3Reader/Writer for Maven 3 compatible
> -
>
> Key: MNG-7889
> URL: https://issues.apache.org/jira/browse/MNG-7889
> Project: Maven
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> {{MetadataXpp3Reader/Writer}} can be used by plugins, eg are used by
> mrm-maven-plugin
> There was available in alpha-7 so should be also present in next version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] slawekjaranowski opened a new pull request, #1246: [MNG-7889] Preserve MetadataXpp3Reader/Writer for Maven 3 compatible
slawekjaranowski opened a new pull request, #1246: URL: https://github.com/apache/maven/pull/1246 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both 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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. 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. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7889) Preserve MetadataXpp3Reader/Writer for Maven 3 compatible
Slawomir Jaranowski created MNG-7889:
Summary: Preserve MetadataXpp3Reader/Writer for Maven 3 compatible
Key: MNG-7889
URL: https://issues.apache.org/jira/browse/MNG-7889
Project: Maven
Issue Type: Bug
Reporter: Slawomir Jaranowski
Assignee: Slawomir Jaranowski
{{MetadataXpp3Reader/Writer}} can be used by plugins, eg are used by
mrm-maven-plugin
There was available in alpha-7 so should be also present in next version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MPLUGIN-482) JavadocSite.createLink() does not consider implicit module path prefix
[ https://issues.apache.org/jira/browse/MPLUGIN-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved MPLUGIN-482. - Fix Version/s: 3.9.1 Resolution: Fixed Fixed in https://github.com/apache/maven-plugin-tools/commit/247bff784a86a620caacc2910439630873849f92. > JavadocSite.createLink() does not consider implicit module path prefix > -- > > Key: MPLUGIN-482 > URL: https://issues.apache.org/jira/browse/MPLUGIN-482 > Project: Maven Plugin Tools > Issue Type: Bug > Components: API >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.9.1 > > > Although the module for a javadoc code reference is looked up (if not > explicitly given by the javadoc reference), it is afterwards not being > considered when the URL is calculated (last argument of > https://github.com/apache/maven-plugin-tools/blob/511d287352836a4dc52227b61208536af5feaded/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/javadoc/JavadocSite.java#L309 > is just disregarded) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-482) JavadocSite.createLink() does not consider implicit module path prefix
[ https://issues.apache.org/jira/browse/MPLUGIN-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765996#comment-17765996 ] ASF GitHub Bot commented on MPLUGIN-482: kwin merged PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226 > JavadocSite.createLink() does not consider implicit module path prefix > -- > > Key: MPLUGIN-482 > URL: https://issues.apache.org/jira/browse/MPLUGIN-482 > Project: Maven Plugin Tools > Issue Type: Bug > Components: API >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Although the module for a javadoc code reference is looked up (if not > explicitly given by the javadoc reference), it is afterwards not being > considered when the URL is calculated (last argument of > https://github.com/apache/maven-plugin-tools/blob/511d287352836a4dc52227b61208536af5feaded/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/javadoc/JavadocSite.java#L309 > is just disregarded) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-plugin-tools] kwin merged pull request #226: [MPLUGIN-482] Consider implicit module name for javadoc URL calculation
kwin merged PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] GitPopcorn closed issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
GitPopcorn closed issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40 URL: https://github.com/apache/maven-mvnd/issues/883 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] GitPopcorn commented on issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
GitPopcorn commented on issue #883: URL: https://github.com/apache/maven-mvnd/issues/883#issuecomment-1722260338 > The fact that mvnd outputs the expected encoding in the console does not necessarily mean that it would be used everywhere where it should. BTW, the expected encoding is also shown by `mvnd-1.0-m7-m39` (based on Maven 3.9.x). > > I am not sure whether something changed in Maven 4. Ok, thanks for you replay and explanation. I am just ... not very clear about the actual meaning of platform encoding printed in the console, and I did forget the daemon feature of `mvnd`. This issue could be closed, thanks again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
ppalaga commented on issue #883: URL: https://github.com/apache/maven-mvnd/issues/883#issuecomment-1722258883 > But I just don't know why it could be changed when running with `mvnd-0.8.2` (the second and third command in my log)? but not be so when running `mvnd-1.0-m7-m40`. The fact that mvnd outputs the expected encoding in the console does not necessarily mean that it would be used everywhere where it should. BTW, the expected encoding is also shown by `mvnd-1.0-m7-m39` (based on Maven 3.9.x). I am not sure whether something changed in Maven 4. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] GitPopcorn commented on issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
GitPopcorn commented on issue #883: URL: https://github.com/apache/maven-mvnd/issues/883#issuecomment-1722255904 > Hi @GitPopcorn, I wonder how safe it is to pass `-Dfile.encoding` to an already running daemon. Java caches the value of "file.encoding" in some of it's core classes. Hence once the daemon java process is up, passing a new value via `-Dfile.encoding` won't perhaps have the desired effect. > > Setting `file.encoding` via application properties on Daemon startup should work though. You mean, the following has no effect with mvnd 1.0-m7-m40? > > ``` > mvnd.jvmArgs=-Dfile.encoding=ISO-8859-1 > ``` > > I must say it works for me after forcing to start a new daemon via `mvnd --stop`: > > ``` > $ mvnd --stop > $ mvnd -v > Apache Maven Daemon (mvnd) 1.0-m7 linux-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) > Terminal: org.jline.terminal.impl.PosixSysTerminal with pty org.jline.terminal.impl.jansi.linux.LinuxNativePty > Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) > Maven home: /home/ppalaga/.sdkman/candidates/mvnd/1.0-m7-m40/mvn > Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: /home/ppalaga/.sdkman/candidates/java/17.0.5-tem > Default locale: en_IE, platform encoding: ISO-8859-1 > OS name: "linux", version: "6.4.11-200.fc38.x86_64", arch: "amd64", family: "unix" > ``` Alright, I got what you mean that mvnd will remain and reuse a certain JVM process, and the defined JVM system properties won't change when running, this may explain why the platform encoding can not be changed before `mvnd --stop`. But I just don't know why it could be changed when running with `mvnd-0.8.2` (the second and third command in my log)? but not be so when running `mvnd-1.0-m7-m40`. Is there any difference in the JVM reusing strategy between these two version? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on issue #883: Cannot change Platform Encoding with mvnd 1.0-m7-m40
ppalaga commented on issue #883: URL: https://github.com/apache/maven-mvnd/issues/883#issuecomment-1722252317 Hi @GitPopcorn, I wonder how safe it is to pass `-Dfile.encoding` to an already running daemon. Java caches the value of "file.encoding" in some of it's core classes. Hence once the daemon java process is up, passing a new value via `-Dfile.encoding` won't perhaps have the desired effect. Setting `file.encoding` via application properties on Daemon startup should work though. You mean, the following has no effect with mvnd 1.0-m7-m40? ``` mvnd.jvmArgs=-Dfile.encoding=ISO-8859-1 ``` I must say it works for me after forcing to start a new daemon via `mvnd --stop`: ``` $ mvnd --stop $ mvnd -v Apache Maven Daemon (mvnd) 1.0-m7 linux-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.PosixSysTerminal with pty org.jline.terminal.impl.jansi.linux.LinuxNativePty Apache Maven 4.0.0-alpha-7 (bf699a388cc04b8e4088226ba09a403b68de6b7b) Maven home: /home/ppalaga/.sdkman/candidates/mvnd/1.0-m7-m40/mvn Java version: 17.0.5, vendor: Eclipse Adoptium, runtime: /home/ppalaga/.sdkman/candidates/java/17.0.5-tem Default locale: en_IE, platform encoding: ISO-8859-1 OS name: "linux", version: "6.4.11-200.fc38.x86_64", arch: "amd64", family: "unix" ``` -- 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] (MENFORCER-492) Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
[ https://issues.apache.org/jira/browse/MENFORCER-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765969#comment-17765969 ] ASF GitHub Bot commented on MENFORCER-492: -- slawekjaranowski opened a new pull request, #291: URL: https://github.com/apache/maven-enforcer/pull/291 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). > Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0 > -- > > Key: MENFORCER-492 > URL: https://issues.apache.org/jira/browse/MENFORCER-492 > Project: Maven Enforcer 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)
[GitHub] [maven-enforcer] slawekjaranowski opened a new pull request, #291: [MENFORCER-492] Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
slawekjaranowski opened a new pull request, #291: URL: https://github.com/apache/maven-enforcer/pull/291 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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] [Moved] (MENFORCER-492) Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0
[ https://issues.apache.org/jira/browse/MENFORCER-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski moved MRRESOURCES-141 to MENFORCER-492: --- Fix Version/s: next-release (was: next-release) Key: MENFORCER-492 (was: MRRESOURCES-141) Project: Maven Enforcer Plugin (was: Maven Remote Resources Plugin) > Bump plexus-utils from 3.5.1 to 4.0.0 and plexus-xml 3.0.0 > -- > > Key: MENFORCER-492 > URL: https://issues.apache.org/jira/browse/MENFORCER-492 > Project: Maven Enforcer 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] (MPLUGIN-482) JavadocSite.createLink() does not consider implicit module path prefix
[ https://issues.apache.org/jira/browse/MPLUGIN-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765952#comment-17765952 ] ASF GitHub Bot commented on MPLUGIN-482: slawekjaranowski commented on code in PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226#discussion_r1327949273 ## maven-plugin-tools-api/pom.xml: ## @@ -125,4 +130,30 @@ + + + run-its + + + +org.apache.maven.plugins +maven-failsafe-plugin + + + + integration-test + verify + + + JavadocSite.createLink() does not consider implicit module path prefix > -- > > Key: MPLUGIN-482 > URL: https://issues.apache.org/jira/browse/MPLUGIN-482 > Project: Maven Plugin Tools > Issue Type: Bug > Components: API >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Although the module for a javadoc code reference is looked up (if not > explicitly given by the javadoc reference), it is afterwards not being > considered when the URL is calculated (last argument of > https://github.com/apache/maven-plugin-tools/blob/511d287352836a4dc52227b61208536af5feaded/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/javadoc/JavadocSite.java#L309 > is just disregarded) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a diff in pull request #226: [MPLUGIN-482] Consider implicit module name for javadoc URL calculation
slawekjaranowski commented on code in PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226#discussion_r1327949273 ## maven-plugin-tools-api/pom.xml: ## @@ -125,4 +130,30 @@ + + + run-its + + + +org.apache.maven.plugins +maven-failsafe-plugin + + + + integration-test + verify + + + + nonLtsJavadocs Review Comment: ok. I see test are execute - only not the non lst are extracted to other test -- 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] (MPLUGIN-482) JavadocSite.createLink() does not consider implicit module path prefix
[ https://issues.apache.org/jira/browse/MPLUGIN-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765946#comment-17765946 ] ASF GitHub Bot commented on MPLUGIN-482: kwin commented on code in PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226#discussion_r1327945771 ## maven-plugin-tools-api/pom.xml: ## @@ -125,4 +130,30 @@ + + + run-its + + + +org.apache.maven.plugins +maven-failsafe-plugin + + + + integration-test + verify + + + JavadocSite.createLink() does not consider implicit module path prefix > -- > > Key: MPLUGIN-482 > URL: https://issues.apache.org/jira/browse/MPLUGIN-482 > Project: Maven Plugin Tools > Issue Type: Bug > Components: API >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Although the module for a javadoc code reference is looked up (if not > explicitly given by the javadoc reference), it is afterwards not being > considered when the URL is calculated (last argument of > https://github.com/apache/maven-plugin-tools/blob/511d287352836a4dc52227b61208536af5feaded/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/javadoc/JavadocSite.java#L309 > is just disregarded) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-plugin-tools] kwin commented on a diff in pull request #226: [MPLUGIN-482] Consider implicit module name for javadoc URL calculation
kwin commented on code in PR #226: URL: https://github.com/apache/maven-plugin-tools/pull/226#discussion_r1327945771 ## maven-plugin-tools-api/pom.xml: ## @@ -125,4 +130,30 @@ + + + run-its + + + +org.apache.maven.plugins +maven-failsafe-plugin + + + + integration-test + verify + + + + nonLtsJavadocs Review Comment: Any other concerns @slawekjaranowski? -- 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-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=17765945#comment-17765945
]
ASF GitHub Bot commented on MNG-7864:
-
elharo commented on code in PR #1239:
URL: https://github.com/apache/maven/pull/1239#discussion_r1327945304
##
Jenkinsfile.s390x.its:
##
@@ -0,0 +1,58 @@
+/*
+ * 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.
+ */
+
+pipeline {
+ agent { node { 's390x' } }
+ options {
+durabilityHint('PERFORMANCE_OPTIMIZED')
+buildDiscarder(logRotator(numToKeepStr: '20', artifactNumToKeepStr: '5'))
+timeout(time: 180, unit: 'MINUTES')
+ }
+ parameters {
+string( defaultValue: 'master', description: 'Core Its branch (default
master)',
+name: 'ITS_BRANCH' )
+ }
+ stages {
+stage("Build Maven Core") {
+ steps {
+withEnv(["JAVA_HOME=${ tool "ibm-semeru-8u362-b09" }",
"PATH+MAVEN=${tool 'Maven 3.6.3'}/bin:${env.JAVA_HOME}/bin"]) {
Review Comment:
Is 3.6.3 what we're really using? Looks like other ITs are somewhere in 3.8
right now
> 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)
[GitHub] [maven] elharo commented on a diff in pull request #1239: [MNG-7864] Fix the S390x to use IT branches
elharo commented on code in PR #1239:
URL: https://github.com/apache/maven/pull/1239#discussion_r1327945304
##
Jenkinsfile.s390x.its:
##
@@ -0,0 +1,58 @@
+/*
+ * 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.
+ */
+
+pipeline {
+ agent { node { 's390x' } }
+ options {
+durabilityHint('PERFORMANCE_OPTIMIZED')
+buildDiscarder(logRotator(numToKeepStr: '20', artifactNumToKeepStr: '5'))
+timeout(time: 180, unit: 'MINUTES')
+ }
+ parameters {
+string( defaultValue: 'master', description: 'Core Its branch (default
master)',
+name: 'ITS_BRANCH' )
+ }
+ stages {
+stage("Build Maven Core") {
+ steps {
+withEnv(["JAVA_HOME=${ tool "ibm-semeru-8u362-b09" }",
"PATH+MAVEN=${tool 'Maven 3.6.3'}/bin:${env.JAVA_HOME}/bin"]) {
Review Comment:
Is 3.6.3 what we're really using? Looks like other ITs are somewhere in 3.8
right now
--
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-7888) maven releases do not resolve URL in pom
[
https://issues.apache.org/jira/browse/MNG-7888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765918#comment-17765918
]
Michael Osipov commented on MNG-7888:
-
The POM is subject to interpolation. Using it from an ordinary XML tools leaves
the POM logically incomplete. That is on purpose, no?
> 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
>Priority: Major
>
> 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)
