[GitHub] [maven] olamy commented on pull request #1218: [MNG-7863] don't email on s390 failures. The regular results are enough.
olamy commented on PR #1218: URL: https://github.com/apache/maven/pull/1218#issuecomment-1703728184 @kun-lu20 if you need this you need to convince @elharo . Sorry but it's really beyond my motivation... good luck... -- 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] [Resolved] (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
]
Henning Schmiedehausen resolved MJAVADOC-767.
-
Fix Version/s: 4.0.0
Resolution: Fixed
> 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: 4.0.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] [Assigned] (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
]
Henning Schmiedehausen reassigned MJAVADOC-767:
---
Assignee: Henning Schmiedehausen
> 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
>
> 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)
[GitHub] [maven-javadoc-plugin] hgschmie opened a new pull request, #228: [MJAVADOC-770] Implement legacy mode for Java 9+
hgschmie opened a new pull request, #228: URL: https://github.com/apache/maven-javadoc-plugin/pull/228 A lot of existing projects that don't use module descriptors but only automatic module naming have moved past Java 8. However, when trying to build docs, the javadoc plugin assumes that the project is modularized and starts using the module path which leads to problems with documentation generation. This change introduces a new configuration setting `` which is turned off by default. When turning on, the javadoc plugin will continue to construct just a classpath (and not a module path) for the javadoc tool, even if the jdk version is 9 or greater. Includes integration test and documentation. 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/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [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 -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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] gnodet merged pull request #1221: [MNG-7861] Remove artifacts which should be kept hidden
gnodet merged PR #1221: URL: https://github.com/apache/maven/pull/1221 -- 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] [Closed] (MNG-7861) Plugins which used stax / woodstox are broken
[
https://issues.apache.org/jira/browse/MNG-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7861.
Resolution: Fixed
> Plugins which used stax / woodstox are broken
> -
>
> Key: MNG-7861
> URL: https://issues.apache.org/jira/browse/MNG-7861
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.0.0-alpha-8
>
>
> Due to export:
> {code:java}
> org.codehaus.woodstox:stax2-api
> {code}
> classes from {{stax2-api}} are not available for plugins.
> eg:
> {code:java}
> mvn versions:2.16.0:set -DnewVersion=1.0.0
> [ERROR] Failed to execute goal
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set (default-cli) on project
> exec-maven-plugin: Execution default-cli of goal
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set failed: A required class
> was missing while executing
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set:
> org/codehaus/stax2/XMLInputFactory2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1313425780
##
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:
##
@@ -152,14 +150,20 @@ private ClassRealm createRealm(
List parentImports,
Map foreignImports,
List artifacts) {
-Set artifactIds = new LinkedHashSet<>();
+Set artifactIds = Collections.emptySet();
Review Comment:
Reverting this line according to avoid problems
--
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] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1313425324
##
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:
##
@@ -301,20 +305,22 @@ private void callDelegates(
}
private Set populateRealm(ClassRealm classRealm,
List constituents) {
-Set includedIds = new LinkedHashSet<>();
+Set includedIds = Collections.emptySet();
Review Comment:
Fine with me, thanks for clarifying. Reverting this line
--
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] [Resolved] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen resolved SUREFIRE-2190.
--
Fix Version/s: 3.x-candidate
Resolution: Fixed
> optional dependencies and JPMS modules confuse surefire
> ---
>
> Key: SUREFIRE-2190
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Assignee: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.x-candidate, 3.2.0
>
>
> The surefire plugin, when executing tests for JPMS code, patches the test
> code "into" the module under test (using {{{}--patch-module{}}}). This work
> for compile+runtime dependencies (`requires`) but not for compile
> required/runtime optional dependencies ({{{}requires static{}}}).
> The plugin only adds the module under test using {{--add-modules
> module.under.test.id}} to the JVM that is executing the test classes. As
> {{requires static}} dependencies are not loaded transitively, any dependency
> that is optional for the main artifact but required for test code is not
> found.
> clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
> This repo contains three artifacts with identical code:
> thing1 builds a main artifact without JPMS
> thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
> jakarta.annotation.
> thing3 builds a main artifact with a compile-only ({{requires static}})
> dependency on jakarta.annotation.
> The code and its test classes are otherwise identical.
> Running {{mvn -DskipTests}} clean install builds all three modules and the
> test code.
> Running {{mvn surefire:test}} passes the tests in the first two modules but
> fails in the third.
> Explanation:
> The surefire plugin, when it executes tests using JPMS adds all referenced
> modules to the module path (in this case the module under test itself and the
> jakarta.annotations-api jar). It then adds the main module using
> {{--add-modules}} and patches this module with the test classes (using
> {{{}-patch-module{}}}, so that the test classes execute as part of the module.
> In case of a compile+runtime ({{requires}}) relationship, the JVM will find
> the required JPMS module on the module path and add it as accessible. This is
> why the "thing2" tests pass.
> In case of a compile only/runtime optional ({{requires static}})
> relationship, the JVM will not add the module transitively as it is
> considered a compilation-only dependency. For the code under test to be able
> to access the classes from jakarta.annotation, they must be declared as a
> module. However, the test code only adds the module under test with
> {{--add-modules}}. So the test classes do not find any classes from the
> jakarta.annotation module and the test fails.
> The fix is simple: Instead of just adding the module under test using
> {{--add-modules}}, the surefire plugin should use {{-add-modules
> ALL-MODULE-PATH}}.
> Which is correct, because the code is not looking for compile time only
> dependencies but actual runtime dependencies where the code under execution
> may also need to access optional runtime dependencies (see
> [https://nipafx.dev/java-modules-optional-dependencies/] for a slightly
> longer explanation).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] ppalaga commented on issue #874: How is mvnd used in eclipse or intellij idea？
ppalaga commented on issue #874: URL: https://github.com/apache/maven-mvnd/issues/874#issuecomment-1703184882 > maybe need doc introduce how to use in eclipse,e.g build package release mvnd is a command line tool and it works also in Eclipse Terminal. Press CTRL+ALT+T and use mvnd as in any other console. I do not see much to document here. > any plan to make a plugin in eclipse or idea like maven? No, this project has no such plan. -- 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] [Assigned] (MNG-7861) Plugins which used stax / woodstox are broken
[
https://issues.apache.org/jira/browse/MNG-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7861:
Assignee: Guillaume Nodet
> Plugins which used stax / woodstox are broken
> -
>
> Key: MNG-7861
> URL: https://issues.apache.org/jira/browse/MNG-7861
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-8
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.0.0-alpha-8
>
>
> Due to export:
> {code:java}
> org.codehaus.woodstox:stax2-api
> {code}
> classes from {{stax2-api}} are not available for plugins.
> eg:
> {code:java}
> mvn versions:2.16.0:set -DnewVersion=1.0.0
> [ERROR] Failed to execute goal
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set (default-cli) on project
> exec-maven-plugin: Execution default-cli of goal
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set failed: A required class
> was missing while executing
> org.codehaus.mojo:versions-maven-plugin:2.16.0:set:
> org/codehaus/stax2/XMLInputFactory2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] elharo commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
elharo commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1313207880
##
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:
##
@@ -301,20 +305,22 @@ private void callDelegates(
}
private Set populateRealm(ClassRealm classRealm,
List constituents) {
-Set includedIds = new LinkedHashSet<>();
+Set includedIds = Collections.emptySet();
Review Comment:
You're saying that at this commit, mixing mutable and immutable lists is not
a problem. That's likely true. However there's no guarantee this will still be
true in a commit 5 years down the road. I've seen slipping an immutable list
into something that wasn't expecting it cause very painful production problems.
It's just safer to always use one or the other, and make sure the declared
types make it clear which is being used. Any collection not explicitly declared
as immutable should not be immutable. Yes, this is a design flaw in the Java
Collections API going back to Java 1.1, but it's a design flaw we have to live
with.
--
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-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
AlexanderAshitkin commented on code in PR #91: URL: https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1312170655 ## src/test/projects/include-exclude/pom.xml: ## @@ -0,0 +1,51 @@ + +http://www.w3.org/2001/XMLSchema-instance"; xmlns="http://maven.apache.org/POM/4.0.0"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> + +4.0.0 +org.apache.maven.caching.test.include-exclude +include-exclude +0.0.1-SNAPSHOT +jar + + +1.8 +1.8 + + + + extraFile.txt + second_folder_outside_src + + **/excluded_subfolder/** Review Comment: Please notice that the documentation describes the parameters as follows: ``` Paths to exclude from source code search. Relative paths calculated from the current project/module root ``` Please notice the documentation doesn't say this is a pattern, a glob, or an ant expression. We need to update the documentation to reflect the support for globs and how they are applied. The key issue is whether the base dir is prepended, with or without leading slashes. To make it deterministic, we might follow this approach: * If the pattern starts with `/`, it is considered an absolute path expression * If not, any path expression is prepended by the absolute project dir path * The content of the properties will be interpreted as a glob expression. -- 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-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
AlexanderAshitkin commented on code in PR #91: URL: https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1312155125 ## src/test/projects/include-exclude/pom.xml: ## @@ -0,0 +1,51 @@ + +http://www.w3.org/2001/XMLSchema-instance"; xmlns="http://maven.apache.org/POM/4.0.0"; + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> + +4.0.0 +org.apache.maven.caching.test.include-exclude +include-exclude +0.0.1-SNAPSHOT +jar + + +1.8 +1.8 + + + + extraFile.txt + second_folder_outside_src + + **/excluded_subfolder/** + + folder_outside_src/this_one_should_NOT_be_scanned.txt Review Comment: It will be good to cover ambiguous cases here: 1. just `excluded_subfolder` - previously, I expected to have the whole dir subtree excluded consistently with `second_folder_outside_src`. Now - it excludes only a file with this name. 2. just `excluded_subfolder/**` - it should exclude `/excluded_subfolder/**`, but not `/subfolder/excluded_subfolder/**` 3. `/tmp/**` - I believe it should exclude the absolute path, e.g. all tmp files -- 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-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
AlexanderAshitkin commented on code in PR #91:
URL:
https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1311031579
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +185,101 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.projectGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
-org.apache.maven.model.Build build = project.getBuild();
-filteredOutPaths = new ArrayList<>(Arrays.asList(
-normalizedPath(build.getDirectory()), // target by default
-normalizedPath(build.getOutputDirectory()),
-normalizedPath(build.getTestOutputDirectory(;
+this.baseDirectoryGlobPrefix = baseDirPath.toString().replace("\\",
"/") + "/";
+
+addDefaultExcludeSection(project);
List excludes = config.getGlobalExcludePaths();
for (Exclude excludePath : excludes) {
-filteredOutPaths.add(Paths.get(excludePath.getValue()));
+addToExcludedSection(excludePath.getValue(), true);
}
for (String propertyName : properties.stringPropertyNames()) {
if (propertyName.startsWith(CACHE_EXCLUDE_NAME)) {
String propertyValue = properties.getProperty(propertyName);
-Path path = Paths.get(propertyValue);
-filteredOutPaths.add(path);
+addToExcludedSection(propertyValue, true);
+
if (LOGGER.isDebugEnabled()) {
LOGGER.debug(
-"Adding an excludePath from property '{}', values
is '{}', path is '{}' ",
-propertyName,
-propertyValue,
-path);
+"Adding an excludePath from property '{}', value
is '{}'", propertyName, propertyValue);
}
}
}
CacheUtils.debugPrintCollection(
-LOGGER,
-filteredOutPaths,
-"List of excluded paths (checked either by fileName or by
startsWith prefix)",
-"Path entry");
+LOGGER, inputExcludePathMatcherString, "List of excluded glob
patterns", "Pattern");
this.fileComparator = new PathIgnoringCaseComparator();
}
+private void addDefaultExcludeSection(MavenProject project) {
+
+Build build = project.getBuild();
+Path buildDirectoryPath = normalizedPath(build.getDirectory());
+Path outputDirectoryPath = normalizedPath(build.getOutputDirectory());
+Path testOutputDirectoryPath =
normalizedPath(build.getTestOutputDirectory());
+addToExcludedSection(
+
convertToPathMatcherFileSeperator(buildDirectoryPath.toString()) +
GLOB_SX_FULL_SUB_TREE,
+false); // target by default
+
+if (!outputDirectoryPath.startsWith(buildDirectoryPath)) {
+addToExcludedSection(
+
convertToPathMatcherFileSeperator(outputDirectoryPath.toString()) +
GLOB_SX_FULL_SUB_TREE,
+false); // target/classes by default
+}
+if (!testOutputDirectoryPath.startsWith(buildDirectoryPath)) {
+addToExcludedSection(
+
convertToPathMatcherFileSeperator(testOutputDirectoryPath.toString()) +
GLOB_SX_FULL_SUB_TREE,
+false); // target/test-classes by default
+}
+}
+
+private String convertToPathMatcherFileSeperator(String path) {
+return path.replace("\\", "/");
+}
+
+/**
+ * Add a value from the excluded section list to the directories and/or
the filenames ban list.
+ * @param excludedValue a value from the exclude list
+ */
+private void addToExcludedSection(String excludedValue, boolean
addProjectBaseDir) {
Review Comment:
Why need the `addProjectBaseDir` parameter? Intuitively, the project dir
should always be prepended. Could that lead to an `exclude` applied to an
unexpected subtree? Like `dir1/file.txt` applied to `/dir2/dir1/file.txt`?
--
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-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
AlexanderAshitkin commented on code in PR #91:
URL:
https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1313150946
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -633,13 +714,7 @@ private static boolean isReadable(Path entry) throws
IOException {
}
private boolean isFilteredOutSubpath(Path path) {
-Path normalized = path.normalize();
-for (Path filteredOutDir : filteredOutPaths) {
-if (normalized.startsWith(filteredOutDir)) {
-return true;
-}
-}
-return false;
+return inputExcludeDirectoryPathMatchers.stream().anyMatch(matcher ->
matcher.stopTreeWalking(path));
Review Comment:
Well, there are different semantics now and before for project-level
properties.
Before: declaring `mydir/mysubdir` exclusion was
filtering out the whole subtree (through the `Path#startsWith`)
Now: declaring `mydir/mysubdir` doesn't exclude anything.
```
FileSystems.getDefault().getPathMatcher("glob:dir");
System.out.println(pathMatcher.matches(Paths.get("dir/file.txt")));`
-OUT-
false
```
This is what I meant - properties might assume the exclusion of directories.
For consistency, we must update docs, keep the path semantics, or migrate
properties to globs/regex semantics, delegating filtering expressions to the
users. But the main point is that it should be consistent with inclusion
semantics (and maven in general), transparent to an end user, and
deterministic.
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +184,94 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.defaultFilenameGlob =
properties.getProperty(CACHE_INPUT_GLOB_NAME, config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
+this.baseDirectoryGlob = baseDirPath.toString().replace("\\", "/") +
"/";
+
org.apache.maven.model.Build build = project.getBuild();
-filteredOutPaths = new ArrayList<>(Arrays.asList(
-normalizedPath(build.getDirectory()), // target by default
-normalizedPath(build.getOutputDirectory()),
-normalizedPath(build.getTestOutputDirectory(;
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/classes by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getTestOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/test-classes by default
List excludes = config.getGlobalExcludePaths();
for (Exclude excludePath : excludes) {
-filteredOutPaths.add(Paths.get(excludePath.getValue()));
+addToExcludedSection(excludePath.getValue(), true);
}
for (String propertyName : properties.stringPropertyNames()) {
if (propertyName.startsWith(CACHE_EXCLUDE_NAME)) {
String propertyValue = properties.getProperty(propertyName);
-Path path = Paths.get(propertyValue);
-filteredOutPaths.add(path);
+addToExcludedSection(propertyValue, true);
+
if (LOGGER.isDebugEnabled()) {
LOGGER.debug(
-"Adding an excludePath from property '{}', values
is '{}', path is '{}' ",
-propertyName,
-propertyValue,
-path);
+"Adding an excludePath from property '{}', value
is '{}'", propertyName, propertyValue);
}
}
}
CacheUtils.debugPrintCollection(
-LOGGER,
-filteredOutPaths,
-"List of excluded paths (checked either by fileName or by
startsWith prefix)",
-"Path entry");
+LOGGER, inputExcludePathMatcherString, "List of excluded glob
patterns", "Pattern");
this.fileComparator = new Pa
[GitHub] [maven] gnodet opened a new pull request, #1221: Remove artifacts which should be kept hidden
gnodet opened a new pull request, #1221: URL: https://github.com/apache/maven/pull/1221 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] 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. - [ ] 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 [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. - [ ] 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). [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
[GitHub] [maven] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1312999364
##
maven-core/src/test/java/org/apache/maven/classrealm/DefaultClassRealmManagerTest.java:
##
@@ -0,0 +1,164 @@
+/*
+ * 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.classrealm;
+
+import java.io.File;
+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+
+import org.apache.maven.extension.internal.CoreExports;
+import org.apache.maven.model.Model;
+import org.codehaus.plexus.DefaultPlexusContainer;
+import org.codehaus.plexus.PlexusContainer;
+import org.codehaus.plexus.PlexusContainerException;
+import org.codehaus.plexus.classworlds.realm.ClassRealm;
+import org.eclipse.aether.artifact.Artifact;
+import org.junit.jupiter.api.Test;
+import org.mockito.InOrder;
+import org.mockito.MockedStatic;
+import org.mockito.Mockito;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.Matchers.endsWith;
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.mockito.Mockito.calls;
+import static org.mockito.Mockito.inOrder;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.never;
+import static org.mockito.Mockito.when;
+
+/**
+ * @author Sebastien Doyon
+ */
+class DefaultClassRealmManagerTest {
+
+private DefaultClassRealmManager
newDefaultClassRealmManager(PlexusContainer container) {
+HashSet exportedPackages = new HashSet();
+exportedPackages.add("group1:artifact1");
+
+return new DefaultClassRealmManager(
+container,
+new ArrayList(),
+new CoreExports(new ClassRealm(null, "test", null), new
HashSet(), exportedPackages));
+}
+
+private List newTestArtifactList() {
+List artifacts = new ArrayList();
+
+Artifact artifact = mock(Artifact.class);
+when(artifact.getFile()).thenReturn(new File(new
File("local/repository"), "some/path"));
+when(artifact.getGroupId()).thenReturn("group1");
+when(artifact.getArtifactId()).thenReturn("artifact1");
+when(artifact.getExtension()).thenReturn("ext");
+when(artifact.getClassifier()).thenReturn("classifier1");
+when(artifact.getVersion()).thenReturn("1");
+artifacts.add(artifact);
+
+Artifact artifact2 = mock(Artifact.class);
+when(artifact2.getFile()).thenReturn(null);
+when(artifact2.getGroupId()).thenReturn("group1");
+when(artifact2.getArtifactId()).thenReturn("artifact2");
+when(artifact2.getExtension()).thenReturn("ext");
+when(artifact2.getClassifier()).thenReturn("classifier1");
+when(artifact2.getVersion()).thenReturn("1");
+artifacts.add(artifact2);
+
+return artifacts;
+}
+
+private Model newTestModel() {
+Model model = new Model();
+model.setGroupId("modelGroup1");
+model.setArtifactId("modelArtifact1");
+model.setVersion("modelVersion1");
+
+return model;
+}
+
+@Test
+void testDebugEnabled() throws PlexusContainerException {
+Logger logger = mock(Logger.class);
+when(logger.isDebugEnabled()).thenReturn(true);
+
+DefaultClassRealmManager classRealmManager;
+ClassRealm classRealm;
+
+InOrder verifier = inOrder(logger);
+
+PlexusContainer container = new DefaultPlexusContainer();
+
+try (MockedStatic mockedLoggerFactory =
Mockito.mockStatic(LoggerFactory.class)) {
Review Comment:
I agree with the principle. I did this test class because in the it was
specified in the contribution guidelines : "Make sure you have added the
necessary tests (JUnit/[Core IT
tests](https://maven.apache.org/core-its/core-it-suite/)) for your changes.".
And I found at least one other test example that was testing log messages, the
DefaultToolchainTest class. I don't know if any external tools may be expecting
maven to log in a specific format, like Maven Daemon? If you think the tests
are a bad idea, I am willing to remove, just tell me.
--
This is an
[GitHub] [maven] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1312983567
##
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:
##
@@ -301,20 +305,22 @@ private void callDelegates(
}
private Set populateRealm(ClassRealm classRealm,
List constituents) {
-Set includedIds = new LinkedHashSet<>();
+Set includedIds = Collections.emptySet();
Review Comment:
What is your concerns? The **includedIds** reference a collection that stays
local to the methods **populateRealm** and **createRealm**, it is not escaping
the class and is not an instance variable. The set is only modified if the
logger debug log level is enabled (line 319 and 321), it is set with a
LinkedHashSet on the same condition (lines 310 and 311). I see no point of
creating a LinkedHashSet if the log level is not at least debug since this
collection is only used for logging purpose. What do you think according to
this?
--
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] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1312969152
##
maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java:
##
@@ -152,14 +150,20 @@ private ClassRealm createRealm(
List parentImports,
Map foreignImports,
List artifacts) {
-Set artifactIds = new LinkedHashSet<>();
+Set artifactIds = Collections.emptySet();
Review Comment:
I think in this case it is not a problem. The **artifactIds** reference a
collection that stays local to the method, it is not escaping the class and is
not an instance variable. Knowing that, the emptySet() is not modified in this
state of the code. Do you agree on the safe usage?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MNG-7864) Fix the S390x to use IT branches
[ https://issues.apache.org/jira/browse/MNG-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-7864: - Summary: Fix the S390x to use IT branches (was: Fix the S390x so use IT branches) > 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] sebastien-doyon commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
sebastien-doyon commented on code in PR #1220: URL: https://github.com/apache/maven/pull/1220#discussion_r1312963669 ## maven-core/pom.xml: ## @@ -153,7 +153,7 @@ under the License. org.mockito - mockito-core + mockito-inline Review Comment: This was needed for the DefaultClassRealmManagerTest test class tube able to mock the static method LoggerFactory.getLogger(). According to your comment on this test class bellow, this should be reverted if you think the test is not wanted. -- 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] (MBUILDCACHE-71) buildinfo.xml should be stored after storing the project's artifacts
Amir Hadadi created MBUILDCACHE-71:
--
Summary: buildinfo.xml should be stored after storing the
project's artifacts
Key: MBUILDCACHE-71
URL: https://issues.apache.org/jira/browse/MBUILDCACHE-71
Project: Maven Build Cache Extension
Issue Type: Improvement
Affects Versions: 1.0.1
Reporter: Amir Hadadi
In certain failure cases it's possible that only part of a module artifacts get
stored in the local and remote storage. In that case if buildinfo.xml got
stored, the extension will later incorrectly attempt to restore the partially
cached build.
Because buildinfo.xml is used as an indication that the cached artifacts exist,
I propose to reorder the logic in
{code:java}
CacheControllerImpl.save(){code}
so that
{code:java}
localCache.saveBuildInfo(cacheResult, build);{code}
will happen after the project's artifacts are stored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-871) 3.6.0 reporting Used undeclared dependency that is only used indirectly
[ https://issues.apache.org/jira/browse/MDEP-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761287#comment-17761287 ] Michael Dürig commented on MDEP-871: Same on our side, this started to fail a couple of builds that passed with 3.5.0. > 3.6.0 reporting Used undeclared dependency that is only used indirectly > > > Key: MDEP-871 > URL: https://issues.apache.org/jira/browse/MDEP-871 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.6.0 >Reporter: Joe Barnett >Priority: Major > > reproducer project: > [https://github.com/josephlbarnett/mdep-3.6.0-analyze-reproducer] > if you change the maven-dependency-plugin version to 3.5.0 in the above > project, the maven build will pass. > > It appears that referencing an interface that extends another interface (and > calling a method in that interface) is pulling that extended interface in as > a used dependency? In this case the > `software.amazon.awssdk.services.kms.KmsClientBuilder` interface extends an > interface from the aws-core jar > (`software.amazon.awssdk.awscore.client.builder.AwsClientBuilder`), and the > example code calls the `.region()` method. In 3.5.0 the aws-core dependency > was not treated as used, but in 3.6.0 it is. Unclear if this is only > interface extension or classes implementing interfaces would have a similar > problem? > > Is this intended behavior? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] elharo commented on pull request #1218: [MNG-7863] don't email on s390 failures. The regular results are enough.
elharo commented on PR #1218: URL: https://github.com/apache/maven/pull/1218#issuecomment-1702581818 I stand behind my change, which was filed as a JIRA and approved. I would have CC's some additional reviewers had I noticed the earlier changes at the time, or had their been comments in the file indicating why there was this strange email address for no obvious reason. Nonetheless those earlier changes were wrong and should have been reverted. The CI should not send email to random external addresses. This is not the correct way to monitor a CI. Furthermore the S390 builds were in fact broken. See MNG-7864. That's why I noticed this in the first place. If the email was being sent, it wasn't being read and acted on. -- 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] elharo commented on a diff in pull request #1220: [MNG-7866] Improvements to the logging API usage (technical debt)
elharo commented on code in PR #1220:
URL: https://github.com/apache/maven/pull/1220#discussion_r1312882728
##
maven-core/pom.xml:
##
@@ -153,7 +153,7 @@ under the License.
org.mockito
- mockito-core
+ mockito-inline
Review Comment:
Is this change related?
##
maven-core/src/test/java/org/apache/maven/classrealm/DefaultClassRealmManagerTest.java:
##
@@ -0,0 +1,164 @@
+/*
+ * 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.classrealm;
+
+import java.io.File;
+import java.util.ArrayList;
+import java.util.HashSet;
+import java.util.List;
+
+import org.apache.maven.extension.internal.CoreExports;
+import org.apache.maven.model.Model;
+import org.codehaus.plexus.DefaultPlexusContainer;
+import org.codehaus.plexus.PlexusContainer;
+import org.codehaus.plexus.PlexusContainerException;
+import org.codehaus.plexus.classworlds.realm.ClassRealm;
+import org.eclipse.aether.artifact.Artifact;
+import org.junit.jupiter.api.Test;
+import org.mockito.InOrder;
+import org.mockito.MockedStatic;
+import org.mockito.Mockito;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.Matchers.endsWith;
+import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.mockito.Mockito.calls;
+import static org.mockito.Mockito.inOrder;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.never;
+import static org.mockito.Mockito.when;
+
+/**
+ * @author Sebastien Doyon
+ */
+class DefaultClassRealmManagerTest {
+
+private DefaultClassRealmManager
newDefaultClassRealmManager(PlexusContainer container) {
+HashSet exportedPackages = new HashSet();
+exportedPackages.add("group1:artifact1");
+
+return new DefaultClassRealmManager(
+container,
+new ArrayList(),
+new CoreExports(new ClassRealm(null, "test", null), new
HashSet(), exportedPackages));
+}
+
+private List newTestArtifactList() {
+List artifacts = new ArrayList();
+
+Artifact artifact = mock(Artifact.class);
+when(artifact.getFile()).thenReturn(new File(new
File("local/repository"), "some/path"));
+when(artifact.getGroupId()).thenReturn("group1");
+when(artifact.getArtifactId()).thenReturn("artifact1");
+when(artifact.getExtension()).thenReturn("ext");
+when(artifact.getClassifier()).thenReturn("classifier1");
+when(artifact.getVersion()).thenReturn("1");
+artifacts.add(artifact);
+
+Artifact artifact2 = mock(Artifact.class);
+when(artifact2.getFile()).thenReturn(null);
+when(artifact2.getGroupId()).thenReturn("group1");
+when(artifact2.getArtifactId()).thenReturn("artifact2");
+when(artifact2.getExtension()).thenReturn("ext");
+when(artifact2.getClassifier()).thenReturn("classifier1");
+when(artifact2.getVersion()).thenReturn("1");
+artifacts.add(artifact2);
+
+return artifacts;
+}
+
+private Model newTestModel() {
+Model model = new Model();
+model.setGroupId("modelGroup1");
+model.setArtifactId("modelArtifact1");
+model.setVersion("modelVersion1");
+
+return model;
+}
+
+@Test
+void testDebugEnabled() throws PlexusContainerException {
+Logger logger = mock(Logger.class);
+when(logger.isDebugEnabled()).thenReturn(true);
+
+DefaultClassRealmManager classRealmManager;
+ClassRealm classRealm;
+
+InOrder verifier = inOrder(logger);
+
+PlexusContainer container = new DefaultPlexusContainer();
+
+try (MockedStatic mockedLoggerFactory =
Mockito.mockStatic(LoggerFactory.class)) {
Review Comment:
In general, I'm skeptical of testing log messages. I tend to think of them
as side effects that can change pretty freely, and not part of a public API
contract that should be tested.
##
maven-core/src/main/java/org/apache/maven/plugin/internal/MojoLogWrapper.java:
##
@@ -34,7 +34,9 @@ public MojoLogWrapper(Logger logger) {
}
public void debu
[jira] [Updated] (MNG-7867) [REGRESSION] 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant
[ https://issues.apache.org/jira/browse/MNG-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7867: Summary: [REGRESSION] 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant (was: Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant.) > [REGRESSION] 'profiles.profile[ossrh].repositories.repository.[ossrh].url' > contains an expression but should be a constant > -- > > Key: MNG-7867 > URL: https://issues.apache.org/jira/browse/MNG-7867 > Project: Maven > Issue Type: Bug >Reporter: Jörg Hohwiller >Assignee: Guillaume Nodet >Priority: Major > > With MNG-7047 new validation rules have been added to maven 4. > I always thought the maven devs finally started to understand that it is > required to distinguish between the developer view on a POM and the consumer > POM. > Your implementation in maven 4 validates the developer view on a POM and not > the consumer POM. > I do have a generic parent POM that uses some variables as it is used by many > child projects with their own repos like: > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380 > and > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360 > This works fine in maven 3.x > My vision for Maven 4.x was that such variables would be replaced at build > time and the POM that actually gets deployed for consumers could even be > stripped from its parent hierarchy, etc. > Therefore my expectation is that in my pom.xml on the local disc such > variable expressions are fully fine. > I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ > and my vision from the start was that this plugin should only be a temporary > workaround and that maven could implement such features in much smarter way > in its core so my plugin could then be thrown away. > Still in maven 4.x I am using the plugin and it will resolve these variables > but the validation rules get into the way and break my build leading to a > regession bug for something that works in maven 3.x. > Why can you implement to resolve the value of such expression if you want to > have it static/fixed in the final POM? > Thanks for making maven and considering my thoughts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] eliasbalasis commented on issue #836: `Could not acquire write lock for…` errors
eliasbalasis commented on issue #836: URL: https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377 > Windows Filesystem and file-locking is a disaster I couldn't agree more. > the error does not occur even not when I run parallel builds Trust me, it is purely non-deterministic, I thought the same at first. Even Named Locks don't seem to be working perfectly yet. "-Daether.connector.basic.threads=1 -Daether.connector.resumeDownloads=false" hasn't worked perfectly either. From where I stand, this is a dead end at the moment. My hopes lie with Maven 3.9 -- 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] [Assigned] (MNG-7867) Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant.
[ https://issues.apache.org/jira/browse/MNG-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-7867: Assignee: Guillaume Nodet > Maven 4 regression: > 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an > expression but should be a constant. > -- > > Key: MNG-7867 > URL: https://issues.apache.org/jira/browse/MNG-7867 > Project: Maven > Issue Type: Bug >Reporter: Jörg Hohwiller >Assignee: Guillaume Nodet >Priority: Major > > With MNG-7047 new validation rules have been added to maven 4. > I always thought the maven devs finally started to understand that it is > required to distinguish between the developer view on a POM and the consumer > POM. > Your implementation in maven 4 validates the developer view on a POM and not > the consumer POM. > I do have a generic parent POM that uses some variables as it is used by many > child projects with their own repos like: > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380 > and > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360 > This works fine in maven 3.x > My vision for Maven 4.x was that such variables would be replaced at build > time and the POM that actually gets deployed for consumers could even be > stripped from its parent hierarchy, etc. > Therefore my expectation is that in my pom.xml on the local disc such > variable expressions are fully fine. > I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ > and my vision from the start was that this plugin should only be a temporary > workaround and that maven could implement such features in much smarter way > in its core so my plugin could then be thrown away. > Still in maven 4.x I am using the plugin and it will resolve these variables > but the validation rules get into the way and break my build leading to a > regession bug for something that works in maven 3.x. > Why can you implement to resolve the value of such expression if you want to > have it static/fixed in the final POM? > Thanks for making maven and considering my thoughts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7867) Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant.
[ https://issues.apache.org/jira/browse/MNG-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761248#comment-17761248 ] Guillaume Nodet commented on MNG-7867: -- This is under discussion. My proposal is to upload the effective flattened pom as the consumer pom for non pom-packaged artifacts. > Maven 4 regression: > 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an > expression but should be a constant. > -- > > Key: MNG-7867 > URL: https://issues.apache.org/jira/browse/MNG-7867 > Project: Maven > Issue Type: Bug >Reporter: Jörg Hohwiller >Priority: Major > > With MNG-7047 new validation rules have been added to maven 4. > I always thought the maven devs finally started to understand that it is > required to distinguish between the developer view on a POM and the consumer > POM. > Your implementation in maven 4 validates the developer view on a POM and not > the consumer POM. > I do have a generic parent POM that uses some variables as it is used by many > child projects with their own repos like: > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380 > and > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360 > This works fine in maven 3.x > My vision for Maven 4.x was that such variables would be replaced at build > time and the POM that actually gets deployed for consumers could even be > stripped from its parent hierarchy, etc. > Therefore my expectation is that in my pom.xml on the local disc such > variable expressions are fully fine. > I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ > and my vision from the start was that this plugin should only be a temporary > workaround and that maven could implement such features in much smarter way > in its core so my plugin could then be thrown away. > Still in maven 4.x I am using the plugin and it will resolve these variables > but the validation rules get into the way and break my build leading to a > regession bug for something that works in maven 3.x. > Why can you implement to resolve the value of such expression if you want to > have it static/fixed in the final POM? > Thanks for making maven and considering my thoughts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] hohwille commented on issue #836: `Could not acquire write lock for…` errors
hohwille commented on issue #836: URL: https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702409617 ``` $ mvnd -v Apache Maven Daemon (mvnd) 1.0-m7 windows-amd64 native client (b2ef5d81997adbcdb72dc8c5603722538fa641fe) Terminal: org.jline.terminal.impl.jansi.win.JansiWinSysTerminal Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f) Maven home: D:\projects\salog\software\mvnd\mvn Java version: 17.0.8, vendor: Eclipse Adoptium, runtime: D:\projects\salog\software\java Default locale: en_US, platform encoding: UTF-8 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" ``` But I also get this: ``` Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire write lock for 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock' in 30 SECONDS at org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire (NamedLockFactoryAdapter.java:202) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve (DefaultArtifactResolver.java:271) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts (DefaultArtifactResolver.java:259) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies (DefaultRepositorySystem.java:352) ``` Windows Filesystem and file-locking is a disaster. However, with regular `mvn` the error does not occur even not when I run parallel builds (e.g. `-T 2C`). Please also note that also with `mvnd` the error goes away if I do not specify concurrent build (no `-T` option). -- 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-7867) Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant.
[ https://issues.apache.org/jira/browse/MNG-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761232#comment-17761232 ] Michael Osipov commented on MNG-7867: - [~gnodet] > Maven 4 regression: > 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an > expression but should be a constant. > -- > > Key: MNG-7867 > URL: https://issues.apache.org/jira/browse/MNG-7867 > Project: Maven > Issue Type: Bug >Reporter: Jörg Hohwiller >Priority: Major > > With MNG-7047 new validation rules have been added to maven 4. > I always thought the maven devs finally started to understand that it is > required to distinguish between the developer view on a POM and the consumer > POM. > Your implementation in maven 4 validates the developer view on a POM and not > the consumer POM. > I do have a generic parent POM that uses some variables as it is used by many > child projects with their own repos like: > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380 > and > https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360 > This works fine in maven 3.x > My vision for Maven 4.x was that such variables would be replaced at build > time and the POM that actually gets deployed for consumers could even be > stripped from its parent hierarchy, etc. > Therefore my expectation is that in my pom.xml on the local disc such > variable expressions are fully fine. > I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ > and my vision from the start was that this plugin should only be a temporary > workaround and that maven could implement such features in much smarter way > in its core so my plugin could then be thrown away. > Still in maven 4.x I am using the plugin and it will resolve these variables > but the validation rules get into the way and break my build leading to a > regession bug for something that works in maven 3.x. > Why can you implement to resolve the value of such expression if you want to > have it static/fixed in the final POM? > Thanks for making maven and considering my thoughts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7867) Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant.
Jörg Hohwiller created MNG-7867: --- Summary: Maven 4 regression: 'profiles.profile[ossrh].repositories.repository.[ossrh].url' contains an expression but should be a constant. Key: MNG-7867 URL: https://issues.apache.org/jira/browse/MNG-7867 Project: Maven Issue Type: Bug Reporter: Jörg Hohwiller With MNG-7047 new validation rules have been added to maven 4. I always thought the maven devs finally started to understand that it is required to distinguish between the developer view on a POM and the consumer POM. Your implementation in maven 4 validates the developer view on a POM and not the consumer POM. I do have a generic parent POM that uses some variables as it is used by many child projects with their own repos like: https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L378-L380 and https://github.com/m-m-m/parent/blob/6e27d18337321c4f9d02e83c0b71313543555157/pom.xml#L360 This works fine in maven 3.x My vision for Maven 4.x was that such variables would be replaced at build time and the POM that actually gets deployed for consumers could even be stripped from its parent hierarchy, etc. Therefore my expectation is that in my pom.xml on the local disc such variable expressions are fully fine. I am the original author of https://www.mojohaus.org/flatten-maven-plugin/ and my vision from the start was that this plugin should only be a temporary workaround and that maven could implement such features in much smarter way in its core so my plugin could then be thrown away. Still in maven 4.x I am using the plugin and it will resolve these variables but the validation rules get into the way and break my build leading to a regession bug for something that works in maven 3.x. Why can you implement to resolve the value of such expression if you want to have it static/fixed in the final POM? Thanks for making maven and considering my thoughts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
