[GitHub] [maven-dependency-analyzer] michael-o commented on a diff in pull request #81: [MSHARED-1224] Prefer JDK classes to Plexus utils
michael-o commented on code in PR #81:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/81#discussion_r1161023331
##
src/main/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtils.java:
##
@@ -77,45 +77,39 @@ private static void acceptJar(URL url, ClassFileVisitor
visitor) throws IOExcept
String name = entry.getName();
// ignore files like package-info.class and module-info.class
if (name.endsWith(".class") && name.indexOf('-') == -1) {
-visitClass(name, in, visitor);
+// Jars(ZIP) always use / as the separator character
+visitClass(name, in, visitor, '/');
}
}
}
}
private static void acceptDirectory(File directory, ClassFileVisitor
visitor) throws IOException {
-if (!directory.isDirectory()) {
-throw new IllegalArgumentException("File is not a directory");
-}
-
-DirectoryScanner scanner = new DirectoryScanner();
-
-scanner.setBasedir(directory);
-scanner.setIncludes(new String[] {"**/*.class"});
-
-scanner.scan();
-String[] paths = scanner.getIncludedFiles();
-
-for (String path : paths) {
-path = path.replace(File.separatorChar, '/');
-
-File file = new File(directory, path);
+List classFiles;
+try (Stream walk = Files.walk(directory.toPath())) {
+classFiles = walk.filter(path ->
path.getFileName().toString().endsWith(".class"))
Review Comment:
Yes, indeed. It is just a wrapper.
--
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-dependency-analyzer] elharo commented on a diff in pull request #81: [MSHARED-1224] Prefer JDK classes to Plexus utils
elharo commented on code in PR #81:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/81#discussion_r1161021500
##
src/main/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtils.java:
##
@@ -77,45 +77,39 @@ private static void acceptJar(URL url, ClassFileVisitor
visitor) throws IOExcept
String name = entry.getName();
// ignore files like package-info.class and module-info.class
if (name.endsWith(".class") && name.indexOf('-') == -1) {
-visitClass(name, in, visitor);
+// Jars(ZIP) always use / as the separator character
+visitClass(name, in, visitor, '/');
}
}
}
}
private static void acceptDirectory(File directory, ClassFileVisitor
visitor) throws IOException {
-if (!directory.isDirectory()) {
-throw new IllegalArgumentException("File is not a directory");
-}
-
-DirectoryScanner scanner = new DirectoryScanner();
-
-scanner.setBasedir(directory);
-scanner.setIncludes(new String[] {"**/*.class"});
-
-scanner.scan();
-String[] paths = scanner.getIncludedFiles();
-
-for (String path : paths) {
-path = path.replace(File.separatorChar, '/');
-
-File file = new File(directory, path);
+List classFiles;
+try (Stream walk = Files.walk(directory.toPath())) {
+classFiles = walk.filter(path ->
path.getFileName().toString().endsWith(".class"))
Review Comment:
I'll have to check but I don't think that will work. The method you
reference checks if a Path ends with another Path. e.g. that
/usr/local/tmp/foo.class ends with a path for foo.class. However, I don't
think it would work for /usr/local/tmp/foo.class ending with the extension
.class.
See
https://stackoverflow.com/questions/20531247/how-to-check-the-extension-of-a-java-7-path
--
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-dependency-analyzer] michael-o commented on a diff in pull request #81: [MSHARED-1224] Prefer JDK classes to Plexus utils
michael-o commented on code in PR #81:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/81#discussion_r1161016212
##
src/main/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtils.java:
##
@@ -77,45 +77,39 @@ private static void acceptJar(URL url, ClassFileVisitor
visitor) throws IOExcept
String name = entry.getName();
// ignore files like package-info.class and module-info.class
if (name.endsWith(".class") && name.indexOf('-') == -1) {
-visitClass(name, in, visitor);
+// Jars(ZIP) always use / as the separator character
+visitClass(name, in, visitor, '/');
}
}
}
}
private static void acceptDirectory(File directory, ClassFileVisitor
visitor) throws IOException {
-if (!directory.isDirectory()) {
-throw new IllegalArgumentException("File is not a directory");
-}
-
-DirectoryScanner scanner = new DirectoryScanner();
-
-scanner.setBasedir(directory);
-scanner.setIncludes(new String[] {"**/*.class"});
-
-scanner.scan();
-String[] paths = scanner.getIncludedFiles();
-
-for (String path : paths) {
-path = path.replace(File.separatorChar, '/');
-
-File file = new File(directory, path);
+List classFiles;
+try (Stream walk = Files.walk(directory.toPath())) {
+classFiles = walk.filter(path ->
path.getFileName().toString().endsWith(".class"))
Review Comment:
There is a native `endsWith()`
--
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] (MSHARED-1224) Prefer JDK classes to Plexus utils
Slawomir Jaranowski created MSHARED-1224: Summary: Prefer JDK classes to Plexus utils Key: MSHARED-1224 URL: https://issues.apache.org/jira/browse/MSHARED-1224 Project: Maven Shared Components Issue Type: Task Components: maven-dependency-analyzer Reporter: Slawomir Jaranowski Fix For: maven-dependency-analyzer-next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-analyzer] slawekjaranowski commented on a diff in pull request #81: Prefer JDK classes to Plexus utils
slawekjaranowski commented on code in PR #81:
URL:
https://github.com/apache/maven-dependency-analyzer/pull/81#discussion_r1161009729
##
src/main/java/org/apache/maven/shared/dependency/analyzer/ClassFileVisitorUtils.java:
##
@@ -99,7 +97,8 @@ private static void acceptJar( URL url, ClassFileVisitor
visitor )
// ignore files like package-info.class and module-info.class
if ( name.endsWith( ".class" ) && name.indexOf( '-' ) == -1 )
{
-visitClass( name, in, visitor );
+// Even on Windows Jars use / as the separator character
Review Comment:
comment was changed
--
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-7757) Resolved dependencies are not taking into account dependency management
[
https://issues.apache.org/jira/browse/MNG-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MNG-7757:
-
Fix Version/s: waiting-for-feedback
> Resolved dependencies are not taking into account dependency management
> ---
>
> Key: MNG-7757
> URL: https://issues.apache.org/jira/browse/MNG-7757
> Project: Maven
> Issue Type: Bug
> Environment: Windows 10, Java 17.0.2, Maven 3.8.5
>Reporter: Daniel Puiu
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: test-maven-dependency-tree-bug.7z
>
>
> I have the following case:
> * Project C depends on project D (compile scope).
> * Project B depends on project C (compile scope) and declares project D in
> dependency management as provided.
> * Project A depends on project B (compile scope).
> Running dependency:tree on A outputs:
> {noformat}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
> test-maven-dependency-tree-bug-A ---
> [INFO] org.example:test-maven-dependency-tree-bug-A:jar:1.0-SNAPSHOT
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-B:jar:1.0-SNAPSHOT:compile
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-C:jar:1.0-SNAPSHOT:compile
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-D:jar:1.0-SNAPSHOT:compile{noformat}
> Also, building a fat jar with maven-assembly-plugin adds the content of D to
> the jar.
>
> Both plugins use org.apache.maven.DefaultProjectDependencyGraph (which is
> marked as internal and deprecated) to resolve the dependency tree. This is
> actually the reason for which I am opening the ticket on maven's side and not
> on maven-dependency-plugin and maven-assembly-plugin sides.
>
> From the
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html],
> my understanding is that D should appear as provided in the dependency tree
> and not be part of the fat jar created by assembly plugin.
>
> I have tested both plugins mainly with maven 3.8.5, but have obtained the
> same results with 4.0.0-alpha5, 3.6.3 and 3.0.5
> I have attached a multi module project on which I tested the case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7757) Resolved dependencies are not taking into account dependency management
[
https://issues.apache.org/jira/browse/MNG-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709787#comment-17709787
]
Slawomir Jaranowski commented on MNG-7757:
--
Please try with the latest version 3.5.0 of maven-dependency-plugin
> Resolved dependencies are not taking into account dependency management
> ---
>
> Key: MNG-7757
> URL: https://issues.apache.org/jira/browse/MNG-7757
> Project: Maven
> Issue Type: Bug
> Environment: Windows 10, Java 17.0.2, Maven 3.8.5
>Reporter: Daniel Puiu
>Priority: Major
> Attachments: test-maven-dependency-tree-bug.7z
>
>
> I have the following case:
> * Project C depends on project D (compile scope).
> * Project B depends on project C (compile scope) and declares project D in
> dependency management as provided.
> * Project A depends on project B (compile scope).
> Running dependency:tree on A outputs:
> {noformat}
> [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
> test-maven-dependency-tree-bug-A ---
> [INFO] org.example:test-maven-dependency-tree-bug-A:jar:1.0-SNAPSHOT
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-B:jar:1.0-SNAPSHOT:compile
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-C:jar:1.0-SNAPSHOT:compile
> [INFO] \-
> org.example:test-maven-dependency-tree-bug-D:jar:1.0-SNAPSHOT:compile{noformat}
> Also, building a fat jar with maven-assembly-plugin adds the content of D to
> the jar.
>
> Both plugins use org.apache.maven.DefaultProjectDependencyGraph (which is
> marked as internal and deprecated) to resolve the dependency tree. This is
> actually the reason for which I am opening the ticket on maven's side and not
> on maven-dependency-plugin and maven-assembly-plugin sides.
>
> From the
> [documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html],
> my understanding is that D should appear as provided in the dependency tree
> and not be part of the fat jar created by assembly plugin.
>
> I have tested both plugins mainly with maven 3.8.5, but have obtained the
> same results with 4.0.0-alpha5, 3.6.3 and 3.0.5
> I have attached a multi module project on which I tested the case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7757) Resolved dependencies are not taking into account dependency management
Daniel Puiu created MNG-7757:
Summary: Resolved dependencies are not taking into account
dependency management
Key: MNG-7757
URL: https://issues.apache.org/jira/browse/MNG-7757
Project: Maven
Issue Type: Bug
Environment: Windows 10, Java 17.0.2, Maven 3.8.5
Reporter: Daniel Puiu
Attachments: test-maven-dependency-tree-bug.7z
I have the following case:
* Project C depends on project D (compile scope).
* Project B depends on project C (compile scope) and declares project D in
dependency management as provided.
* Project A depends on project B (compile scope).
Running dependency:tree on A outputs:
{noformat}
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @
test-maven-dependency-tree-bug-A ---
[INFO] org.example:test-maven-dependency-tree-bug-A:jar:1.0-SNAPSHOT
[INFO] \- org.example:test-maven-dependency-tree-bug-B:jar:1.0-SNAPSHOT:compile
[INFO] \-
org.example:test-maven-dependency-tree-bug-C:jar:1.0-SNAPSHOT:compile
[INFO] \-
org.example:test-maven-dependency-tree-bug-D:jar:1.0-SNAPSHOT:compile{noformat}
Also, building a fat jar with maven-assembly-plugin adds the content of D to
the jar.
Both plugins use org.apache.maven.DefaultProjectDependencyGraph (which is
marked as internal and deprecated) to resolve the dependency tree. This is
actually the reason for which I am opening the ticket on maven's side and not
on maven-dependency-plugin and maven-assembly-plugin sides.
>From the
>[documentation|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html],
> my understanding is that D should appear as provided in the dependency tree
>and not be part of the fat jar created by assembly plugin.
I have tested both plugins mainly with maven 3.8.5, but have obtained the same
results with 4.0.0-alpha5, 3.6.3 and 3.0.5
I have attached a multi module project on which I tested the case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-47) Extension computes a new check sum for a project with multiple modules without any changes
[
https://issues.apache.org/jira/browse/MBUILDCACHE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maximilian Novikov closed MBUILDCACHE-47.
-
> Extension computes a new check sum for a project with multiple modules
> without any changes
> --
>
> Key: MBUILDCACHE-47
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-47
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Venelin Koulaxazov
>Priority: Critical
> Attachments: api-module-v1.xml, api-module-v2.xml,
> parent-module-v1.xml, service-module-v1.xml, service-module-v2.xml
>
>
> I have a maven project with 2 modules and a parent pom as such
> {code:java}
>
> api
> service
> {code}
> I would like to take advantage of the maven cache extension and I've added it
> in the build section of the parent pom as such
> {code:java}
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0
>
> {code}
> I've also added a maven-build-cache-config.xml file however it would seem
> that every time I run {{mvn clean package}} a different checksum is generated
> for my submodules and as a result I don't actually benefit from the caching
> since all my java files are in those submodules
> I've tried multiple configs with no luck unfortunately
> {code:java}
>
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> http://maven.apache.org/xsd/cache-config-1.0.0.xsd";>
>
> true
> XX
>
>
>
> {*.java,*.xml,*.properties}
>
> recursive=api/*
> recursive=service/*
>
>
>
> {code}
> How can I make this extension actually cache the contents of my submodules
> with the same checksum if there haven't been changes. I know this extension
> is fairly recent and I haven't been able to find any hits online.
> *EDIT*
> Commenting one of the child modules out, actually ended up working and the
> cache is kicking in correctly. Is it possible there's a limitation to the
> extension in that it scans for a single module?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MBUILDCACHE-47) Extension computes a new check sum for a project with multiple modules without any changes
[
https://issues.apache.org/jira/browse/MBUILDCACHE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maximilian Novikov resolved MBUILDCACHE-47.
---
Resolution: Not A Bug
> Extension computes a new check sum for a project with multiple modules
> without any changes
> --
>
> Key: MBUILDCACHE-47
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-47
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Venelin Koulaxazov
>Priority: Critical
> Attachments: api-module-v1.xml, api-module-v2.xml,
> parent-module-v1.xml, service-module-v1.xml, service-module-v2.xml
>
>
> I have a maven project with 2 modules and a parent pom as such
> {code:java}
>
> api
> service
> {code}
> I would like to take advantage of the maven cache extension and I've added it
> in the build section of the parent pom as such
> {code:java}
>
>
> org.apache.maven.extensions
> maven-build-cache-extension
> 1.0.0
>
> {code}
> I've also added a maven-build-cache-config.xml file however it would seem
> that every time I run {{mvn clean package}} a different checksum is generated
> for my submodules and as a result I don't actually benefit from the caching
> since all my java files are in those submodules
> I've tried multiple configs with no luck unfortunately
> {code:java}
>
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> http://maven.apache.org/xsd/cache-config-1.0.0.xsd";>
>
> true
> XX
>
>
>
> {*.java,*.xml,*.properties}
>
> recursive=api/*
> recursive=service/*
>
>
>
> {code}
> How can I make this extension actually cache the contents of my submodules
> with the same checksum if there haven't been changes. I know this extension
> is fairly recent and I haven't been able to find any hits online.
> *EDIT*
> Commenting one of the child modules out, actually ended up working and the
> cache is kicking in correctly. Is it possible there's a limitation to the
> extension in that it scans for a single module?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] michael-o commented on issue #813: mvnd and .mvn
michael-o commented on issue #813: URL: https://github.com/apache/maven-mvnd/issues/813#issuecomment-1500603572 > > > > > Ok, so add `-Dlogback.configurationFile=logback.xml` to `maven.config`? Will that always find `.mvn/logback.xml`? > > > > > > > > > > > > This is wrong! What you want is a system property, but `maven.config` is _only_ about Maven user properties. You must use `jvm.config` for this. > > > > > > > > > That's irrelevant. The question is the same with `jvm.config`... Or that mean that there's a need for yet another level of property, which may become a bit too much... > > > > > > I wouldn't say so because both files are processed in completely different ways. This matters. > > This is purely a technical problem however. Some system properties can be set before the JVM is started (using `-Dxxx` options on the JVM command line), others can be set by the java code using `System.setProperty`. Both may need to be supported, and splitting completely user properties from system properties (i.e. not setting user properties as system properties) may open the need for properties to be set by maven early (i.e. same time as user properties atm). Correct. My point was to clarify for/with the user that he is not interacting with system properties actually. -- 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-477) failWhenParentIsSnapshot does not respect onlyWhenRelease
[
https://issues.apache.org/jira/browse/MENFORCER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709776#comment-17709776
]
Peter De Maeyer commented on MENFORCER-477:
---
This is not a bug after all. I had made a mistake: I had put the
{{onlyWhenRelease}} and {{failWhenParentIsSnapshot}} directly in the
{{configuration}} section instead of _inside_ the {{requireReleaseDeps}} rule.
Once I put the parameters in the right place, it works as expected. Sorry for
the noise. This can be closed.
> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release
> version of my project only depends on release versions, including the parent,
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the
> enforcer for snapshot versions.
> *Expected:* my snapshot project build succeeds with a snapshot parent.
> *Actual:* my snapshot project build _fails_ with a snapshot parent, despite
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}}
> into account.
> The intuitive fix for me would be that the combination of both options
> behaves as expected.
> I imagine that maybe it was a design choice to keep both options completely
> independent of each other, so an acceptable alternative for me would be to
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves
> similar to {{onlyWhenRelease}} but applies to the parent only.
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unrecognised tag: 'properties' (position: START_TAG seen
> ...\n\t... @13:14) @ /home/peter/.m2/settings.xml,
> line 13, column 14
> [WARNING]
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
> [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must
> be unique but found duplicate declaration of plugin
> org.apache.maven.plugins:maven-failsafe-plugin @
> su.pernova:bom:1.1.0-SNAPSHOT,
> /home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
> line 263, column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> [INFO] Inspecting build with total of 5 modules...
> [INFO] Installing Nexus Staging features:
> [INFO] ... total of 5 executions of maven-deploy-plugin replaced with
> nexus-staging-maven-plugin
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Supernova Assertions - Parent
> [pom]
> [INFO] Supernova Assertions - Main
> [jar]
> [INFO] Supernova Assertions - JUnit 4
> [jar]
> [INFO] Supernova Assertions - JUnit 5
> [jar]
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5
> [jar]
> [INFO]
> [INFO] < su.pernova:assertions-parent
> >
> [INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT
> [1/5]
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent
> ---
> [INFO]
> [INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @
> assertions-parent ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:3.2.1:enforce
> (enforce-no-snapshots-in-releases) @ assertions-parent ---
> [INFO]
>
> [INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
> [INFO]
> [INFO] Supernova Assertions - Parent .. FAILURE [ 0.464
> s]
> [INFO] Supernova Assertions - Main SKIPPED
> [INFO] Supernova Assertions - JUnit 4 . SKIPPED
> [INFO] Supernova Assertions - JUnit 5 . SKIPPED
> [INFO] Supernova Assertion
[GitHub] [maven-mvnd] gnodet commented on issue #813: mvnd and .mvn
gnodet commented on issue #813: URL: https://github.com/apache/maven-mvnd/issues/813#issuecomment-1500598783 > > > > Ok, so add `-Dlogback.configurationFile=logback.xml` to `maven.config`? Will that always find `.mvn/logback.xml`? > > > > > > > > > This is wrong! What you want is a system property, but `maven.config` is _only_ about Maven user properties. You must use `jvm.config` for this. > > > > > > That's irrelevant. The question is the same with `jvm.config`... Or that mean that there's a need for yet another level of property, which may become a bit too much... > > I wouldn't say so because both files are processed in completely different ways. This matters. This is purely a technical problem however. Some system properties can be set before the JVM is started (using `-Dxxx` options on the JVM command line), others can be set by the java code using `System.setProperty`. Both may need to be supported, and splitting completely user properties from system properties (i.e. not setting user properties as system properties) may open the need for properties to be set by maven early (i.e. same time as user properties atm). -- 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] (MSHADE-203) "shadeTestJar" option not working?
[ https://issues.apache.org/jira/browse/MSHADE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-203. -- Resolution: Fixed > "shadeTestJar" option not working? > -- > > Key: MSHADE-203 > URL: https://issues.apache.org/jira/browse/MSHADE-203 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Aaron Curley >Priority: Minor > > So, I'm pretty new to using the maven-shade-plugin and I'm not really that > familiar with the maven-shade-plugin's design/code; however, it appears that > the option in the maven-shade-plugin configuration does not > work correctly. > __Symtoms__ > While running "mvn package" in my project (which has set to > true), maven-shade-plugin appears to perform the "test jar shading" step > (after performing the regular jar's shade), but the "shaded" test JAR doesn't > actually include any shaded dependency files (it just includes the "original" > test jar's contents, which is essentially a "no-op"). > __Possible Diagnosis__ > I took a quick look at the release code base for v2.4.1, in particularly, the > mojo/ShadeMojo.java file. In the execute() method, at line 437, there is > method call: > processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, > artifactSelector ); > This method call appears to populate the "artifacts" and "sourceArtifacts" > sets created earlier in execute() but the code noticeably does not populate > the similar "testArtifacts" set. My guess is that this is causing the > "shade" operation to skip processing any artifacts for the test jar shade > operation (since only the project-level artifact is populated in the > "testArtifacts" set at line 432). > __Possible Solution__ > (Obviously) Add an additional parameter to processArtifactSelectors() that > accepts the additional "testArtifacts" set. Then, processArtifactSelectors > could populate that set (much like it does for the "sourceArtifacts" set at > line 623). A more extensible design might be to populate a list of Set's and > supply that to processArtifactSelectors(), but there are some other > difficulties with that (under the current design). > Best wishes. Like I said, I'm pretty new to this plugin, so the above may be > incorrect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-203) "shadeTestJar" option not working?
[ https://issues.apache.org/jira/browse/MSHADE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-203. > "shadeTestJar" option not working? > -- > > Key: MSHADE-203 > URL: https://issues.apache.org/jira/browse/MSHADE-203 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Aaron Curley >Priority: Minor > > So, I'm pretty new to using the maven-shade-plugin and I'm not really that > familiar with the maven-shade-plugin's design/code; however, it appears that > the option in the maven-shade-plugin configuration does not > work correctly. > __Symtoms__ > While running "mvn package" in my project (which has set to > true), maven-shade-plugin appears to perform the "test jar shading" step > (after performing the regular jar's shade), but the "shaded" test JAR doesn't > actually include any shaded dependency files (it just includes the "original" > test jar's contents, which is essentially a "no-op"). > __Possible Diagnosis__ > I took a quick look at the release code base for v2.4.1, in particularly, the > mojo/ShadeMojo.java file. In the execute() method, at line 437, there is > method call: > processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, > artifactSelector ); > This method call appears to populate the "artifacts" and "sourceArtifacts" > sets created earlier in execute() but the code noticeably does not populate > the similar "testArtifacts" set. My guess is that this is causing the > "shade" operation to skip processing any artifacts for the test jar shade > operation (since only the project-level artifact is populated in the > "testArtifacts" set at line 432). > __Possible Solution__ > (Obviously) Add an additional parameter to processArtifactSelectors() that > accepts the additional "testArtifacts" set. Then, processArtifactSelectors > could populate that set (much like it does for the "sourceArtifacts" set at > line 623). A more extensible design might be to populate a list of Set's and > supply that to processArtifactSelectors(), but there are some other > difficulties with that (under the current design). > Best wishes. Like I said, I'm pretty new to this plugin, so the above may be > incorrect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease
[
https://issues.apache.org/jira/browse/MENFORCER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter De Maeyer updated MENFORCER-477:
--
Description:
I have a snapshot project that has a snapshot parent.
At release time, I want to use the enforcer plugin to make sure the release
version of my project only depends on release versions, including the parent,
so I use {{failWhenParentIsSnapshot=true}}.
For snapshot versions of my project, I want to _allow_ snapshot dependencies
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the
enforcer for snapshot versions.
*Expected:* my snapshot project build succeeds with a snapshot parent.
*Actual:* my snapshot project build _fails_ with a snapshot parent, despite
{{onlyWhenRelease=true}}.
I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}}
into account.
The intuitive fix for me would be that the combination of both options behaves
as expected.
I imagine that maybe it was a design choice to keep both options completely
independent of each other, so an acceptable alternative for me would be to
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves
similar to {{onlyWhenRelease}} but applies to the parent only.
{noformat}
[WARNING]
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen
...\n\t... @13:14) @ /home/peter/.m2/settings.xml, line
13, column 14
[WARNING]
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be
unique but found duplicate declaration of plugin
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT,
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
line 263, column 17
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO] ... total of 5 executions of maven-deploy-plugin replaced with
nexus-staging-maven-plugin
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Supernova Assertions - Parent [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 [jar]
[INFO]
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT [1/5]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent
---
[INFO]
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent
---
[INFO]
[INFO] --- maven-enforcer-plugin:3.2.1:enforce
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO]
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO]
[INFO] Supernova Assertions - Parent .. FAILURE [ 0.464 s]
[INFO] Supernova Assertions - Main SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce
(enforce-no-snapshots-in-releases) on project assertions-parent:
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and pos
[GitHub] [maven-mvnd] gnodet commented on issue #813: mvnd and .mvn
gnodet commented on issue #813: URL: https://github.com/apache/maven-mvnd/issues/813#issuecomment-1500591222 > > Ok, so add `-Dlogback.configurationFile=logback.xml` to `maven.config`? Will that always find `.mvn/logback.xml`? > > This is wrong! What you want is a system property, but `maven.config` is _only_ about Maven user properties. You must use `jvm.config` for this. That's irrelevant. The question is the same with `jvm.config`... Or that mean that there's a need for yet another level of property, which may become a bit too much... -- 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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709768#comment-17709768
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500587863
I think we should make the `rootdir` property available from the _project_
rather than from the _session_. If we want to support über-aggregations, we
should prepare for each project to have a different _rootdir_.
The current `session.rootdir` would only be the `rootdir` for the _top
project_.
Consider the following:
```
a
|- b
| \- c
\- d
\- e
```
where _b_ and _d_ are GitHub repositories and _a_ is a project aggregating
_b_ and _d_. In this case, _c_ rootdir should point to _b_ and _e_ rootdir
should point to _d_. If we don't do this, projects would be build differently
because the rootdir would point to _a_, which could be really bad.
I'm going to add a `getRootdir()` on `Project` and make sure that this one
is used when interpolating projects or injecting mojos. This would not affect
early usage of the `rootdir` property obviously.
The other possibility is to clearly document the limitation and that
projects using `rootdir` may not be properly aggregated (which is the case
currently for projects using the `maven.multiModuleProjectDirectory` or other
mechanisms), but if that could be fixed as well...
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500587863 I think we should make the `rootdir` property available from the _project_ rather than from the _session_. If we want to support über-aggregations, we should prepare for each project to have a different _rootdir_. The current `session.rootdir` would only be the `rootdir` for the _top project_. Consider the following: ``` a |- b | \- c \- d \- e ``` where _b_ and _d_ are GitHub repositories and _a_ is a project aggregating _b_ and _d_. In this case, _c_ rootdir should point to _b_ and _e_ rootdir should point to _d_. If we don't do this, projects would be build differently because the rootdir would point to _a_, which could be really bad. I'm going to add a `getRootdir()` on `Project` and make sure that this one is used when interpolating projects or injecting mojos. This would not affect early usage of the `rootdir` property obviously. The other possibility is to clearly document the limitation and that projects using `rootdir` may not be properly aggregated (which is the case currently for projects using the `maven.multiModuleProjectDirectory` or other mechanisms), but if that could be fixed as well... -- 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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709765#comment-17709765
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160912659
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
Fixed
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160912659
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
Fixed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-mvnd] michael-o commented on issue #813: mvnd and .mvn
michael-o commented on issue #813: URL: https://github.com/apache/maven-mvnd/issues/813#issuecomment-1500568346 > Ok, so add `-Dlogback.configurationFile=logback.xml` to `maven.config`? Will that always find `.mvn/logback.xml`? This is wrong! What you want is a system property, but `maven.config` is *only* about Maven user properties. You must use `jvm.config` for 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
[jira] [Closed] (MSHARED-1205) Integration tests do not run on Java 19
[
https://issues.apache.org/jira/browse/MSHARED-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MSHARED-1205.
Resolution: Fixed
> Integration tests do not run on Java 19
> ---
>
> Key: MSHARED-1205
> URL: https://issues.apache.org/jira/browse/MSHARED-1205
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-dependency-analyzer
>Reporter: Richard Eckart de Castilho
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-dependency-analyzer-next-release
>
>
> The maven-dependency-analyzer integration tests do not pass on Java 19:
> {noformat}
> % mvn -Prun-its clean verify
> ...
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.052 s
> [INFO] Finished at: 2023-03-17T15:52:37+01:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.6.4:descriptor
> (default-descriptor) on project maven-mock-plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.6.4:descriptor failed:
> Unsupported class file major version 63 -> [Help 1]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-dependency-analyzer] slawekjaranowski merged pull request #86: [MSHARED-1205] Build on JDK 19, 20
slawekjaranowski merged PR #86: URL: https://github.com/apache/maven-dependency-analyzer/pull/86 -- 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-dependency-analyzer] slawekjaranowski commented on pull request #86: [MSHARED-1205] Build on JDK 19, 20
slawekjaranowski commented on PR #86: URL: https://github.com/apache/maven-dependency-analyzer/pull/86#issuecomment-1500562079 > Lgtm. > > Maybe we can release shared action V4 with Java 20 as default? This could minimize patching effort and dependabot could do work for us We need a new parent in other way we starting to manage plugins version in many place. This change I recognize as a testing new plugins with new JDKs. -- 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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709762#comment-17709762
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500561296
> > Some of the use cases involve arguments interpolation, so this has to be
done very early in the process.
>
> That are probably just other use-cases that where requested! I just wanted
remind of the original request, that only wanted to make `multiModuleDirectory`
official to be **used inside a pom**, it was never asked to work on commandline
arguments, and at the point where the **model(!)** is read the location is well
known and there are no inconsistency and it is early enough for this use-case.
JIRA seems down for me, but I can point to MNG-5659 or
https://github.com/apache/maven-mvnd/issues/813#issuecomment-1466916434
> > Also, I disagree that this is weird somehow. I think it's actually
mapping quite well with the property isRootProject()
>
> I think you mean
`org.apache.maven.project.MavenProject.isExecutionRoot()`? Beside from Maven
developers I assume no one ever has heard of it and I can't find the term in
the current maven documentation anywhere. Beside that, its currently defined as
the project that is the one where I executed maven.
I was referring to
https://github.com/apache/maven/pull/1061/files#diff-5e32d3e141f6d87a19ff7f26d7ff4f2d427a8d98622e71ef24a1168772d23e13R117
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500561296 > > Some of the use cases involve arguments interpolation, so this has to be done very early in the process. > > That are probably just other use-cases that where requested! I just wanted remind of the original request, that only wanted to make `multiModuleDirectory` official to be **used inside a pom**, it was never asked to work on commandline arguments, and at the point where the **model(!)** is read the location is well known and there are no inconsistency and it is early enough for this use-case. JIRA seems down for me, but I can point to MNG-5659 or https://github.com/apache/maven-mvnd/issues/813#issuecomment-1466916434 > > Also, I disagree that this is weird somehow. I think it's actually mapping quite well with the property isRootProject() > > I think you mean `org.apache.maven.project.MavenProject.isExecutionRoot()`? Beside from Maven developers I assume no one ever has heard of it and I can't find the term in the current maven documentation anywhere. Beside that, its currently defined as the project that is the one where I executed maven. I was referring to https://github.com/apache/maven/pull/1061/files#diff-5e32d3e141f6d87a19ff7f26d7ff4f2d427a8d98622e71ef24a1168772d23e13R117 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] jglick opened a new issue, #836: `Could not acquire write lock for…` errors
jglick opened a new issue, #836:
URL: https://github.com/apache/maven-mvnd/issues/836
I just upgraded mvnd to 1.0-m6-m39 via Snap from 0.9.0 (using Java 11) and
ran a build of my reactor with 27 modules as usual (max parallelism 11). It
spat out some errors such as
```
Could not acquire write lock for
'~/.m2/repository/.locks/com.github.spotbugs~spotbugs-annotations~4.7.3.lock'
Could not acquire write lock for
'~/.m2/repository/.locks/commons-collections~commons-collections~3.2.2.lock'
```
and the build failed partway through
```
Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0:enforce
(enforce-bytecode-version) on project …: Execution enforce-bytecode-version of
goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0:enforce failed: Could
not acquire write lock for
'~/.m2/repository/.locks/groupId~artifactId~1.234.lock' -> [Help 1]
Failed to execute goal some:plugin:1.2:some-mojo (default-some-mojo) on
project …: Execution default-some-mojo of goal some:plugin:1.2:some-mojo
failed: Could not acquire write lock for
'~/.m2/repository/.locks/groupId2~artifactId2~5.678.lock' -> [Help 1]
Could not acquire write lock for
'~/.m2/repository/.locks/groupId3~artifactId3~9.012.lock'
```
When I ran the build again, it passes, so I presume this was some sort of
race condition, possibly involving artifact downloads (I had pulled in various
POM updates since the last local build of the project).
No further details were provided, and I was not using `-e` so there was no
stack trace giving context. I checked `~/.m2/mvnd/registry/1.0-m6/daemon-*.log`
which did not really add any more information:
```
Dispatch message: ExecutionFailure{projectId='…', halted=true,
exception='java.lang.IllegalStateException: Could not acquire write lock for
'~/.m2/repository/.locks/com.github.spotbugs~spotbugs-annotations~4.7.3.lock''}
```
If nothing else, the `Throwable.toString` of the cause ought to be included
in the top-level error message I think.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709744#comment-17709744
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500462903
> I do not feel very comfortable to add runtime information into a static
model. This does not feel right. Maybe we should just require `.mvn` to be
present now, period?
Strictly speaking it is as runtime as the gav of the pom so this part is
fine IMHO.
Current proposal looks good and avoids the pitfall `.mvn` presence will
imply so looks good to me.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
rmannibucau commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500462903 > I do not feel very comfortable to add runtime information into a static model. This does not feel right. Maybe we should just require `.mvn` to be present now, period? Strictly speaking it is as runtime as the gav of the pom so this part is fine IMHO. Current proposal looks good and avoids the pitfall `.mvn` presence will imply so looks good to me. -- 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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709738#comment-17709738
]
ASF GitHub Bot commented on MNG-7038:
-
laeubi commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500441953
> Some of the use cases involve arguments interpolation, so this has to be
done very early in the process.
That are probably just other use-cases that where requested! I just wanted
remind of the original request, that only wanted to make `multiModuleDirectory`
official to be **used inside a pom**, it was never asked to work on commandline
arguments, and at the point where the **model(!)** is read the location is well
known and there are no inconsistency and it is early enough for this use-case.
> Also, I disagree that this is weird somehow. I think it's actually mapping
quite well with the property isRootProject()
I think you mean `org.apache.maven.project.MavenProject.isExecutionRoot()`?
Beside from Maven developers I assume no one ever has heard of it and I can't
find the term in the current maven documentation anywhere. Beside that, its
currently defined as the project that is the one where I executed maven.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] laeubi commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
laeubi commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500441953 > Some of the use cases involve arguments interpolation, so this has to be done very early in the process. That are probably just other use-cases that where requested! I just wanted remind of the original request, that only wanted to make `multiModuleDirectory` official to be **used inside a pom**, it was never asked to work on commandline arguments, and at the point where the **model(!)** is read the location is well known and there are no inconsistency and it is early enough for this use-case. > Also, I disagree that this is weird somehow. I think it's actually mapping quite well with the property isRootProject() I think you mean `org.apache.maven.project.MavenProject.isExecutionRoot()`? Beside from Maven developers I assume no one ever has heard of it and I can't find the term in the current maven documentation anywhere. Beside that, its currently defined as the project that is the one where I executed maven. -- 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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709734#comment-17709734
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500435764
> > > I do not feel very comfortable to add runtime information into a
static model. This does not feel right. Maybe we should just require `.mvn` to
be present now, period?
> >
> >
> > I'll let you discuss with @rmannibucau about that, because that's
precisely the very point he disagree with...
>
> My feeling is that hes the only one disagreeing here, so maybe we can not
make everyone happy ;-) Beside that i find "root" confusing if it is only used
to define a path but has no other meaning.
>
> Also as an excerpt from the discussion, I think that almost all use-cases
would better to have a property that has the full path of the current **pom.xml
file** (!).
>
> So lets say I have a parent `pom.xml` and I use the property
`${this.location}` it should always resolve to the path of the parent pom even
if used in a child at any level. Thats simple and can be used independent of
the project structure.
Some of the use cases involve arguments interpolation, so this has to be
done _very early_ in the process.
Also, I disagree that this is _weird_ somehow. I think it's actually
mapping quite well with the property `isRootProject()` which has already been
added to the `Project`, and actually nicely reflects the correct semantic and
what we're looking for.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500435764
> > > I do not feel very comfortable to add runtime information into a
static model. This does not feel right. Maybe we should just require `.mvn` to
be present now, period?
> >
> >
> > I'll let you discuss with @rmannibucau about that, because that's
precisely the very point he disagree with...
>
> My feeling is that hes the only one disagreeing here, so maybe we can not
make everyone happy ;-) Beside that i find "root" confusing if it is only used
to define a path but has no other meaning.
>
> Also as an excerpt from the discussion, I think that almost all use-cases
would better to have a property that has the full path of the current **pom.xml
file** (!).
>
> So lets say I have a parent `pom.xml` and I use the property
`${this.location}` it should always resolve to the path of the parent pom even
if used in a child at any level. Thats simple and can be used independent of
the project structure.
Some of the use cases involve arguments interpolation, so this has to be
done _very early_ in the process.
Also, I disagree that this is _weird_ somehow. I think it's actually
mapping quite well with the property `isRootProject()` which has already been
added to the `Project`, and actually nicely reflects the correct semantic and
what we're looking for.
--
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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709730#comment-17709730
]
ASF GitHub Bot commented on MNG-7038:
-
laeubi commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500421719
> > I do not feel very comfortable to add runtime information into a static
model. This does not feel right. Maybe we should just require `.mvn` to be
present now, period?
>
> I'll let you discuss with @rmannibucau about that, because that's
precisely the very point he disagree with...
My feeling is that hes the only one disagreeing here, so maybe we can not
make everyone happy ;-)
Beside that i find "root" confusing if it is only used to define a path but
has no other meaning.
Also as an excerpt from the discussion, I think that almost all use-cases
would better to have a property that has the full path of the current **pom.xml
file** (!).
So lets say I have a parent `pom.xml` and I use the property
`${this.location}` it should always resolve to the path of the parent pom even
if used in a child at any level. Thats simple and can be used independent of
the project structure.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] laeubi commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
laeubi commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500421719
> > I do not feel very comfortable to add runtime information into a static
model. This does not feel right. Maybe we should just require `.mvn` to be
present now, period?
>
> I'll let you discuss with @rmannibucau about that, because that's
precisely the very point he disagree with...
My feeling is that hes the only one disagreeing here, so maybe we can not
make everyone happy ;-)
Beside that i find "root" confusing if it is only used to define a path but
has no other meaning.
Also as an excerpt from the discussion, I think that almost all use-cases
would better to have a property that has the full path of the current **pom.xml
file** (!).
So lets say I have a parent `pom.xml` and I use the property
`${this.location}` it should always resolve to the path of the parent pom even
if used in a child at any level. Thats simple and can be used independent of
the project structure.
--
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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709728#comment-17709728
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160802840
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
The documentation is already present in Javadoc. We don't declare REs
anywhere, but Javadoc. It should be consistent throughout.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160802840
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
The documentation is already present in Javadoc. We don't declare REs
anywhere, but Javadoc. It should be consistent throughout.
--
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-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709726#comment-17709726
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500413738
> I do not feel very comfortable to add runtime information into a static
model. This does not feel right. Maybe we should just require `.mvn` to be
present now, period?
I'll let you discuss with @rmannibucau about that, because that's precisely
the very point he disagree with...
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500413738 > I do not feel very comfortable to add runtime information into a static model. This does not feel right. Maybe we should just require `.mvn` to be present now, period? I'll let you discuss with @rmannibucau about that, because that's precisely the very point he disagree 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
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709725#comment-17709725
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160797325
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
It's not mandatory, but definitely not redundant. That's documentation ;-)
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160797325
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
It's not mandatory, but definitely not redundant. That's documentation ;-)
--
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] (MPOM-394) Upgrade Maven Project Info Reports Plugin to 3.4.3
[ https://issues.apache.org/jira/browse/MPOM-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709720#comment-17709720 ] Slawomir Jaranowski commented on MPOM-394: -- 3.4.3 is not released yet > Upgrade Maven Project Info Reports Plugin to 3.4.3 > -- > > Key: MPOM-394 > URL: https://issues.apache.org/jira/browse/MPOM-394 > Project: Maven POMs > Issue Type: Task > Components: asf >Affects Versions: ASF-29 >Reporter: Herve Boutemy >Priority: Major > Fix For: ASF-30 > > > to benefit from MPIR-429 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-site] evantill commented on pull request #408: Fix anchors in guides/getting-started/index.htm
evantill commented on PR #408: URL: https://github.com/apache/maven-site/pull/408#issuecomment-1500395389 I have manually tested the links using the `mvn site:run` command. > Note: The spaces changed are a side effect of my script. -- 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] (MPOM-411) Bump maven-install-plugin from 3.1.0 to 3.1.1
Slawomir Jaranowski created MPOM-411: Summary: Bump maven-install-plugin from 3.1.0 to 3.1.1 Key: MPOM-411 URL: https://issues.apache.org/jira/browse/MPOM-411 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709714#comment-17709714
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160779967
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
That's a runtime exception and redundant in the signature.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1160779967
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,51 @@ public interface MavenExecutionRequest {
/**
* @since 3.3.0
+ * @deprecated use {@link #setRootdir(Path)} instead
*/
+@Deprecated
void setMultiModuleProjectDirectory(File file);
/**
* @since 3.3.0
+ * @deprecated use {@link #getRootdir()} instead
*/
+@Deprecated
File getMultiModuleProjectDirectory();
+/**
+ * Sets the root dir of the project.
+ *
+ * @since 4.0.0
+ */
+MavenExecutionRequest setRootdir(Path rootdir);
+
+/**
+ * Gets the root directory of the project, which is the parent directory
containing the {@code .mvn} directory
+ * or a {@code pom.xml} file with the {@code root="true"} attribute.
+ * If there's no such file, an {@code IllegalStateException} will be
thrown.
+ *
+ * @throws IllegalStateException if the root directory could not be found
+ * @since 4.0.0
+ */
+Path getRootdir() throws IllegalStateException;
Review Comment:
That's a runtime exception and redundant in the signature.
--
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-apache-parent] dependabot[bot] opened a new pull request, #144: Bump maven-install-plugin from 3.1.0 to 3.1.1
dependabot[bot] opened a new pull request, #144: URL: https://github.com/apache/maven-apache-parent/pull/144 Bumps [maven-install-plugin](https://github.com/apache/maven-install-plugin) from 3.1.0 to 3.1.1. Release notes Sourced from https://github.com/apache/maven-install-plugin/releases";>maven-install-plugin's releases. 3.1.1 What's Changed [MINSTALL-186] Use proper repositorySystemSession by https://github.com/rbioteau";>@rbioteau in https://redirect.github.com/apache/maven-install-plugin/pull/49";>apache/maven-install-plugin#49 [MINSTALL-188] Upgrade Parent to 39 by https://github.com/slawekjaranowski";>@slawekjaranowski in https://redirect.github.com/apache/maven-install-plugin/pull/53";>apache/maven-install-plugin#53 [MINSTALL-189] Add parameter to lax project validation by https://github.com/cstamas";>@cstamas in https://redirect.github.com/apache/maven-install-plugin/pull/57";>apache/maven-install-plugin#57 New Contributors https://github.com/rbioteau";>@rbioteau made their first contribution in https://redirect.github.com/apache/maven-install-plugin/pull/49";>apache/maven-install-plugin#49 Full Changelog: https://github.com/apache/maven-install-plugin/compare/maven-install-plugin-3.1.0...maven-install-plugin-3.1.1";>https://github.com/apache/maven-install-plugin/compare/maven-install-plugin-3.1.0...maven-install-plugin-3.1.1 Commits https://github.com/apache/maven-install-plugin/commit/2a366ed910b119360c49330d533c2b00972e034e";>2a366ed [maven-release-plugin] prepare release maven-install-plugin-3.1.1 https://github.com/apache/maven-install-plugin/commit/0d0df3560139841641da3ec6823730f797bd1862";>0d0df35 [MINSTALL-189] Add parameter to lax project validation (https://redirect.github.com/apache/maven-install-plugin/issues/57";>#57) https://github.com/apache/maven-install-plugin/commit/ba4cdf27f42ac9c1fa8cba60ec2ee812934d9547";>ba4cdf2 [MINSTALL-188] Upgrade Parent to 39 - code reformat https://github.com/apache/maven-install-plugin/commit/1f9c6df7f8f3e962c65cf4434faf86ade8820640";>1f9c6df [MINSTALL-188] Upgrade Parent to 39 https://github.com/apache/maven-install-plugin/commit/508a3cd11402ebd3f009828d9110f1010bc5e2f2";>508a3cd Disable merge button and add jira autolink https://github.com/apache/maven-install-plugin/commit/4cbbc08d5114539f81519db392ad1b4e401e394c";>4cbbc08 [MINSTALL-186] Use proper repositorySystemSession https://github.com/apache/maven-install-plugin/commit/bb5360974ceedce3cc05d94c3e0b01525b60f696";>bb53609 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-install-plugin/compare/maven-install-plugin-3.1.0...maven-install-plugin-3.1.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infras
[jira] [Closed] (MPOM-405) Bump maven.plugin.tools.version from 3.7.0 to 3.8.1
[ https://issues.apache.org/jira/browse/MPOM-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-405. Resolution: Fixed > Bump maven.plugin.tools.version from 3.7.0 to 3.8.1 > --- > > Key: MPOM-405 > URL: https://issues.apache.org/jira/browse/MPOM-405 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #132: [MPOM-405] Bump maven.plugin.tools.version from 3.7.0 to 3.8.1
slawekjaranowski merged PR #132: URL: https://github.com/apache/maven-apache-parent/pull/132 -- 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-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709711#comment-17709711
]
Michael Osipov commented on MNG-6825:
-
[~cstamas], I think this can and should be ported to 3.9.x.
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-6, 4.0.0
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6825:
Fix Version/s: 3.9.x-candidate
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 3.9.x-candidate, 4.0.0-alpha-6, 4.0.0
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7423) Remove Dependency to org.apache.commons:commons-lang3
[ https://issues.apache.org/jira/browse/MNG-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7423. --- Fix Version/s: (was: 4.0.x-candidate) Resolution: Duplicate > Remove Dependency to org.apache.commons:commons-lang3 > - > > Key: MNG-7423 > URL: https://issues.apache.org/jira/browse/MNG-7423 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Karl Heinz Marbaise >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-6825) Cleaning Up dependencies plexus-utils/maven-shared-utils/commons-lang3/commons-io
[
https://issues.apache.org/jira/browse/MNG-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6825:
Fix Version/s: 4.0.0
> Cleaning Up dependencies
> plexus-utils/maven-shared-utils/commons-lang3/commons-io
> -
>
> Key: MNG-6825
> URL: https://issues.apache.org/jira/browse/MNG-6825
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0-alpha-6, 4.0.0
>
>
> Experiment to see if we can get rid of commons-lang3 dependency.
> * Identified code duplication between:
> ** {{org.apache.commons.lang3.StringUtils}} from {{commons-lang3}} (501879
> Bytes commons-lang3-3.8.1.jar)
> ** {{org.codehaus.plexus.util.StringUtil}} from {{plexus-utils}} (261801
> Bytes plexus-utils-3.2.1.jar)
> ** {{org.apache.maven.shared.utils}} from {{maven-shared-utils}} (166562
> Bytes maven-shared-utils-3.2.1.jar)
> ** We should replace the self implemented with
> {{org.codehaus.plexus.util.StringUtil}}. or with {{maven-shared-utils}}
> * {{commons-io}} usage by {{maven-shared-utils}} (208700 Bytes
> commons-io-2.5.jar)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPOM-410) Bump maven-resources-plugin from 3.3.0 to 3.3.1
Slawomir Jaranowski created MPOM-410: Summary: Bump maven-resources-plugin from 3.3.0 to 3.3.1 Key: MPOM-410 URL: https://issues.apache.org/jira/browse/MPOM-410 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7561) DefaultVersionRangeResolver should not try to resolve versions with same upper and lower bound
[
https://issues.apache.org/jira/browse/MNG-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7561:
Fix Version/s: 3.8.9
(was: 3.8.x-candidate)
> DefaultVersionRangeResolver should not try to resolve versions with same
> upper and lower bound
> --
>
> Key: MNG-7561
> URL: https://issues.apache.org/jira/browse/MNG-7561
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-3, 4.0.0, 3.8.9
>
>
> For dependencies having e.g. version {{[1.0]}} the
> DefaultVersionRangeResolver still tries to resolve versions although only a
> single version (namely 1.0) is valid here according to
> https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification.
>
> This leads in the worst case to long-running calls against a remote
> repository for no reason.
> There should be a shortcut in
> https://github.com/apache/maven/blob/3f90e7028e0338c110aea267b44362653d55273a/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L108
> when the range has the same upper and lower bound.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSKINS-225) Upgrade to Doxia Sitetools 2.0.0-M7
[ https://issues.apache.org/jira/browse/MSKINS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-225: -- Description: This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M7 was: This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M6 > Upgrade to Doxia Sitetools 2.0.0-M7 > --- > > Key: MSKINS-225 > URL: https://issues.apache.org/jira/browse/MSKINS-225 > Project: Maven Skins > Issue Type: Dependency upgrade > Components: Fluido Skin >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-2.0.0-M6 > > > This will also include the upgrade in ITs: > * Maven Site Plugin 4.0.0-M7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSKINS-225) Upgrade to Doxia Sitetools 2.0.0-M7
Michael Osipov created MSKINS-225: - Summary: Upgrade to Doxia Sitetools 2.0.0-M7 Key: MSKINS-225 URL: https://issues.apache.org/jira/browse/MSKINS-225 Project: Maven Skins Issue Type: Dependency upgrade Components: Fluido Skin Reporter: Michael Osipov Assignee: Michael Osipov Fix For: fluido-2.0.0-M5 This will also include the upgrade in ITs: * Maven Site Plugin 4.0.0-M6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSKINS-225) Upgrade to Doxia Sitetools 2.0.0-M7
[ https://issues.apache.org/jira/browse/MSKINS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSKINS-225: -- Fix Version/s: fluido-2.0.0-M6 (was: fluido-2.0.0-M5) > Upgrade to Doxia Sitetools 2.0.0-M7 > --- > > Key: MSKINS-225 > URL: https://issues.apache.org/jira/browse/MSKINS-225 > Project: Maven Skins > Issue Type: Dependency upgrade > Components: Fluido Skin >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: fluido-2.0.0-M6 > > > This will also include the upgrade in ITs: > * Maven Site Plugin 4.0.0-M6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-409) Bump apache-source-release-assembly-descriptor from 1.0.6 to 1.5
Slawomir Jaranowski created MPOM-409: Summary: Bump apache-source-release-assembly-descriptor from 1.0.6 to 1.5 Key: MPOM-409 URL: https://issues.apache.org/jira/browse/MPOM-409 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-408) Bump maven-scm-publish-plugin from 3.1.0 to 3.2.1
Slawomir Jaranowski created MPOM-408: Summary: Bump maven-scm-publish-plugin from 3.1.0 to 3.2.1 Key: MPOM-408 URL: https://issues.apache.org/jira/browse/MPOM-408 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-407) Bump maven-release-plugin from 3.0.0-M7 to 3.0.0
Slawomir Jaranowski created MPOM-407: Summary: Bump maven-release-plugin from 3.0.0-M7 to 3.0.0 Key: MPOM-407 URL: https://issues.apache.org/jira/browse/MPOM-407 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-406) Bump surefire/failsafe version from 2.22.2 to 3.0.0
Slawomir Jaranowski created MPOM-406: Summary: Bump surefire/failsafe version from 2.22.2 to 3.0.0 Key: MPOM-406 URL: https://issues.apache.org/jira/browse/MPOM-406 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-405) Bump maven.plugin.tools.version from 3.7.0 to 3.8.1
Slawomir Jaranowski created MPOM-405: Summary: Bump maven.plugin.tools.version from 3.7.0 to 3.8.1 Key: MPOM-405 URL: https://issues.apache.org/jira/browse/MPOM-405 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709693#comment-17709693
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1500332743
@michael-o @rmannibucau @cstamas please check the recent addition of the
`root="true"` model attribute as an alternative mechanism to locate the root
directory. Both are conceptually similar and the nearest directory having
either a `.mvn` sub-directory or a `pom.xml` flagged with this attribute will
be used.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1061: [MNG-7038] Introduce public property to point to a root directory of (multi-module) project
gnodet commented on PR #1061: URL: https://github.com/apache/maven/pull/1061#issuecomment-1500332743 @michael-o @rmannibucau @cstamas please check the recent addition of the `root="true"` model attribute as an alternative mechanism to locate the root directory. Both are conceptually similar and the nearest directory having either a `.mvn` sub-directory or a `pom.xml` flagged with this attribute will be used. -- 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] (MPOM-404) Bump maven-scm-plugin from 1.13.0 to 2.0.0
[ https://issues.apache.org/jira/browse/MPOM-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-404. Resolution: Fixed > Bump maven-scm-plugin from 1.13.0 to 2.0.0 > -- > > Key: MPOM-404 > URL: https://issues.apache.org/jira/browse/MPOM-404 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #136: [MPOM-404] Bump maven-scm-plugin from 1.13.0 to 2.0.0
slawekjaranowski merged PR #136: URL: https://github.com/apache/maven-apache-parent/pull/136 -- 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] (MRESOLVER-351) Thread count as core multiplied
[
https://issues.apache.org/jira/browse/MRESOLVER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MRESOLVER-351.
-
Resolution: Won't Fix
the "dynamic core count" should be calculated on some higher level (app
integrating resolver), not in resolver.
> Thread count as core multiplied
> ---
>
> Key: MRESOLVER-351
> URL: https://issues.apache.org/jira/browse/MRESOLVER-351
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Syntax as {{1.5C}} for thread count parameters
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-351) Thread count as core multiplied
[
https://issues.apache.org/jira/browse/MRESOLVER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709686#comment-17709686
]
ASF GitHub Bot commented on MRESOLVER-351:
--
slawekjaranowski closed pull request #278: [MRESOLVER-351] Thread count as core
multiplied
URL: https://github.com/apache/maven-resolver/pull/278
> Thread count as core multiplied
> ---
>
> Key: MRESOLVER-351
> URL: https://issues.apache.org/jira/browse/MRESOLVER-351
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Syntax as {{1.5C}} for thread count parameters
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] slawekjaranowski closed pull request #278: [MRESOLVER-351] Thread count as core multiplied
slawekjaranowski closed pull request #278: [MRESOLVER-351] Thread count as core multiplied URL: https://github.com/apache/maven-resolver/pull/278 -- 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-7007) Remove documented backward compatibility
[
https://issues.apache.org/jira/browse/MNG-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709668#comment-17709668
]
Michael Osipov commented on MNG-7007:
-
[~gnodet], WDYT?
> Remove documented backward compatibility
>
>
> Key: MNG-7007
> URL: https://issues.apache.org/jira/browse/MNG-7007
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Priority: Major
>
> These spots document backward compatibility:
> {noformat}
> ./maven-core/src/main/java/org/apache/maven/execution/MavenSession.java:
> // Backward compat
> ./maven-core/src/main/java/org/apache/maven/plugin/DefaultBuildPluginManager.java:
> // This is necessary to avoid creating compatibility problems for
> existing plugins that use
> ./maven-core/src/main/java/org/apache/maven/plugin/LegacySupport.java: *
> Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultLegacySupport.java:
> * Helps to provide backward-compatibility with plugins that use legacy
> components. Warning: This is an
> ./maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuildingHelper.java:
> * This is purely for backward-compat with 2.x where
> consisting of a single artifact where
> ./maven-core/src/main/java/org/apache/maven/project/DuplicateArtifactAttachmentException.java:
> * Currently, this modification would create compatibility problems for
> existing plugins.
> ./maven-core/src/main/java/org/apache/maven/project/MavenProject.java: *
> @throws DuplicateArtifactAttachmentException will never happen but leave it
> for backward compatibility
> ./maven-core/src/main/java/org/apache/maven/project/artifact/DefaultMetadataSource.java:
> * This realizes the metadata source via the default hint to provide
> backward-compat with Maven 2.x whose Plexus version
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * Provides backwards compatibility with Maven 3.2.3 and earlier. Clients
> that do not require compatibility with Maven
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/DefaultJavaToolChain.java:
> * @deprecated clients that do not require compatibility with Maven 3.2.3 and
> earlier should link to
> ./maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainFactory.java:
> // use DefaultJavaToolChain for compatibility with maven 3.2.3 and
> earlier
> ./maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java:
> * Denotes validation as performed by Maven 2.0. This validation level is
> meant as a compatibility mode to allow
> ./maven-model-builder/src/main/java/org/apache/maven/model/inheritance/DefaultInheritanceAssembler.java:
> * sake of backward-compat with 2.x (MNG-5000). In general, it is
> wrong to
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * NOTE: This is primarily to keep backward-compat with Maven 2.x
> which did not validate that dependencies are
> ./maven-model-builder/src/main/java/org/apache/maven/model/normalization/DefaultModelNormalizer.java:
> * the first occurrence. So when we're in lenient/compat mode, we
> have to deal with such broken POMs and mimic
> ./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
> * order to don't break backward-compat with those, only
> warn but don't error out.
> ./maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java:
> // note this will not be hit for Maven 1.x project.xml as it is
> an incompatible schema
> {noformat}
> They need to be reviewed one by one and removed if possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSKINS-216) Fix issue with missing dependency to plexus-utils in minify-maven-plugin and Maven 3.9.x
[
https://issues.apache.org/jira/browse/MSKINS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSKINS-216.
-
Resolution: Fixed
Fixed with
[35d7020a5b56dd3ec11d42694e12c115f0734144|https://gitbox.apache.org/repos/asf?p=maven-fluido-skin.git;a=commit;h=35d7020a5b56dd3ec11d42694e12c115f0734144].
> Fix issue with missing dependency to plexus-utils in minify-maven-plugin and
> Maven 3.9.x
>
>
> Key: MSKINS-216
> URL: https://issues.apache.org/jira/browse/MSKINS-216
> Project: Maven Skins
> Issue Type: Dependency upgrade
> Components: Fluido Skin
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: fluido-2.0.0-M6
>
>
> {noformat}[ERROR] Failed to execute goal
> com.samaxes.maven:minify-maven-plugin:1.7.6:minify (default-minify) on
> project maven-fluido-skin: java.lang.NoClassDefFoundError:
> org/codehaus/plexus/util/IOUtil: org.codehaus.plexus.util.IOUtil -> [Help
> 1]{noformat}
> with Maven 3.9.x. Fix for upstream
> https://github.com/samaxes/minify-maven-plugin/pull/176
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-351) Thread count as core multiplied
[
https://issues.apache.org/jira/browse/MRESOLVER-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709666#comment-17709666
]
ASF GitHub Bot commented on MRESOLVER-351:
--
cstamas commented on PR #278:
URL: https://github.com/apache/maven-resolver/pull/278#issuecomment-1500244719
https://github.com/apache/maven-resolver/pull/239#issuecomment-1420576532
> Thread count as core multiplied
> ---
>
> Key: MRESOLVER-351
> URL: https://issues.apache.org/jira/browse/MRESOLVER-351
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Syntax as {{1.5C}} for thread count parameters
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-fluido-skin] asfgit closed pull request #49: [MSKINS-216] Add missing dependency to plexus-utils used in minify-maven-plugin
asfgit closed pull request #49: [MSKINS-216] Add missing dependency to plexus-utils used in minify-maven-plugin URL: https://github.com/apache/maven-fluido-skin/pull/49 -- 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-resolver] cstamas commented on pull request #278: [MRESOLVER-351] Thread count as core multiplied
cstamas commented on PR #278: URL: https://github.com/apache/maven-resolver/pull/278#issuecomment-1500244719 https://github.com/apache/maven-resolver/pull/239#issuecomment-1420576532 -- 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] (MPMD-367) Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in MPMD-270-325-JDK11
[
https://issues.apache.org/jira/browse/MPMD-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709657#comment-17709657
]
Elliotte Rusty Harold commented on MPMD-367:
This issue has been worked around, but I'm still curious how this happened in
the first place.
> Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in
> MPMD-270-325-JDK11
>
>
> Key: MPMD-367
> URL: https://issues.apache.org/jira/browse/MPMD-367
> Project: Maven PMD Plugin
> Issue Type: Task
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Problem seems to be that this test produces a WARNING on this platform (and
> only this platform?) that fails the build
> {noformat}
> 317 kB at 5.4 MB/s)
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/classes
> [INFO]
> [INFO] --- resources:3.3.0:testResources (default-testResources) @
> MPMD-270-325-JDK11 ---
> [INFO] skip non existing resourceDirectory
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/src/test/resources
> [INFO]
> [INFO] --- compiler:3.8.0:testCompile (default-testCompile) @
> MPMD-270-325-JDK11 ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- surefire:3.0.0:test (default-test) @ MPMD-270-325-JDK11 ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- jar:3.3.0:jar (default-jar) @ MPMD-270-325-JDK11 ---
> [INFO] Building jar:
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/MPMD-270-325-JDK11-1.0-SNAPSHOT.jar
> [INFO]
> [INFO] >>> pmd:3.21.0-SNAPSHOT:check (default) > :pmd @ MPMD-270-325-JDK11 >>>
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:pmd (pmd) @ MPMD-270-325-JDK11 ---
> [WARNING] Parameter \'localRepository\' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to \'${repositorySystemSession}\' expression and get LRM from it
> instead.
> [INFO] PMD version: 6.55.0
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO]
> [INFO] <<< pmd:3.21.0-SNAPSHOT:check (default) < :pmd @ MPMD-270-325-JDK11 <<<
> [INFO]
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:check (default) @ MPMD-270-325-JDK11 ---
> [INFO] PMD version: 6.55.0
> [INFO] PMD Failure: com.mycompany.app.Foo:26 Rule:UnusedFormalParameter
> Priority:3 Avoid unused constructor parameters such as \'foo\'..
> [INFO]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MPMD-367) Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in MPMD-270-325-JDK11
[
https://issues.apache.org/jira/browse/MPMD-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MPMD-367.
Resolution: Fixed
> Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in
> MPMD-270-325-JDK11
>
>
> Key: MPMD-367
> URL: https://issues.apache.org/jira/browse/MPMD-367
> Project: Maven PMD Plugin
> Issue Type: Task
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Problem seems to be that this test produces a WARNING on this platform (and
> only this platform?) that fails the build
> {noformat}
> 317 kB at 5.4 MB/s)
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/classes
> [INFO]
> [INFO] --- resources:3.3.0:testResources (default-testResources) @
> MPMD-270-325-JDK11 ---
> [INFO] skip non existing resourceDirectory
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/src/test/resources
> [INFO]
> [INFO] --- compiler:3.8.0:testCompile (default-testCompile) @
> MPMD-270-325-JDK11 ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- surefire:3.0.0:test (default-test) @ MPMD-270-325-JDK11 ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- jar:3.3.0:jar (default-jar) @ MPMD-270-325-JDK11 ---
> [INFO] Building jar:
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/MPMD-270-325-JDK11-1.0-SNAPSHOT.jar
> [INFO]
> [INFO] >>> pmd:3.21.0-SNAPSHOT:check (default) > :pmd @ MPMD-270-325-JDK11 >>>
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:pmd (pmd) @ MPMD-270-325-JDK11 ---
> [WARNING] Parameter \'localRepository\' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to \'${repositorySystemSession}\' expression and get LRM from it
> instead.
> [INFO] PMD version: 6.55.0
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO]
> [INFO] <<< pmd:3.21.0-SNAPSHOT:check (default) < :pmd @ MPMD-270-325-JDK11 <<<
> [INFO]
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:check (default) @ MPMD-270-325-JDK11 ---
> [INFO] PMD version: 6.55.0
> [INFO] PMD Failure: com.mycompany.app.Foo:26 Rule:UnusedFormalParameter
> Priority:3 Avoid unused constructor parameters such as \'foo\'..
> [INFO]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MPMD-367) Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in MPMD-270-325-JDK11
[
https://issues.apache.org/jira/browse/MPMD-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MPMD-367.
--
> Verify / ubuntu-latest jdk-11-temurin 3.9.1 broken at head in
> MPMD-270-325-JDK11
>
>
> Key: MPMD-367
> URL: https://issues.apache.org/jira/browse/MPMD-367
> Project: Maven PMD Plugin
> Issue Type: Task
>Reporter: Elliotte Rusty Harold
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Problem seems to be that this test produces a WARNING on this platform (and
> only this platform?) that fails the build
> {noformat}
> 317 kB at 5.4 MB/s)
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 2 source files to
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/classes
> [INFO]
> [INFO] --- resources:3.3.0:testResources (default-testResources) @
> MPMD-270-325-JDK11 ---
> [INFO] skip non existing resourceDirectory
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/src/test/resources
> [INFO]
> [INFO] --- compiler:3.8.0:testCompile (default-testCompile) @
> MPMD-270-325-JDK11 ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- surefire:3.0.0:test (default-test) @ MPMD-270-325-JDK11 ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- jar:3.3.0:jar (default-jar) @ MPMD-270-325-JDK11 ---
> [INFO] Building jar:
> /home/runner/work/maven-pmd-plugin/maven-pmd-plugin/target/it/MPMD-270-325-JDK11/target/MPMD-270-325-JDK11-1.0-SNAPSHOT.jar
> [INFO]
> [INFO] >>> pmd:3.21.0-SNAPSHOT:check (default) > :pmd @ MPMD-270-325-JDK11 >>>
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:pmd (pmd) @ MPMD-270-325-JDK11 ---
> [WARNING] Parameter \'localRepository\' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to \'${repositorySystemSession}\' expression and get LRM from it
> instead.
> [INFO] PMD version: 6.55.0
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO]
> [INFO] <<< pmd:3.21.0-SNAPSHOT:check (default) < :pmd @ MPMD-270-325-JDK11 <<<
> [INFO]
> [INFO]
> [INFO] --- pmd:3.21.0-SNAPSHOT:check (default) @ MPMD-270-325-JDK11 ---
> [INFO] PMD version: 6.55.0
> [INFO] PMD Failure: com.mycompany.app.Foo:26 Rule:UnusedFormalParameter
> Priority:3 Avoid unused constructor parameters such as \'foo\'..
> [INFO]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MSITE-944) Site plugin fails if there's a & in the project POM
[
https://issues.apache.org/jira/browse/MSITE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-944.
Fix Version/s: 4.0.0-M7
Resolution: Fixed
> Site plugin fails if there's a & in the project POM
> -
>
> Key: MSITE-944
> URL: https://issues.apache.org/jira/browse/MSITE-944
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
>Reporter: Vincent Massol
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0-M7
>
>
> For example, using:
> {noformat}
>
> http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}&path=
> {noformat}
> Leads to the following when calling "mvn site":
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
> xwiki-commons: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
> project xwiki-commons: SiteToolException: Error parsing site descriptor
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error parsing site descriptor
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:293)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error parsing site
> descriptor
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(DefaultSiteTool.java:1249)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:480)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:286)
> ... 23 more
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseEntityRef(MXParser.java:2219)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseAttribute(MXParser.java:2044)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseStartTag(MXParser.java:1796)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1127)
> at org.codehaus.plexus.ut
[jira] [Commented] (MSITE-944) Site plugin fails if there's a & in the project POM
[
https://issues.apache.org/jira/browse/MSITE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709632#comment-17709632
]
Michael Osipov commented on MSITE-944:
--
I can still reproduce:
{noformat}
[INFO] Finished at: 2023-04-07T11:01:57+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-site) on
project maven-site-plugin: SiteToolException: Error parsing site descriptor:
entity reference name can not contain character =' (position: TEXT seen
...ions.xwiki.org?id=org.apache.maven.plugins:maven-site-plugin&path=...
@28:105) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
D:\Entwicklung\Projekte\maven-site-plugin [(maven-site-plugin-4.0.0-M6) +0 ~2
-0 !]>
{noformat}
> Site plugin fails if there's a & in the project POM
> -
>
> Key: MSITE-944
> URL: https://issues.apache.org/jira/browse/MSITE-944
> Project: Maven Site Plugin
> Issue Type: Bug
>Reporter: Vincent Massol
>Assignee: Michael Osipov
>Priority: Major
>
> For example, using:
> {noformat}
>
> http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}&path=
> {noformat}
> Leads to the following when calling "mvn site":
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
> xwiki-commons: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
> project xwiki-commons: SiteToolException: Error parsing site descriptor
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error parsing site descriptor
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:293)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error parsing site
> descriptor
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(
[jira] [Updated] (MSITE-944) Site plugin fails if there's a & in the project POM
[
https://issues.apache.org/jira/browse/MSITE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSITE-944:
-
Affects Version/s: 4.0.0-M6
3.12.1
> Site plugin fails if there's a & in the project POM
> -
>
> Key: MSITE-944
> URL: https://issues.apache.org/jira/browse/MSITE-944
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
>Reporter: Vincent Massol
>Assignee: Michael Osipov
>Priority: Major
>
> For example, using:
> {noformat}
>
> http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}&path=
> {noformat}
> Leads to the following when calling "mvn site":
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
> xwiki-commons: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
> project xwiki-commons: SiteToolException: Error parsing site descriptor
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error parsing site descriptor
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:293)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error parsing site
> descriptor
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(DefaultSiteTool.java:1249)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:480)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:286)
> ... 23 more
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseEntityRef(MXParser.java:2219)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseAttribute(MXParser.java:2044)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseStartTag(MXParser.java:1796)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1127)
> at org.codehaus.plexus.util.xml.pull.MXParser.ne
[jira] [Moved] (MSITE-944) Site plugin fails if there's a & in the project POM
[
https://issues.apache.org/jira/browse/MSITE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-5242 to MSITE-944:
---
Key: MSITE-944 (was: MNG-5242)
Project: Maven Site Plugin (was: Maven)
> Site plugin fails if there's a & in the project POM
> -
>
> Key: MSITE-944
> URL: https://issues.apache.org/jira/browse/MSITE-944
> Project: Maven Site Plugin
> Issue Type: Bug
>Reporter: Vincent Massol
>Assignee: Michael Osipov
>Priority: Major
>
> For example, using:
> {noformat}
>
> http://extensions.xwiki.org?id=${project.groupId}:${project.artifactId}&path=
> {noformat}
> Leads to the following when calling "mvn site":
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project
> xwiki-commons: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
> project xwiki-commons: SiteToolException: Error parsing site descriptor
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: SiteToolException:
> Error parsing site descriptor
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:293)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.doxia.tools.SiteToolException: Error parsing site
> descriptor
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.readDecorationModel(DefaultSiteTool.java:1249)
> at
> org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:480)
> at
> org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:286)
> ... 23 more
> Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: entity
> reference name can not contain character =' (position: TEXT seen
> ...tp://extensions.xwiki.org?id=org.xwiki.commons:xwiki-commons&path=...
> @27:121)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseEntityRef(MXParser.java:2219)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseAttribute(MXParser.java:2044)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.parseStartTag(MXParser.java:1796)
> at
> org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1127)
> at org.codehaus.plexus.util.xml.pull.MXParse
[jira] [Updated] (MSKINS-224) Ampersand gets un-escaped in menu item
[
https://issues.apache.org/jira/browse/MSKINS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-224:
--
Fix Version/s: fluido-2.0.0-M6
> Ampersand gets un-escaped in menu item
> --
>
> Key: MSKINS-224
> URL: https://issues.apache.org/jira/browse/MSKINS-224
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M5
>Reporter: Lukas Theussl
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: fluido-2.0.0-M6
>
>
> On the Doxia site (trunk) we have a menu item:
> {code:xml}
>
> {code}
> which ends up as
> {code:xml}
>
> Issues & Gotchas
>
> {code}
> ie the ampersand gets un-escaped, making the xhtml invalid.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MSKINS-224) Ampersand gets un-escaped in menu item
[
https://issues.apache.org/jira/browse/MSKINS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MSITE-333 to MSKINS-224:
-
Component/s: Fluido Skin
(was: site descriptor)
Key: MSKINS-224 (was: MSITE-333)
Affects Version/s: fluido-2.0.0-M5
(was: 2.0-beta-7)
Project: Maven Skins (was: Maven Site Plugin)
> Ampersand gets un-escaped in menu item
> --
>
> Key: MSKINS-224
> URL: https://issues.apache.org/jira/browse/MSKINS-224
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M5
>Reporter: Lukas Theussl
>Assignee: Michael Osipov
>Priority: Minor
>
> On the Doxia site (trunk) we have a menu item:
> {code:xml}
>
> {code}
> which ends up as
> {code:xml}
>
> Issues & Gotchas
>
> {code}
> ie the ampersand gets un-escaped, making the xhtml invalid.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
