[jira] [Commented] (MCOMPILER-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)
[
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789615#comment-17789615
]
ASF GitHub Bot commented on MCOMPILER-381:
--
olamy commented on code in PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1404715210
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1539,36 +1546,41 @@ private static List
removeEmptyCompileSourceRoots(List compileSo
* generated classes and if we got a file which is = the build-started
timestamp, then we caught a file which
* got changed during this build.
*
- * @return true if at least one single dependency has changed.
+ * @return {@code true} if at least one single dependency has changed.
*/
-protected boolean isDependencyChanged() {
-if (session == null) {
+private boolean isDependencyChanged() {
Review Comment:
breaking backward compat protected -> private
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1400,10 +1406,11 @@ protected int getRequestThreadCount() {
return session.getRequest().getDegreeOfConcurrency();
}
-protected Date getBuildStartTime() {
-MavenExecutionRequest request = session.getRequest();
-Date buildStartTime = request == null ? new Date() :
request.getStartTime();
-return buildStartTime == null ? new Date() : buildStartTime;
+private Optional getBuildStartTime() {
Review Comment:
uhm you're changing a protected method. this is breaking any backward compat.
> Refactoring needed for isDependencyChanged / Using fileExtensions
> (AbstractCompilerMojo)
>
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is
> being changed within the {{isDependencyChanged}} method. This attribute is
> also being used by the method {{hasNewFile}} which is a kind of confusing (a
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}}
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379].
> It should be investigated how this code can be made more clear and maybe
> easier to understand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-381] - Refactor incremental detection [maven-compiler-plugin]
olamy commented on code in PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1404715210
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1539,36 +1546,41 @@ private static List
removeEmptyCompileSourceRoots(List compileSo
* generated classes and if we got a file which is = the build-started
timestamp, then we caught a file which
* got changed during this build.
*
- * @return true if at least one single dependency has changed.
+ * @return {@code true} if at least one single dependency has changed.
*/
-protected boolean isDependencyChanged() {
-if (session == null) {
+private boolean isDependencyChanged() {
Review Comment:
breaking backward compat protected -> private
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1400,10 +1406,11 @@ protected int getRequestThreadCount() {
return session.getRequest().getDegreeOfConcurrency();
}
-protected Date getBuildStartTime() {
-MavenExecutionRequest request = session.getRequest();
-Date buildStartTime = request == null ? new Date() :
request.getStartTime();
-return buildStartTime == null ? new Date() : buildStartTime;
+private Optional getBuildStartTime() {
Review Comment:
uhm you're changing a protected method. this is breaking any backward compat.
--
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] (MCOMPILER-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)
[
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789612#comment-17789612
]
ASF GitHub Bot commented on MCOMPILER-381:
--
olamy commented on code in PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1404714195
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1156,6 +1151,16 @@ public void execute() throws MojoExecutionException,
CompilationFailureException
incrementalBuildHelper.beforeRebuildExecution(incrementalBuildHelperRequest);
+// Cleanup the generated sources directory
+if (getGeneratedSourcesDirectory() != null) {
Review Comment:
Why cleaning this directory? I don't understand the reason. Can you please
explain?
reading the change as it it looks this will remove the generated-sources
added via the phase `generate-sources` or any phase before compile.
Maybe I read the change in a wrong way?
> Refactoring needed for isDependencyChanged / Using fileExtensions
> (AbstractCompilerMojo)
>
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is
> being changed within the {{isDependencyChanged}} method. This attribute is
> also being used by the method {{hasNewFile}} which is a kind of confusing (a
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}}
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379].
> It should be investigated how this code can be made more clear and maybe
> easier to understand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-381] - Refactor incremental detection [maven-compiler-plugin]
olamy commented on code in PR #181:
URL:
https://github.com/apache/maven-compiler-plugin/pull/181#discussion_r1404714195
##
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##
@@ -1156,6 +1151,16 @@ public void execute() throws MojoExecutionException,
CompilationFailureException
incrementalBuildHelper.beforeRebuildExecution(incrementalBuildHelperRequest);
+// Cleanup the generated sources directory
+if (getGeneratedSourcesDirectory() != null) {
Review Comment:
Why cleaning this directory? I don't understand the reason. Can you please
explain?
reading the change as it it looks this will remove the generated-sources
added via the phase `generate-sources` or any phase before compile.
Maybe I read the change in a wrong way?
--
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] (MCOMPILER-538) Do not add target/generated-sources/annotations to the source roots
[
https://issues.apache.org/jira/browse/MCOMPILER-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789599#comment-17789599
]
Jorge Solórzano commented on MCOMPILER-538:
---
This PR requires a test to ensure it actually fixes the bug.
> Do not add target/generated-sources/annotations to the source roots
> ---
>
> Key: MCOMPILER-538
> URL: https://issues.apache.org/jira/browse/MCOMPILER-538
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Daniel Mensinger
>Priority: Major
>
> Adding the generated source root ({{target/generated-sources/annotations}})
> is not required for javac. Additionally adding the generated source root
> results in compilation errors with annotation processors generating code
> unless the generated-sources dir is cleaned.
> Specifically, the following steps result in compilation errors:
> # run {{mvn clean}}
> # Modify a source file that is consumed by the annotation processor so that
> there is a compilation error, but the annotation processor still runs (add or
> remove a parameter in a method call).
> # run {{mvn compile}} --> the generated file exists but there is no class
> file for the source file.
> # Fix the "bug" from step 2
> # run {{mvn compile}} again --> compilation should succeed, but it fails.
>
> Example code:
> [https://github.com/mensinda/quarkus-stuff/tree/annotationProcessingTest]
> Use the {{annotationProcessingTest}} branch!
> For step 2 this change can be used:
> {code:java}
> diff --git a/code/src/main/java/bar/MyAnnotatedClass.java
> b/code/src/main/java/bar/MyAnnotatedClass.java
> index bbfef7a..a303924 100644
> --- a/code/src/main/java/bar/MyAnnotatedClass.java
> +++ b/code/src/main/java/bar/MyAnnotatedClass.java
> @@ -4,7 +4,7 @@ import foo.MyAnnotation;
> @MyAnnotation
> public class MyAnnotatedClass {
> -MyGeneratedClass generatedClass = new MyGeneratedClass();
> +MyGeneratedClass generatedClass = new MyGeneratedClass(false);
> // foo
> {code}
>
> To see that *not* adding {{target/generated-sources/annotations}} helps run
> {{mvn -X compile}} and copy the {{Command line options:}}. Then run {{javac}}
> manually, but remove the {{target/generated-sources/annotations}} from the
> {{-sourcepath}} list, but *not* the {{-s}} parameter.
>
> PR with a fix: https://github.com/apache/maven-compiler-plugin/pull/191
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.codehaus.mojo:build-helper-maven-plugin from 3.4.0 to 3.5.0 [maven-site]
dependabot[bot] opened a new pull request, #467: URL: https://github.com/apache/maven-site/pull/467 Bumps [org.codehaus.mojo:build-helper-maven-plugin](https://github.com/mojohaus/build-helper-maven-plugin) from 3.4.0 to 3.5.0. Release notes Sourced from https://github.com/mojohaus/build-helper-maven-plugin/releases;>org.codehaus.mojo:build-helper-maven-plugin's releases. 3.5.0 Changes New features and improvements Add skipIfMissing flag (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/187;>#187) https://github.com/hgschmie;>@hgschmie Add skip flags (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/186;>#186) https://github.com/hgschmie;>@hgschmie Deprecate maven-version goal (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/191;>#191) https://github.com/slawekjaranowski;>@slawekjaranowski Dependency updates Bump org.codehaus.mojo:mojo-parent from 76 to 77 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/190;>#190) https://github.com/dependabot;>@dependabot Bump mojo-parent from 75 to 76 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/185;>#185) https://github.com/dependabot;>@dependabot Bump mojo-parent from 74 to 75 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/184;>#184) https://github.com/dependabot;>@dependabot Bump plexus-utils from 3.5.1 to 4.0.0 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/183;>#183) https://github.com/dependabot;>@dependabot Bump maven-plugin-annotations from 3.8.2 to 3.9.0 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/182;>#182) https://github.com/dependabot;>@dependabot Maintenance Use plugins versions from parent in ITs (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/192;>#192) https://github.com/slawekjaranowski;>@slawekjaranowski Use Maven Apache shared GitHub action (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/189;>#189) https://github.com/slawekjaranowski;>@slawekjaranowski Fix antrun version in ITs (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/188;>#188) https://github.com/slawekjaranowski;>@slawekjaranowski Bump mojo-parent from 75 to 76 (https://redirect.github.com/mojohaus/build-helper-maven-plugin/pull/185;>#185) https://github.com/dependabot;>@dependabot Commits https://github.com/mojohaus/build-helper-maven-plugin/commit/820d0a8107a7dcad4fe0c9e9b0cf44e9ceefd807;>820d0a8 [maven-release-plugin] prepare release 3.5.0 https://github.com/mojohaus/build-helper-maven-plugin/commit/497a9f58a035e80bf401eb6fe01dbf3fc312a032;>497a9f5 Use plugins versions from parent in ITs https://github.com/mojohaus/build-helper-maven-plugin/commit/ad1076e467aa818c3f7e7596d0a51958f35e70d1;>ad1076e Add skipIfMissing flag (https://redirect.github.com/mojohaus/build-helper-maven-plugin/issues/187;>#187) https://github.com/mojohaus/build-helper-maven-plugin/commit/faab9369445fef414a671a9df41cafcbd2d3bf7e;>faab936 Bump project version to next minor 3.5.0 https://github.com/mojohaus/build-helper-maven-plugin/commit/b49b7e6c2cffe430fa39a6bb0bcc9d323e523eb8;>b49b7e6 Add skip flags (https://redirect.github.com/mojohaus/build-helper-maven-plugin/issues/186;>#186) https://github.com/mojohaus/build-helper-maven-plugin/commit/223744155deb6b01bd401a911cc5245bafee753b;>2237441 Deprecate maven-version goal https://github.com/mojohaus/build-helper-maven-plugin/commit/ef477d8b3d1bed075937a0cb68535330fcf77f29;>ef477d8 Drop stale action https://github.com/mojohaus/build-helper-maven-plugin/commit/3df0c7f86bf6015254906ebc306495dc2fedb766;>3df0c7f Bump org.codehaus.mojo:mojo-parent from 76 to 77 https://github.com/mojohaus/build-helper-maven-plugin/commit/e6e9ba6f1d9f365413fbd8eb506781ebaca6e1e6;>e6e9ba6 Use Maven Apache shared GitHub action https://github.com/mojohaus/build-helper-maven-plugin/commit/d7cb1c5f100fe22d51eb0607104b243d536908d0;>d7cb1c5 Fix antrun version in ITs Additional commits viewable in https://github.com/mojohaus/build-helper-maven-plugin/compare/3.4.0...3.5.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
[jira] [Updated] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MENFORCER-390:
-
Description:
With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
that the canonical path of a file is the same as the absolute path.
But not all absolute paths are canonical.
* absolute paths can involve symbolic links
* and they are allowed to have parts which are relative
** {{/../}}
** {{/./}}
And when it fails to handle a path, it can report that a file does not exist,
even though the local system will resolve the path.
A blunt solution might be three separate rules:
* requireFileExists
** the provided path must resolve to a file (which may be a directory or link)
* requireCanonicalFileExists
** the provided path must exist as a canonical file
* requireCasesenstiveFileExists
** the provided path must file a file
** the file name must have the same case (upper//lower) as the
** the parts of the path from the file up must have the same case until they
go through a symbolic link
I have used the "nio" package to handle some of stuff before. I will add a
comment with some java code I would start with. Since the outcome here is very
dependent on the use case you pick, the java will be "meta code" with ??? where
you have to know the use case to know the outcome.
but basically, with "nio" you can march up a path checking for symbolic links
and such.
was:
With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
that the canonical path of a file is the same as the absolute path.
But not all absolute paths are canonical.
* absolute paths can involve symbolic links
* and they are allowed to have parts which are relative
** {{/../}}
** {{/./}}
And when it fails to handle a path, it can report that a file does not exist,
even though the local system will resolve the path.
A blunt solution might be three separate rules:
* requireFileExists
** the provided path must resolve to a file (which may be a directory or link)
* requireCanonicalFileExists
** the provided path must exist as a canonical file
* requireCasesenstiveFileExists
** the provided path must file a file
** the file name must have the same case (upper//lower) as the
** the parts of the path from the file up must have the same case until they
go through a symbolic link
I have used the "nio" package to handle some of stuff before. I will add a
comment with some java code I would start with. Since the outcome here is very
dependent on the use case you pick, the java will be "meta code" with ??? where
you have to know the use case to know the outcome.
but basically, with "nio" you can march up a path checking for symbolic links
and such.
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MENFORCER-390:
-
Description:
With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
that the canonical path of a file is the same as the absolute path.
But not all absolute paths are canonical.
* absolute paths can involve symbolic links
* and they are allowed to have parts which are relative
** {{/../}}
** {{/./}}
And when it fails to handle a path, it can report that a file does not exist,
even though the local system will resolve the path.
A blunt solution might be three separate rules:
* requireFileExists
** the provided path must resolve to a file (which may be a directory or link)
* requireCanonicalFileExists
** the provided path must exist as a canonical file
* requireCasesenstiveFileExists
** the provided path must file a file
** the file name must have the same case (upper//lower) as the
** the parts of the path from the file up must have the same case until they
go through a symbolic link
I have used the "nio" package to handle some of stuff before. I will add a
comment with some java code I would start with. Since the outcome here is very
dependent on the use case you pick, the java will be "meta code" with ??? where
you have to know the use case to know the outcome.
but basically, with "nio" you can march up a path checking for symbolic links
and such.
was:
With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
that the canonical path of a file is the same as the absolute path.
But not all absolute paths are canonical.
* absolute paths can involve symbolic links
* and they are allowed to have parts which are relative
** {{/../}}
** {{/./}}{{}}{{}}{{}}
And when it fails to handle a path, it can report that a file does not exist,
even though the local system will resolve the path.
A blunt solution might be three separate rules:
* requireFileExists
** the provided path must resolve to a file (which may be a directory or link)
* requireCanonicalFileExists
** the provided path must exist as a canonical file
* requireCasesenstiveFileExists
** the provided path must file a file
** the file name must have the same case (upper//lower) as the
** the parts of the path from the file up must have the same case until they
go through a symbolic link
I have used the "nio" package to handle some of stuff before. I will add a
comment with some java code I would start with. Since the outcome here is very
dependent on the use case you pick, the java will be "meta code" with ??? where
you have to know the use case to know the outcome.
but basically, with "nio" you can march up a path checking for symbolic links
and such.
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789535#comment-17789535
]
ASF GitHub Bot commented on MENFORCER-390:
--
slawekjaranowski commented on PR #297:
URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1825978578
Ok, the simple `file.exists()` should be enough in normal usage ...
I only think - if we don't break and special cases ... but agree more
complicated check should be done optionally or by next rule
By the way we can mention in documentation a way how file existence is
checked to be clear.
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}{{}}{{}}{{}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]
slawekjaranowski commented on PR #297: URL: https://github.com/apache/maven-enforcer/pull/297#issuecomment-1825978578 Ok, the simple `file.exists()` should be enough in normal usage ... I only think - if we don't break and special cases ... but agree more complicated check should be done optionally or by next rule By the way we can mention in documentation a way how file existence is checked to be clear. -- 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-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789518#comment-17789518
]
ASF GitHub Bot commented on MNG-7920:
-
gnodet commented on PR #1305:
URL: https://github.com/apache/maven/pull/1305#issuecomment-1825897618
This will conflict with #1323 ...
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the {{bom}} packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd;>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the maven-install-plugin which is
> capable of handling that...but I assumed that this conversion is done by core?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7920] Fix usage of packaging BOM fails in maven-install-plugin [maven]
gnodet commented on PR #1305: URL: https://github.com/apache/maven/pull/1305#issuecomment-1825897618 This will conflict with #1323 ... -- 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-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789515#comment-17789515
]
Jason commented on MENFORCER-390:
-
I guess another options would be to inform the plugins if the filesystem is
case-sensitve or not. This may mean needing to have multiple configurations and
it would still have limitations, but it would at least be obvious what was
happening.
I've placed that here:
https://github.com/roadSurfer/maven-enforcer/tree/MENFORCER-390_impl2
Testing will be an issue, one would need to have differing filesystems
available.
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}{{}}{{}}{{}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [I] Failed to install artifact xxx [maven-mvnd]
harryssuperman commented on issue #862: URL: https://github.com/apache/maven-mvnd/issues/862#issuecomment-1825876587 Hi folks, after testing a lot, we have discovered our IT Security department introduced a new antivirus (trendmicro) and i think it was the main reason for the problem. This is not happening in the last few days but we didn't also any change. It was even funny, because after a failed build i was testing und manually run a new build and it was not failing. So i suggest @chenfeg to check if something like that is happening also for you. -- 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
Re: [PR] Unpack and scan for Chronicle specific packages to encrypt. [maven-shade-plugin]
yevgenp closed pull request #203: Unpack and scan for Chronicle specific packages to encrypt. URL: https://github.com/apache/maven-shade-plugin/pull/203 -- 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-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789503#comment-17789503
]
ASF GitHub Bot commented on MENFORCER-390:
--
roadSurfer opened a new pull request, #297:
URL: https://github.com/apache/maven-enforcer/pull/297
This reverts the change from MENFORCER-364 as this led to a regressions with
symbolic links.
The fundamental issue is that there is no clean way to deal with
case-sensitivity as OSs can have multuple filesystems mounted that follow
different rules. Thus the simple `file.exists()` is, despite the limitations,
probably best. Those requiring more stringent checks writing their own handling.
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/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.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] 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.
- [ ] 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`).
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).
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}{{}}{{}}{{}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MENFORCER-390] "requireFilesExist" no longer handles non-canonical paths [maven-enforcer]
roadSurfer opened a new pull request, #297: URL: https://github.com/apache/maven-enforcer/pull/297 This reverts the change from MENFORCER-364 as this led to a regressions with symbolic links. The fundamental issue is that there is no clean way to deal with case-sensitivity as OSs can have multuple filesystems mounted that follow different rules. Thus the simple `file.exists()` is, despite the limitations, probably best. Those requiring more stringent checks writing their own handling. 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/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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] 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. - [ ] 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`). 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). -- 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-390) "requireFilesExist" no longer handles non-canonical paths
[
https://issues.apache.org/jira/browse/MENFORCER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789499#comment-17789499
]
Jason commented on MENFORCER-390:
-
Hit this yesterday and was deeply confused as to what was going on. I worked
around the issue by using Atlassian's `bash-maven-plugin` and some basic BASH,
but this is less than optimal.
Looking at the change from MENFORCE-364, I honestly think it should be reverted.
Filesystems are case-(in)sensitve, not operating systems.
`requireFilesDontExist` was not updated. Handling symbolic links was broken.
OSs can have *multiple* filesystems connected with different case-sensitivity.
Despite all the limitations, `file.exists()` is the simplest way to deal with
this without creating unexpected edge cases.
Those who have more exacting/unusual needs can craft a custom plugin (or
something) to handle their case. They should not break Maven for everyone.
All that said, I did implement a partial fix which highlights some of the
issues that can arise. You can view it here:
https://github.com/roadSurfer/maven-enforcer/tree/MENFORCER-390_impl
> "requireFilesExist" no longer handles non-canonical paths
> -
>
> Key: MENFORCER-390
> URL: https://issues.apache.org/jira/browse/MENFORCER-390
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: requireFilesExist, Standard Rules
>Affects Versions: 3.0.0
>Reporter: Gene Smith
>Priority: Major
>
> With the commit to resolve MENFORCER-364, the rule "requireFileExists" checks
> that the canonical path of a file is the same as the absolute path.
> But not all absolute paths are canonical.
> * absolute paths can involve symbolic links
> * and they are allowed to have parts which are relative
> ** {{/../}}
> ** {{/./}}{{}}{{}}{{}}
> And when it fails to handle a path, it can report that a file does not exist,
> even though the local system will resolve the path.
> A blunt solution might be three separate rules:
> * requireFileExists
> ** the provided path must resolve to a file (which may be a directory or
> link)
> * requireCanonicalFileExists
> ** the provided path must exist as a canonical file
> * requireCasesenstiveFileExists
> ** the provided path must file a file
> ** the file name must have the same case (upper//lower) as the
> ** the parts of the path from the file up must have the same case until they
> go through a symbolic link
> I have used the "nio" package to handle some of stuff before. I will add a
> comment with some java code I would start with. Since the outcome here is
> very dependent on the use case you pick, the java will be "meta code" with
> ??? where you have to know the use case to know the outcome.
> but basically, with "nio" you can march up a path checking for symbolic links
> and such.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7945) Fix profile settings being injected into consumer POMs
Guillaume Nodet created MNG-7945: Summary: Fix profile settings being injected into consumer POMs Key: MNG-7945 URL: https://issues.apache.org/jira/browse/MNG-7945 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-alpha-8 Reporter: Tamas Cservenak Assignee: Guillaume Nodet Fix For: 4.0.0-alpha-9 The consumer POMs may end up containing information from user settings. The reason is that they are currently built from the effective POMs. They need to be rebuilt based on raw models. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789496#comment-17789496
]
Guillaume Nodet commented on MNG-7919:
--
I think INFO is fine. The goal was to not disturb maven 3 projects by
displaying a warning or error.
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] update shared utils [maven-surefire]
michael-o commented on PR #652: URL: https://github.com/apache/maven-surefire/pull/652#issuecomment-1825793991 https://issues.apache.org/jira/browse/MSHARED-1014 -- 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] (MRESOLVER-440) Clean up transport names, configuration properties and documentation
[ https://issues.apache.org/jira/browse/MRESOLVER-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-440: -- Summary: Clean up transport names, configuration properties and documentation (was: Clean up transport names and configuration properties) > Clean up transport names, configuration properties and documentation > > > Key: MRESOLVER-440 > URL: https://issues.apache.org/jira/browse/MRESOLVER-440 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Currently ApacheHC transport is called "http" while JDK transport is called > "jdk" and JettyHC is "jetty". Also, historically all transports were > connectors, and later was "basic" connector added and transports introduced, > but many transport related configuration properties remained as "connector". > Proposed changes: > * Rename ApacheHC to "apache" transport, to "free" the "http" config key. > There will be no "http" transport anymore, it is reserved for "shared HTTP > related config" that is shared among multiple HTTP transports (apache, jdk, > jetty...). > * Rename transport specific configurations from "aether.connector.apache..." > and "aether.connector.jdk..." to their proper names "aether.transport..." > * keep "aether.transport.http..." for generic HTTP protocol related > configuration (that may be used by all HTTP using transports). > * align many other (for historical reason) badly keyed property to "proper > place". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-440) Clean up transport names, configuration properties and documentation
[ https://issues.apache.org/jira/browse/MRESOLVER-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-440: -- Description: Currently ApacheHC transport is called "http" while JDK transport is called "jdk" and JettyHC is "jetty". Also, historically all transports were connectors, and later was "basic" connector added and transports introduced, but many transport related configuration properties remained as "connector". Proposed changes: * Rename ApacheHC to "apache" transport, to "free" the "http" config key. There will be no "http" transport anymore, it is reserved for "shared HTTP related config" that is shared among multiple HTTP transports (apache, jdk, jetty...). * Rename transport specific configurations from "aether.connector.apache..." and "aether.connector.jdk..." to their proper names "aether.transport..." * keep "aether.transport.http..." for generic HTTP protocol related configuration (that may be used by all HTTP using transports). * align many other (for historical reason) badly keyed property to "proper place". * sort out documentation for these, ideally the page should be generated was: Currently ApacheHC transport is called "http" while JDK transport is called "jdk" and JettyHC is "jetty". Also, historically all transports were connectors, and later was "basic" connector added and transports introduced, but many transport related configuration properties remained as "connector". Proposed changes: * Rename ApacheHC to "apache" transport, to "free" the "http" config key. There will be no "http" transport anymore, it is reserved for "shared HTTP related config" that is shared among multiple HTTP transports (apache, jdk, jetty...). * Rename transport specific configurations from "aether.connector.apache..." and "aether.connector.jdk..." to their proper names "aether.transport..." * keep "aether.transport.http..." for generic HTTP protocol related configuration (that may be used by all HTTP using transports). * align many other (for historical reason) badly keyed property to "proper place". > Clean up transport names, configuration properties and documentation > > > Key: MRESOLVER-440 > URL: https://issues.apache.org/jira/browse/MRESOLVER-440 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Currently ApacheHC transport is called "http" while JDK transport is called > "jdk" and JettyHC is "jetty". Also, historically all transports were > connectors, and later was "basic" connector added and transports introduced, > but many transport related configuration properties remained as "connector". > Proposed changes: > * Rename ApacheHC to "apache" transport, to "free" the "http" config key. > There will be no "http" transport anymore, it is reserved for "shared HTTP > related config" that is shared among multiple HTTP transports (apache, jdk, > jetty...). > * Rename transport specific configurations from "aether.connector.apache..." > and "aether.connector.jdk..." to their proper names "aether.transport..." > * keep "aether.transport.http..." for generic HTTP protocol related > configuration (that may be used by all HTTP using transports). > * align many other (for historical reason) badly keyed property to "proper > place". > * sort out documentation for these, ideally the page should be generated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SUREFIRE-2216) Upgrade plugins and components (in ITs)
Michael Osipov created SUREFIRE-2216: Summary: Upgrade plugins and components (in ITs) Key: SUREFIRE-2216 URL: https://issues.apache.org/jira/browse/SUREFIRE-2216 Project: Maven Surefire Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: next-release * Upgrade to Maven Surefire 3.2.2 * Upgrade to Commons Lang 3.14.0 * Upgrade to Commons Compress 1.25.0 * Upgrade to Commons IO 2.15.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2211: - Fix Version/s: next-release > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > Fix For: next-release > > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned SUREFIRE-2211: Assignee: Michael Osipov > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Assignee: Michael Osipov >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-364) requireFilesExist rule should be case sensitive
[
https://issues.apache.org/jira/browse/MENFORCER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789430#comment-17789430
]
Jason commented on MENFORCER-364:
-
[~st-torbjornsvensson] - MENFORCER-390 covers the symbolic link regression.
> requireFilesExist rule should be case sensitive
> ---
>
> Key: MENFORCER-364
> URL: https://issues.apache.org/jira/browse/MENFORCER-364
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Johannes Goebel
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> When using the enforcer plugin with a configuration using the
> {{requireFilesExist}} rule, as follows, the case of the existence of files
> cannot be enforced case sensitive.
> {code:xml}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0-M3
>
>
> enforce-files-exist
>
> enforce
>
>
>
>
>
> src/main/resources/i18n_de.properties
>
>
>
> true
>
>
>
>
> {code}
> For example, if the file {{src/main/resources/i18n_DE.properties}} exists,
> but not {{src/main/resources/i18n_de.properties}} the execution of the plugin
> will succeed.
> Unfortunately in my use case, this is exactly the requirement. I have not
> found a way to enforce case sensitivity for this rule.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789411#comment-17789411 ] Michael Osipov commented on SUREFIRE-2211: -- OK. Let's wait a few days. I should then be visible publically. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789399#comment-17789399 ] Robert Seidel commented on SUREFIRE-2211: - I created a report and got the review id 9076264. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789379#comment-17789379
]
Michael Osipov commented on SUREFIRE-2211:
--
https://bugreport.java.com/bugreport/ and reference this issue as well. It will
be flagged as {{maven-found}}.
> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Priority: Major
>
> We are using the configuration parameter additionalClasspathElements
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
> to provide a log4j2 xml configuration during tests. There is configured an
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found
> without issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEPLOY-315) Documentation
Alberto Gallardo created MDEPLOY-315:
Summary: Documentation
Key: MDEPLOY-315
URL: https://issues.apache.org/jira/browse/MDEPLOY-315
Project: Maven Deploy Plugin
Issue Type: Improvement
Reporter: Alberto Gallardo
Rewrite
[usage#the-deploy-deploy-mojo|[https://maven.apache.org/plugins/maven-deploy-plugin/usage.html#the-deploy-deploy-mojo
|https://maven.apache.org/plugins/maven-deploy-plugin/usage.html#the-deploy-deploy-mojo]]
to clarify that the distributionManagement can be also configured without
modifying the `pom`.
Currently, the documentation states:
{quote}To enable this mojo to function, you must include a valid
section POM, [...]
{quote}
Suggesting that the pom must specify this element and must be modified
accordingly. This suggestion is reinforced in
[deploy-mojo#altDeploymentRepository|https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository]
:
{quote}
h4. **
Specifies an alternative repository to which the project artifacts should be
deployed (other than those specified in ).{quote}
(my interpretation is that `distributionManagement` must be present)
Unfortunately, this mislead me to think that the only way to provide this
configuration was by modifying the pom. I later found that
`altDeploymentRepository` could be used *instead of* the
`distributionManagement` in the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789374#comment-17789374
]
ASF GitHub Bot commented on MNG-7919:
-
CrazyHZM opened a new pull request, #1325:
URL: https://github.com/apache/maven/pull/1325
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/
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-7919]Missing .mvn directory is only reported in DEBUG mode [maven]
CrazyHZM opened a new pull request, #1325: URL: https://github.com/apache/maven/pull/1325 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
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789371#comment-17789371 ] Robert Seidel edited comment on SUREFIRE-2211 at 11/24/23 8:40 AM: --- I have no account for https://bugs.openjdk.org/ so I cannot raise an issue there. And you have to be an author to create issues (so no easy registration is possible). was (Author: JIRAUSER295788): I have no account for https://bugs.openjdk.org/ so I cannot raise an issue there. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789371#comment-17789371 ] Robert Seidel commented on SUREFIRE-2211: - I have no account for https://bugs.openjdk.org/ so I cannot raise an issue there. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[
https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789367#comment-17789367
]
Jorge Solórzano commented on MCOMPILER-542:
---
{quote}too chatty: that's why I proposed just a single summary at the end of
the patch, to know that the patch was activated and how much it had to patch.
More detail, even in debug, is too much noise IMHO
{quote}
Sure, I added a summary at the end of the patch printing all the modules that
were patched, right now is with info level to not be a silent feature, can be
changed to debug or whatever.
{quote}notice that even if JDK 22 has the fix, I expect Reproducible Builds
releases to be done with the next LTS, in near 2 years, because building
releases to Maven Central with a non LTS compiler is not a best practice
{quote}
In general, this is always activated (or the Reproducible Builds will not
work), I tried to add some conditionals to skip versions > 21 where the JDK fix
will be available, but I reverted that since I could not simply use the
{{java.specification.version}} to check the java version used since I also
have to check the toolchain used, so is not so trivial to add this check, it
should not be a blocker since the JDK fix will be released the next year and I
don't expect everyone building with JDK 22 in the short term, this skip based
on JDK could be added in a next version of m-compiler-p. WDYT?
> clean JDK patch version in module-info.class
>
>
> Key: MCOMPILER-542
> URL: https://issues.apache.org/jira/browse/MCOMPILER-542
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.11.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.12.0
>
>
> as seen in MJAR-275, JDK patch version in module-info.class is NOT included
> only when building with a newer JDK release using "--release" flag, see
> [https://github.com/jvm-repo-rebuild/module-info]
> issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a
> proper fix at javac level (probably for Java 22)
> and waiting for that, we need a workaround to drop the JDK patch version in
> other cases: we'll need to define where is the best place –
> m-jar-p?m-compiler-p? other?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789363#comment-17789363 ] Michael Osipov commented on SUREFIRE-2211: -- Can you raise a bug with OpenJDK? This must be documented. Then I'd link it and merge your PR with pleasure. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
