[jira] [Updated] (MPLUGIN-478) Upgrade org.junit:junit-bom from 5.9.3 to 5.10.0
[ https://issues.apache.org/jira/browse/MPLUGIN-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MPLUGIN-478: Description: https://github.com/apache/maven-plugin-tools/pull/221 > Upgrade org.junit:junit-bom from 5.9.3 to 5.10.0 > > > Key: MPLUGIN-478 > URL: https://issues.apache.org/jira/browse/MPLUGIN-478 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Affects Versions: 3.9.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.1 > > > https://github.com/apache/maven-plugin-tools/pull/221 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-478) Upgrade org.junit:junit-bom from 5.9.3 to 5.10.0
Karl Heinz Marbaise created MPLUGIN-478: --- Summary: Upgrade org.junit:junit-bom from 5.9.3 to 5.10.0 Key: MPLUGIN-478 URL: https://issues.apache.org/jira/browse/MPLUGIN-478 Project: Maven Plugin Tools Issue Type: Dependency upgrade Affects Versions: 3.9.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.9.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7860) Interleaving of build phases
Christoph Läubrich created MNG-7860: --- Summary: Interleaving of build phases Key: MNG-7860 URL: https://issues.apache.org/jira/browse/MNG-7860 Project: Maven Issue Type: New Feature Reporter: Christoph Läubrich Currently a project is build bu running all its phases (e.g. [compile, test, package, verify|https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html]). Lets say we have a multi module build with a module "lib" that contains the basic stuff so other modules depend on it (lets say "feature-a" and "feature-b") and of course we want everything is always fine so we have a lot of test in "lib" in compile scope. Currently now "lib" is compiled and "feature-a" and "feature-b" have to wait until it has finished all phases so in the worst a whole build-tree can be blocked from building unless "lib" is finished. *What I like to propose* is that there is a way to 'interleave' phases. For example currently 'package' is executed *after* test, but actually it could be performed before hands, also as soon as "lib" has passed its compile/package phase the other projects are allowed to run (because the artifact is already there even though not fully tested). Of course this is only a rough description of the idea, e.g. to make this work, one maybe want to have a new 'package-main' phase that is performed right after 'compile' (and probably a package-test phase) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-release] elharo commented on a diff in pull request #196: [MRELEASE-1054] Support for excluding submodules changes.
elharo commented on code in PR #196:
URL: https://github.com/apache/maven-release/pull/196#discussion_r1292889605
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -39,6 +43,7 @@
import org.apache.maven.shared.release.versions.VersionParseException;
import org.codehaus.plexus.components.interactivity.Prompter;
import org.codehaus.plexus.components.interactivity.PrompterException;
+import org.codehaus.plexus.util.SelectorUtils;
Review Comment:
I'd like to avoid addition al plexus dependencies if at all possible.
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -142,6 +147,15 @@ public ReleaseResult execute(
throws ReleaseExecutionException, ReleaseFailureException {
ReleaseResult result = new ReleaseResult();
+List additionalExcludes =
releaseDescriptor.getCheckModificationExcludes();
+
+if (additionalExcludes != null) {
+for (String additionalExclude : additionalExcludes) {
+exclusionPatterns.add(
+additionalExclude.replace("\\",
File.separator).replace("/", File.separator));
Review Comment:
same as above
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -118,6 +125,15 @@ public ReleaseResult execute(
throws ReleaseExecutionException {
ReleaseResult result = new ReleaseResult();
+List additionalExcludes =
releaseDescriptor.getCheckModificationExcludes();
+
+if (additionalExcludes != null) {
+for (String additionalExclude : additionalExcludes) {
+exclusionPatterns.add(
+additionalExclude.replace("\\",
File.separator).replace("/", File.separator));
Review Comment:
File.separator is platform dependent, but I'm not sure it should be here.
That is, exclusions should be specified in a platform independent, standard
way. I could be wrong about that but if I am, please elaborate in detail on how
this works with references to docs.
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -199,13 +213,18 @@ private void transform(
for (MavenProject project : reactorProjects) {
URI pom = project.getFile().toURI();
-logInfo(
-result,
-"Transforming " + root.relativize(pom).getPath() + ' '
-+ buffer().project(project.getArtifactId()) + " '"
+ project.getName() + "'"
-+ (simulate ? " with ." + getPomSuffix() + "
suffix" : "") + "...");
+final String path = root.relativize(pom).getPath();
+
+if (exclusionPatterns.stream()
+.noneMatch(exclusionPattern ->
SelectorUtils.matchPath(exclusionPattern, path))) {
+logInfo(
Review Comment:
why log this? debug level at most
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -165,17 +181,24 @@ public ReleaseResult execute(
}
}
} else {
+URI root = rootProject.getBasedir().toURI();
for (MavenProject project : reactorProjects) {
String projectId =
ArtifactUtils.versionlessKey(project.getGroupId(), project.getArtifactId());
String nextVersion = resolveNextVersion(project, projectId,
releaseDescriptor, releaseEnvironment);
-if (!convertToSnapshot) {
-releaseDescriptor.addReleaseVersion(projectId,
nextVersion);
-} else if (releaseDescriptor.isBranchCreation() &&
convertToBranch) {
-releaseDescriptor.addReleaseVersion(projectId,
nextVersion);
-} else {
-releaseDescriptor.addDevelopmentVersion(projectId,
nextVersion);
+URI pom = project.getFile().toURI();
+final String path = root.relativize(pom).getPath();
+
+if (exclusionPatterns.stream()
+.noneMatch(exclusionPattern ->
SelectorUtils.matchPath(exclusionPattern, path))) {
Review Comment:
a basic loop with no lambdas would be easier to read
--
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] (MRELEASE-1054) [Git submodule] Wrong Change on scm submodule after release:prepare and failed on pushChange
[
https://issues.apache.org/jira/browse/MRELEASE-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753863#comment-17753863
]
ASF GitHub Bot commented on MRELEASE-1054:
--
elharo commented on code in PR #196:
URL: https://github.com/apache/maven-release/pull/196#discussion_r1292889605
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -39,6 +43,7 @@
import org.apache.maven.shared.release.versions.VersionParseException;
import org.codehaus.plexus.components.interactivity.Prompter;
import org.codehaus.plexus.components.interactivity.PrompterException;
+import org.codehaus.plexus.util.SelectorUtils;
Review Comment:
I'd like to avoid addition al plexus dependencies if at all possible.
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -142,6 +147,15 @@ public ReleaseResult execute(
throws ReleaseExecutionException, ReleaseFailureException {
ReleaseResult result = new ReleaseResult();
+List additionalExcludes =
releaseDescriptor.getCheckModificationExcludes();
+
+if (additionalExcludes != null) {
+for (String additionalExclude : additionalExcludes) {
+exclusionPatterns.add(
+additionalExclude.replace("\\",
File.separator).replace("/", File.separator));
Review Comment:
same as above
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -118,6 +125,15 @@ public ReleaseResult execute(
throws ReleaseExecutionException {
ReleaseResult result = new ReleaseResult();
+List additionalExcludes =
releaseDescriptor.getCheckModificationExcludes();
+
+if (additionalExcludes != null) {
+for (String additionalExclude : additionalExcludes) {
+exclusionPatterns.add(
+additionalExclude.replace("\\",
File.separator).replace("/", File.separator));
Review Comment:
File.separator is platform dependent, but I'm not sure it should be here.
That is, exclusions should be specified in a platform independent, standard
way. I could be wrong about that but if I am, please elaborate in detail on how
this works with references to docs.
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java:
##
@@ -199,13 +213,18 @@ private void transform(
for (MavenProject project : reactorProjects) {
URI pom = project.getFile().toURI();
-logInfo(
-result,
-"Transforming " + root.relativize(pom).getPath() + ' '
-+ buffer().project(project.getArtifactId()) + " '"
+ project.getName() + "'"
-+ (simulate ? " with ." + getPomSuffix() + "
suffix" : "") + "...");
+final String path = root.relativize(pom).getPath();
+
+if (exclusionPatterns.stream()
+.noneMatch(exclusionPattern ->
SelectorUtils.matchPath(exclusionPattern, path))) {
+logInfo(
Review Comment:
why log this? debug level at most
##
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractMapVersionsPhase.java:
##
@@ -165,17 +181,24 @@ public ReleaseResult execute(
}
}
} else {
+URI root = rootProject.getBasedir().toURI();
for (MavenProject project : reactorProjects) {
String projectId =
ArtifactUtils.versionlessKey(project.getGroupId(), project.getArtifactId());
String nextVersion = resolveNextVersion(project, projectId,
releaseDescriptor, releaseEnvironment);
-if (!convertToSnapshot) {
-releaseDescriptor.addReleaseVersion(projectId,
nextVersion);
-} else if (releaseDescriptor.isBranchCreation() &&
convertToBranch) {
-releaseDescriptor.addReleaseVersion(projectId,
nextVersion);
-} else {
-releaseDescriptor.addDevelopmentVersion(projectId,
nextVersion);
+URI pom = project.getFile().toURI();
+final String path = root.relativize(pom).getPath();
+
+if (exclusionPatterns.stream()
+.noneMatch(exclusionPattern ->
SelectorUtils.matchPath(exclusionPattern, path))) {
Review Comment:
a basic loop with no lambdas would be easier to read
> [Git submodule] Wrong Change on scm submodule after release:prepare and
> failed on pushChange
>
>
> Key: MRELEASE-1054
> URL
[GitHub] [maven-shade-plugin] dependabot[bot] opened a new pull request, #194: Bump org.vafer:jdependency from 2.8.0 to 2.9.0
dependabot[bot] opened a new pull request, #194: URL: https://github.com/apache/maven-shade-plugin/pull/194 Bumps [org.vafer:jdependency](https://github.com/tcurdt/jdependency) from 2.8.0 to 2.9.0. Changelog Sourced from https://github.com/tcurdt/jdependency/blob/master/HISTORY.md";>org.vafer:jdependency's changelog. Version 2.9.0, release 11.08.2023 Upgraded to ASM 9.4 (JDK 20 support) Commits https://github.com/tcurdt/jdependency/commit/91956ef0c6d411bfb12803017bdf7cd9d510797b";>91956ef adjusted release date https://github.com/tcurdt/jdependency/commit/212fa6568e6961860d440128fce37725a1c47f38";>212fa65 fixed maven being picky https://github.com/tcurdt/jdependency/commit/1b212f1b237cfc1de129cad705180477ece912bb";>1b212f1 ignore build artifacts https://github.com/tcurdt/jdependency/commit/38d6c0651fd2ca06fad4472c20f35637871c5125";>38d6c06 prepared release https://github.com/tcurdt/jdependency/commit/17fec7808ca09b0c039ce9296ecb9d17879156f4";>17fec78 Update dependency org.apache.maven.plugins:maven-clean-plugin to v3.3.1 https://github.com/tcurdt/jdependency/commit/51537fbf5248e1182147998441de9861ad8206f9";>51537fb Update dependency org.apache.maven.plugins:maven-shade-plugin to v3.5.0 https://github.com/tcurdt/jdependency/commit/c498f8b9ea703aa5441b64edf9ba1d1771a8f451";>c498f8b Update dependency org.apache.maven.plugins:maven-surefire-report-plugin to v3... https://github.com/tcurdt/jdependency/commit/1429be643865cc826ca894c7c0e28b3ca28d";>1429be6 Update dependency org.apache.maven.plugins:maven-project-info-reports-plugin ... https://github.com/tcurdt/jdependency/commit/bea5cfeee4677d9244e8d9e47fa257ee5e53dc64";>bea5cfe Update dependency org.apache.maven.plugins:maven-surefire-plugin to v3.1.2 https://github.com/tcurdt/jdependency/commit/6084325758bbbc0e16c7fbcff0c62facb77f47bb";>6084325 Update dependency org.apache.maven.plugins:maven-release-plugin to v3.0.1 Additional commits viewable in https://github.com/tcurdt/jdependency/compare/jdependency-2.8.0...jdependency-2.9.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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-wrapper] danishcake opened a new pull request, #107: [MWRAPPER-114] - Maven wrapper relative distributionUrl does not work…
danishcake opened a new pull request, #107: URL: https://github.com/apache/maven-wrapper/pull/107 … on Windows There is a Path -> URI -> Path roundtrip which was being incorrectly carried out. For Windows file URIs like file:///C:/test calling distUrl.getPath() resulted in /C:/test, which Paths.get could not handle. Existing behaviour is preserved for non-file URIs 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/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MWRAPPER-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. - [x] 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. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`)**This fails, but so does master. I could not find any documentation on how to create a suitable development environment to have the tests pass** 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) - [ ] 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] [Commented] (MWRAPPER-114) Maven wrapper relative distributionUrl does not work on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753896#comment-17753896
]
ASF GitHub Bot commented on MWRAPPER-114:
-
danishcake opened a new pull request, #107:
URL: https://github.com/apache/maven-wrapper/pull/107
… on Windows
There is a Path -> URI -> Path roundtrip which was being incorrectly carried
out. For Windows file URIs like
file:///C:/test
calling distUrl.getPath() resulted in /C:/test, which Paths.get could not
handle. Existing behaviour is preserved for non-file URIs
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/MWRAPPER) 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 `[MWRAPPER-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MWRAPPER-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.
- [x] 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.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
verify`)**This fails, but so does master. I could not find any documentation on
how to create a suitable development environment to have the tests pass**
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)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Maven wrapper relative distributionUrl does not work on Windows
> ---
>
> Key: MWRAPPER-114
> URL: https://issues.apache.org/jira/browse/MWRAPPER-114
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 3.2.0
> Environment: Windows
>Reporter: Edward Woolhouse
>Priority: Normal
>
> If Maven Wrapper is used with a relative distributionUrl on Windows then an
> error message indicating invalid path characters is shown.
>
> {code:java}
> # Directory structure
> ./mvnw
> ./mvnw.cmd
> ./.mvn/wrapper/maven-wrapper.jar
> ./.mvn/wrapper/maven-wrapper.properties
> ...{code}
> {code:java}
> # maven-wrapper.properties
> distributionUrl=apache-maven-3.8.8-bin.zip
> wrapperUrl=maven-wrapper.jar{code}
> When run
> {code:java}
> ./mvnw
> ...
> java.nio.file.InvalidPathException: Illegal char <:> at index 2:
> /C:/some-path/apache-maven-3.8.8.zip {code}
> This is caused by PathAssembler.java:getBaseName unnecessarilly stringifying
> the distibution URL. The fix is as follows
> {code:java}
> private String getBaseName(URI distUrl) {
> - return Paths.get(distUrl.getPath()).getFileName().toString();
> + return Paths.get(distUrl).getFileName().toString();
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-114) Maven wrapper relative distributionUrl does not work on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753897#comment-17753897
]
Edward Woolhouse commented on MWRAPPER-114:
---
Pull request raised https://github.com/apache/maven-wrapper/pull/107
> Maven wrapper relative distributionUrl does not work on Windows
> ---
>
> Key: MWRAPPER-114
> URL: https://issues.apache.org/jira/browse/MWRAPPER-114
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Jar
>Affects Versions: 3.2.0
> Environment: Windows
>Reporter: Edward Woolhouse
>Priority: Normal
>
> If Maven Wrapper is used with a relative distributionUrl on Windows then an
> error message indicating invalid path characters is shown.
>
> {code:java}
> # Directory structure
> ./mvnw
> ./mvnw.cmd
> ./.mvn/wrapper/maven-wrapper.jar
> ./.mvn/wrapper/maven-wrapper.properties
> ...{code}
> {code:java}
> # maven-wrapper.properties
> distributionUrl=apache-maven-3.8.8-bin.zip
> wrapperUrl=maven-wrapper.jar{code}
> When run
> {code:java}
> ./mvnw
> ...
> java.nio.file.InvalidPathException: Illegal char <:> at index 2:
> /C:/some-path/apache-maven-3.8.8.zip {code}
> This is caused by PathAssembler.java:getBaseName unnecessarilly stringifying
> the distibution URL. The fix is as follows
> {code:java}
> private String getBaseName(URI distUrl) {
> - return Paths.get(distUrl.getPath()).getFileName().toString();
> + return Paths.get(distUrl).getFileName().toString();
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] nick-ling opened a new issue, #877: Failed to load native library:jansi-2.4.0-d705f3ccea969984-libjansi.so
nick-ling opened a new issue, #877: URL: https://github.com/apache/maven-mvnd/issues/877 There is a problem with the maven configuration environment in Synology ```shell limbo@Limbo-NAS:/opt$ java -version java version "1.8.0_202" Java(TM) SE Runtime Environment (build 1.8.0_202-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode) limbo@Limbo-NAS:/opt$ mvn -v Failed to load native library:jansi-2.4.0-320a2697b8944d1c-libjansi.so. The native library file at /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64 java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so: /tmp/jansi-2.4.0-320a2697b8944d1c-libjansi.so: failed to map segment from shared object Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /opt/maven38 Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: /volume1/container/common/opt/config/jdk8/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.302+", arch: "amd64", family: "unix" limbo@Limbo-NAS:/opt$ ``` > Upgrade the jdk of higher version ```shell limbo@Limbo-NAS:/volume1/container/common/opt/config$ sudo vim /etc/profile limbo@Limbo-NAS:/volume1/container/common/opt/config$ source /etc/profile limbo@Limbo-NAS:/volume1/container/common/opt/config$ java -version java version "17.0.8" 2023-07-18 LTS Java(TM) SE Runtime Environment (build 17.0.8+9-LTS-211) Java HotSpot(TM) 64-Bit Server VM (build 17.0.8+9-LTS-211, mixed mode, sharing) limbo@Limbo-NAS:/volume1/container/common/opt/config$ mvn -v Failed to load native library:jansi-2.4.0-51613297cfd7b049-libjansi.so. The native library file at /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64 java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so: /tmp/jansi-2.4.0-51613297cfd7b049-libjansi.so: failed to map segment from shared object Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39) Maven home: /opt/maven38 Java version: 17.0.8, vendor: Oracle Corporation, runtime: /volume1/container/common/opt/config/jdk17 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.302+", arch: "amd64", family: "unix" limbo@Limbo-NAS:/volume1/container/common/opt/config$ ``` The problem still exists！ How should I solve the problem？ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
