[GitHub] [maven-site] slachiewicz commented on pull request #402: Bump plantuml from 1.2023.4 to 1.2023.5
slachiewicz commented on PR #402: URL: https://github.com/apache/maven-site/pull/402#issuecomment-1489779359 V1.2023.5 (24 Mar, 2023) [Error in generating State Diagram](https://github.com/plantuml/plantuml/issues/1357) [Bug - Crowfoot notation on ERD rendering buggy](https://github.com/plantuml/plantuml/issues/1353) [Regarding the February update with intermediate namespaces](https://github.com/plantuml/plantuml/issues/1352) [Malformed layout and missing arrows on large amount of edges](https://forum.plantuml.net/17654/malformed-layout-and-missing-arrows-on-large-amount-of-edges) [Smetana and ELK: Improve arrow position and suppress empty space](https://github.com/plantuml/plantuml/issues/1349) [[Class] Note on field is considered unlinked](https://github.com/plantuml/plantuml/issues/1348) [How to change direction of arrow in beta syntax in "Activity Diagram"?](https://github.com/plantuml/plantuml/issues/166) [Rollback new style](https://github.com/plantuml/plantuml/issues/1286) ['help preprocessors' command is not working](https://github.com/plantuml/plantuml/issues/1232) [JSON diagram SVG has misplaced arrows when containing newlines](https://github.com/plantuml/plantuml/issues/1334) [[Smetana] Allow notes (or comments) on lines or links](https://github.com/plantuml/plantuml/issues/1332) [ClassAttributeFont(Style|Size|...) overrides ClassFontStyle(Style|Size|...)](https://github.com/plantuml/plantuml/issues/1335) [The command help themes to list all the themes of PlantUML seems broken](https://github.com/plantuml/plantuml/issues/1331) [Note and position not rendering correctly on CheerpJ](https://forum.plantuml.net/17600/note-and-position-not-rendering-correctly-on-cheerpj) [Ports with similar names](https://github.com/plantuml/plantuml/discussions/1325) [Notes linked to messages in Sequence Diagrams](https://forum.plantuml.net/17587/notes-linked-to-messages-in-sequence-diagrams) [!global $variable ?= "default variable" produces error "a001"](https://forum.plantuml.net/17566/global-%24variable-default-variable-produces-error-a001) [Allow only one underscore when escaping](https://github.com/plantuml/plantuml/pull/1307#issuecomment-1455198456) [Using end if as an alias for endif in Activity diagrams](https://github.com/plantuml/plantuml/discussions/1311) [Drastic Behavior Change of "as" Parsing with "." (period)](https://github.com/plantuml/plantuml/issues/1309#issuecomment-1459021728) [nwdiag bug: group causes element to incorrectly connect to network](https://github.com/plantuml/plantuml/issues/1301) -- 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-site] slachiewicz commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
slachiewicz commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489762593 i've added change to bump to fluido-2.0.0-M5 to easier test and help with release vote -- 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-site] hboutemy commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
hboutemy commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489761388 IIUC, not highlighted is less broken than table :) -- 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] (MRESOLVER-347) Transport http should be able to not reuse or maximize TTL of connections
[
https://issues.apache.org/jira/browse/MRESOLVER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706699#comment-17706699
]
ASF GitHub Bot commented on MRESOLVER-347:
--
ok2c commented on code in PR #274:
URL: https://github.com/apache/maven-resolver/pull/274#discussion_r1152756305
##
maven-resolver-api/src/main/java/org/eclipse/aether/ConfigurationProperties.java:
##
@@ -159,6 +159,37 @@ public final class ConfigurationProperties {
*/
public static final boolean DEFAULT_HTTP_PREEMPTIVE_AUTH = false;
+/**
+ * Should HTTP client reuse connections (in other words, pool connections)
or not?
+ *
+ * @see #DEFAULT_HTTP_REUSE_CONNECTIONS
+ * @since 1.9.8
+ */
+public static final String HTTP_REUSE_CONNECTIONS = PREFIX_CONNECTOR +
"http.reuseConnections";
+
+/**
+ * The default value to use if {@link #HTTP_REUSE_CONNECTIONS} isn't set
(true).
+ *
+ * @since 1.9.8
+ */
+public static final boolean DEFAULT_HTTP_REUSE_CONNECTIONS = true;
+
+/**
+ * The maximum TTL (in milliseconds) HTTP client should apply to
connections when reused.
+ *
+ * @see #DEFAULT_HTTP_CONNECTION_MAX_TTL
+ * @see https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/conn/ConnectionKeepAliveStrategy.html";>ConnectionKeepAliveStrategy
+ * @since 1.9.8
+ */
+public static final String HTTP_CONNECTION_MAX_TTL = PREFIX_CONNECTOR +
"http.connectionMaxTtl";
+
+/**
+ * The default value to use if {@link #HTTP_CONNECTION_MAX_TTL} isn't set
(-1 or "no suggested duration"/forever).
+ *
+ * @since 1.9.8
+ */
+public static final long DEFAULT_HTTP_CONNECTION_MAX_TTL = -1;
Review Comment:
@kwin We cannot be sure what value suits all various use cases. We recommend
that the users choose a finite value based on their specific environment and
application type.
> Transport http should be able to not reuse or maximize TTL of connections
> -
>
> Key: MRESOLVER-347
> URL: https://issues.apache.org/jira/browse/MRESOLVER-347
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.8
>
>
> In some environments (like Azure) the connections should not be reused, or
> TTL adjusted, as Azure is killing them automagically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] ok2c commented on a diff in pull request #274: [MRESOLVER-347] Ability to control conn reuse
ok2c commented on code in PR #274:
URL: https://github.com/apache/maven-resolver/pull/274#discussion_r1152756305
##
maven-resolver-api/src/main/java/org/eclipse/aether/ConfigurationProperties.java:
##
@@ -159,6 +159,37 @@ public final class ConfigurationProperties {
*/
public static final boolean DEFAULT_HTTP_PREEMPTIVE_AUTH = false;
+/**
+ * Should HTTP client reuse connections (in other words, pool connections)
or not?
+ *
+ * @see #DEFAULT_HTTP_REUSE_CONNECTIONS
+ * @since 1.9.8
+ */
+public static final String HTTP_REUSE_CONNECTIONS = PREFIX_CONNECTOR +
"http.reuseConnections";
+
+/**
+ * The default value to use if {@link #HTTP_REUSE_CONNECTIONS} isn't set
(true).
+ *
+ * @since 1.9.8
+ */
+public static final boolean DEFAULT_HTTP_REUSE_CONNECTIONS = true;
+
+/**
+ * The maximum TTL (in milliseconds) HTTP client should apply to
connections when reused.
+ *
+ * @see #DEFAULT_HTTP_CONNECTION_MAX_TTL
+ * @see https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/conn/ConnectionKeepAliveStrategy.html";>ConnectionKeepAliveStrategy
+ * @since 1.9.8
+ */
+public static final String HTTP_CONNECTION_MAX_TTL = PREFIX_CONNECTOR +
"http.connectionMaxTtl";
+
+/**
+ * The default value to use if {@link #HTTP_CONNECTION_MAX_TTL} isn't set
(-1 or "no suggested duration"/forever).
+ *
+ * @since 1.9.8
+ */
+public static final long DEFAULT_HTTP_CONNECTION_MAX_TTL = -1;
Review Comment:
@kwin We cannot be sure what value suits all various use cases. We recommend
that the users choose a finite value based on their specific environment and
application type.
--
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] (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
]
Herve Boutemy updated MSKINS-216:
-
Description:
{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
was:
[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]
with Maven 3.9.x. Fix for upstream
https://github.com/samaxes/minify-maven-plugin/pull/176
> 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-347) Transport http should be able to not reuse or maximize TTL of connections
[
https://issues.apache.org/jira/browse/MRESOLVER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706668#comment-17706668
]
ASF GitHub Bot commented on MRESOLVER-347:
--
kwin commented on code in PR #274:
URL: https://github.com/apache/maven-resolver/pull/274#discussion_r1152684480
##
maven-resolver-api/src/main/java/org/eclipse/aether/ConfigurationProperties.java:
##
@@ -159,6 +159,37 @@ public final class ConfigurationProperties {
*/
public static final boolean DEFAULT_HTTP_PREEMPTIVE_AUTH = false;
+/**
+ * Should HTTP client reuse connections (in other words, pool connections)
or not?
+ *
+ * @see #DEFAULT_HTTP_REUSE_CONNECTIONS
+ * @since 1.9.8
+ */
+public static final String HTTP_REUSE_CONNECTIONS = PREFIX_CONNECTOR +
"http.reuseConnections";
+
+/**
+ * The default value to use if {@link #HTTP_REUSE_CONNECTIONS} isn't set
(true).
+ *
+ * @since 1.9.8
+ */
+public static final boolean DEFAULT_HTTP_REUSE_CONNECTIONS = true;
+
+/**
+ * The maximum TTL (in milliseconds) HTTP client should apply to
connections when reused.
+ *
+ * @see #DEFAULT_HTTP_CONNECTION_MAX_TTL
+ * @see https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/conn/ConnectionKeepAliveStrategy.html";>ConnectionKeepAliveStrategy
+ * @since 1.9.8
+ */
+public static final String HTTP_CONNECTION_MAX_TTL = PREFIX_CONNECTOR +
"http.connectionMaxTtl";
+
+/**
+ * The default value to use if {@link #HTTP_CONNECTION_MAX_TTL} isn't set
(-1 or "no suggested duration"/forever).
+ *
+ * @since 1.9.8
+ */
+public static final long DEFAULT_HTTP_CONNECTION_MAX_TTL = -1;
Review Comment:
If this is the general recommendation why is the default TTL in HttpClient
infinite then?
> Transport http should be able to not reuse or maximize TTL of connections
> -
>
> Key: MRESOLVER-347
> URL: https://issues.apache.org/jira/browse/MRESOLVER-347
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.8
>
>
> In some environments (like Azure) the connections should not be reused, or
> TTL adjusted, as Azure is killing them automagically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] kwin commented on a diff in pull request #274: [MRESOLVER-347] Ability to control conn reuse
kwin commented on code in PR #274:
URL: https://github.com/apache/maven-resolver/pull/274#discussion_r1152684480
##
maven-resolver-api/src/main/java/org/eclipse/aether/ConfigurationProperties.java:
##
@@ -159,6 +159,37 @@ public final class ConfigurationProperties {
*/
public static final boolean DEFAULT_HTTP_PREEMPTIVE_AUTH = false;
+/**
+ * Should HTTP client reuse connections (in other words, pool connections)
or not?
+ *
+ * @see #DEFAULT_HTTP_REUSE_CONNECTIONS
+ * @since 1.9.8
+ */
+public static final String HTTP_REUSE_CONNECTIONS = PREFIX_CONNECTOR +
"http.reuseConnections";
+
+/**
+ * The default value to use if {@link #HTTP_REUSE_CONNECTIONS} isn't set
(true).
+ *
+ * @since 1.9.8
+ */
+public static final boolean DEFAULT_HTTP_REUSE_CONNECTIONS = true;
+
+/**
+ * The maximum TTL (in milliseconds) HTTP client should apply to
connections when reused.
+ *
+ * @see #DEFAULT_HTTP_CONNECTION_MAX_TTL
+ * @see https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/conn/ConnectionKeepAliveStrategy.html";>ConnectionKeepAliveStrategy
+ * @since 1.9.8
+ */
+public static final String HTTP_CONNECTION_MAX_TTL = PREFIX_CONNECTOR +
"http.connectionMaxTtl";
+
+/**
+ * The default value to use if {@link #HTTP_CONNECTION_MAX_TTL} isn't set
(-1 or "no suggested duration"/forever).
+ *
+ * @since 1.9.8
+ */
+public static final long DEFAULT_HTTP_CONNECTION_MAX_TTL = -1;
Review Comment:
If this is the general recommendation why is the default TTL in HttpClient
infinite then?
--
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] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706667#comment-17706667
]
Tomáš Mrázek commented on MBUILDCACHE-45:
-
You have to for some reason explicitly configure target subfolders.
{code:java}
classes
generated-sources
maven-status
{code}
Then those subfolders are correctly zipped and stored and restored in cache.
I am on the other hand unable to restore the jar itself to target folder. Maybe
I just don't get the point of the extension.
Anyways I would expect, that input section would specify files to calculate
hash and defaults to include -> src, and output section would specify actual
files to cache and default to include -> target. Include cannot be specified
for the output tho. And attachedOutputs section is inherently defined for
target. Again I would expect this section to convey cacheable artefacts outside
of the target as some special cases. And I would expect, that all outputs would
be cached/zipped for every phase and then properly restored for the highest
phase run.
Attached outputs are always restored no matter the phase.
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-stage-plugin] elharo commented on pull request #7: [MSTAGE-26] - Fix and un-ignore RepositoryCopierTest
elharo commented on PR #7: URL: https://github.com/apache/maven-stage-plugin/pull/7#issuecomment-1489502511 Looks like a credential problem in the CI unrelated to this PR. Unsure how to fix this: Recording test results [GitHub Checks] Causes for no suitable publisher found: [GitHub Checks] Trying to resolve checks parameters from GitHub SCM... [GitHub Checks] No GitHub app credentials found: '5f95d117-af3b-452a-9e5c-4bddb22a67f4' [GitHub Checks] See: https://github.com/jenkinsci/github-branch-source-plugin/blob/master/docs/github-app.adoc [GitHub Checks] Trying to resolve checks parameters from Git SCM... [GitHub Checks] Job does not use Git SCM [Checks API] No suitable checks publisher found. -- 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-stage-plugin] elharo opened a new pull request, #11: Pullrequest
elharo opened a new pull request, #11: URL: https://github.com/apache/maven-stage-plugin/pull/11 fire ci -- 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] (MDEP-848) Dependency Analysis does not work under Java 20
Mark Derricutt created MDEP-848:
---
Summary: Dependency Analysis does not work under Java 20
Key: MDEP-848
URL: https://issues.apache.org/jira/browse/MDEP-848
Project: Maven Dependency Plugin
Issue Type: Dependency upgrade
Components: analyze
Affects Versions: 3.5.0
Reporter: Mark Derricutt
The analyze-only (and probably other goals) don't support the newer class file
version of Java 20.
{{[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.5.0:analyze-only
(com.smxemail.tiles_com.smxemail.tiles.enforcements_4.0.1-SNAPSHOT__analyze-goals)
on project com.smxemail.datatype: Execution
com.smxemail.tiles_com.smxemail.tiles.enforcements_4.0.1-SNAPSHOT__analyze-goals
of goal org.apache.maven.plugins:maven-dependency-plugin:3.5.0:analyze-only
failed: Unsupported class file major version 64 -> [Help 1]}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MINVOKER-334) incorrect basedir on windows
James Nord created MINVOKER-334:
---
Summary: incorrect basedir on windows
Key: MINVOKER-334
URL: https://issues.apache.org/jira/browse/MINVOKER-334
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 3.5.0
Environment: Apache Maven 3.9.1
(2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: c:\java\maven-3.9.1
Java version: 11.0.15, vendor: Eclipse Adoptium, runtime: c:\java\jdk-11.0.15+10
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
Reporter: James Nord
When run on windows the pluigin munges the value of basedir to something that
is not correct.
in windows the canonical case of a drive letter us upper case, and the file
system can be case sensitive but is nearly always always case preserving (on
NTFS)
the plugin however lower cases the basedir leading to incorrect test results
when run on windows.
jshell showing correct info
{noformat}
jshell> File f = new File(".").getCanonicalFile()
f ==> C:\workarea\source\github\jenkinsci\maven-hpi-plugin
jshell> Path p = f.toPath()
p ==> C:\workarea\source\github\jenkinsci\maven-hpi-plugin
jshell> p.toRealPath()
$3 ==> C:\workarea\source\github\jenkinsci\maven-hpi-plugin
{noformat}
sample output from the invoker plugin
{noformat}
[INFO] --- invoker:3.5.0:install (integration-test) @ maven-hpi-plugin ---
[INFO] Installing
c:\workarea\source\github\jenkinsci\maven-hpi-plugin\target\maven-hpi-plugin-3.42-SNAPSHOT.jar
to
c:\workarea\source\github\jenkinsci\maven-hpi-plugin\target\local-repo\org\jenkins-ci\tools\maven-hpi-plugin\3.42-SNAPSHOT\maven-hpi-plugin-3.42-SNAPSHOT.jar
[INFO] Installing
c:\workarea\source\github\jenkinsci\maven-hpi-plugin\target\maven-hpi-plugin-3.42-SNAPSHOT.pom
to
c:\workarea\source\github\jenkinsci\maven-hpi-plugin\target\local-repo\org\jenkins-ci\tools\maven-hpi-plugin\3.42-SNAPSHOT\maven-hpi-plugin-3.42-SNAPSHOT.pom
{noformat}
this can also be observed in a {{verify.groovy}} script that is expecting a
specific output to be written in a log of a run plugin.
{noformat}
List lines = new File(basedir, 'plugins.txt').readLines('UTF-8')
// invoker plugin is brain dead and sets incorrect path
// like c:\foo\bar when it should be C:\foo\bar
// so we need to canonicalize the basedir
def projectRoot = basedir.getCanonicalPath() + File.separator
assert lines.get(0).contains("$basedir")
{noformat}
which causes a failure like:
{noformat}
[INFO] Assertion failed:
assert lines.get(0).contains("${basedir}")
| | | |
| | false
c:\workarea\source\github\jenkinsci\maven-hpi-plugin\target\its\list-plugins-aggregator
|
'whizzbang\t1.0-SNAPSHOT\tC:\\workarea\\source\\github\\jenkinsci\\maven-hpi-plugin\\target\\its\\list-plugins-aggregator\\a-plugin'
['whizzbang\t1.0-SNAPSHOT\tC:\\workarea\\source\\github\\jenkinsci\\maven-hpi-plugin\\target\\its\\list-plugins-aggregator\\a-plugin',
'list-plugins-plugin1\t1.0-SNAPSHOT\tC:\\workarea\\source\\github\\jenkinsci\\maven-hpi-plugin\\target\\its\\list-plugins-aggregator\\first-module']
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] michael-o commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
michael-o commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489224344 > I simply built a site with this change and tables looks more better. Yes, but the source code blocks are broken, not highlighted. -- 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-site] slawekjaranowski commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
slawekjaranowski commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489193991 I simply built a site with this change and tables looks more better. -- 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-stage-plugin] michaelboyles commented on pull request #7: [MSTAGE-26] - Fix and un-ignore RepositoryCopierTest
michaelboyles commented on PR #7: URL: https://github.com/apache/maven-stage-plugin/pull/7#issuecomment-1489192555 @elharo Done, please review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17706576#comment-17706576
]
Venelin Koulaxazov edited comment on MBUILDCACHE-47 at 3/29/23 7:27 PM:
Wonderful thank you very much once again. I will close this bug as a non issue.
[~maximiln] i don't seem to have permissions for this, feel free to close this
at your convenience.
was (Author: JIRAUSER299290):
Wonderful thank you very much once again. I will close this bug as a non issue.
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=17706576#comment-17706576
]
Venelin Koulaxazov commented on MBUILDCACHE-47:
---
Wonderful thank you very much once again. I will close this bug as a non issue.
> 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] [Commented] (MNG-5659) Project specific settings.xml
[
https://issues.apache.org/jira/browse/MNG-5659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706575#comment-17706575
]
ASF GitHub Bot commented on MNG-5659:
-
rmannibucau commented on PR #1059:
URL: https://github.com/apache/maven/pull/1059#issuecomment-1489173930
Can `${maven.multiModuleProjectDirectory}/.mvn/settings.xml` become
`${maven.multiModuleProjectDirectory}/.mvn/project.settings.xml` or something
like that since `.mvn/settings.xml` is sometimes used by users so something
more unlikely would be great.
> Project specific settings.xml
> -
>
> Key: MNG-5659
> URL: https://issues.apache.org/jira/browse/MNG-5659
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Joachim Van der Auwera
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: mvn.patch
>
>
> It would be useful to have a settings.xml file next to the project pom that
> could contain project specific settings. For example, when switching between
> projects it is sometimes necessary to also change the location of the local
> repository, or use a different set of repositories and/or mirror settings for
> each project.
> If a settings.xml file could be included with a project checkout, then the
> repositories needed for the build could be included (instead of putting them
> in the pom) along with any other project specific settings.
> The tricky part is intelligently handling multi-module projects. For a
> multi-module project I don't want to include a separate settings.xml file for
> each directory. So Maven could recursively check each parent directory until
> it either (1) finds a settings.xml, (2) finds a directory with no pom.xml, or
> (3) finds the root directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #1059: [MNG-5659] Provide project-specific settings located in [root]/.mvn/settings.xml by default
rmannibucau commented on PR #1059:
URL: https://github.com/apache/maven/pull/1059#issuecomment-1489173930
Can `${maven.multiModuleProjectDirectory}/.mvn/settings.xml` become
`${maven.multiModuleProjectDirectory}/.mvn/project.settings.xml` or something
like that since `.mvn/settings.xml` is sometimes used by users so something
more unlikely would be great.
--
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=17706574#comment-17706574
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489172763
> Imho, we need this definition before parsing any project POM , else use
cases such as https://github.com/apache/maven/pull/1059 or
https://github.com/apache/maven/pull/1062 cannot be covered. So I'm not opposed
to a different way of pinning, but not from pom files.
For the second one it is not a technical issue AFAIK.
For first one it looks it is a bit more nasty indeed but
`maven.multiModuleProjectDirectory` seems fully dedicated to this lifecycle
case and looks like having the same issues so if it will somehow assume `.mvn`
is there, I would prefer `.mvn/jvm.config` enabling a minimum interpolation
(`$PWD` or alike) which can be set in `jvm.config` this way user can set all
the system props needed there and avoid the ambiguity to introduce something
magic with a lot of corner cases.
> 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-1489172763 > Imho, we need this definition before parsing any project POM , else use cases such as https://github.com/apache/maven/pull/1059 or https://github.com/apache/maven/pull/1062 cannot be covered. So I'm not opposed to a different way of pinning, but not from pom files. For the second one it is not a technical issue AFAIK. For first one it looks it is a bit more nasty indeed but `maven.multiModuleProjectDirectory` seems fully dedicated to this lifecycle case and looks like having the same issues so if it will somehow assume `.mvn` is there, I would prefer `.mvn/jvm.config` enabling a minimum interpolation (`$PWD` or alike) which can be set in `jvm.config` this way user can set all the system props needed there and avoid the ambiguity to introduce something magic with a lot of corner cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7752) can't download transitive dependencies if there is an expression in the pom
Jim Sellers created MNG-7752:
Summary: can't download transitive dependencies if there is an
expression in the pom
Key: MNG-7752
URL: https://issues.apache.org/jira/browse/MNG-7752
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-5
Environment: Apache Maven 4.0.0-alpha-5
(26d10a4bf9a2df75feef60da01d8706f2bf77a47)
Maven home: /mnt/c/users/sellersj/Downloads/apache-maven-4.0.0-alpha-5
Java version: 17.0.6, vendor: Private Build, runtime:
/usr/lib/jvm/java-17-openjdk-amd64
Default locale: en, platform encoding: UTF-8
OS name: "linux", version: "5.10.16.3-microsoft-standard-wsl2", arch: "amd64",
family: "unix"
Reporter: Jim Sellers
The released pom has {{pom.version}} it in. Works in 3.9.1 and everything 3.x
as far as I can tell.
{code:title=command to run}
mvn -V org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get
-Dartifact=org.apache.tiles:tiles-jsp:2.2.2
{code}
{code:title=log}
[INFO] Scanning for projects...
[INFO]
[INFO] ---<
org.apache.maven:standalone-pom >
[INFO] Building Maven Stub Project (No POM) 1
[INFO] -[ pom
]--
[INFO]
[INFO] --- dependency:3.5.0:get (default-cli) @ standalone-pom ---
[INFO] Resolving org.apache.tiles:tiles-jsp:jar:2.2.2 with transitive
dependencies
[WARNING] The POM for org.apache.tiles:tiles-servlet:jar:${pom.version} is
missing, no dependency information available
[WARNING] The POM for org.apache.tiles:tiles-template:jar:${pom.version} is
missing, no dependency information available
[INFO]
--
[INFO] BUILD FAILURE
[INFO]
--
[INFO] Total time: 10.993 s
[INFO] Finished at: 2023-03-29T15:07:34-04:00
[INFO]
--
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.5.0:get (default-cli) on
project standalone-pom: Couldn't download artifact:
org.eclipse.aether.resolution.DependencyResolutionException: The following
artifacts could not be resolved:
org.apache.tiles:tiles-servlet:jar:${pom.version} (absent),
org.apache.tiles:tiles-template:jar:${pom.version} (absent):
org.apache.tiles:tiles-servlet:jar:${pom.version} was not found in
https://example.com/maven-proxy/content/groups/all-released during a previous
attempt. This failure was cached in the local repository and resolution is not
reattempted until the update interval of asb-repository has elapsed or updates
are forced -> [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 verbose output
[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
{code}
--
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=17706568#comment-17706568
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489148686
> > But the parent/child relationship has to be done later in the process,
so can't be used for early interpolation.
>
> Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today. I'm
not to add new properties, really just to get a single functional rootdir one
(hopefully merged with multi one but if not at least reliable on any maven
compatible projects). My definition enables to use it for checkstyles, headers
etc even without a .mvn (whereas it works in a minority of cases -
statistically - if not done this way). It can also work when using an
aggregator if the pom uses properties to define paths exactly as .mvn case
which does not solve this issue since for a project with `root >
{child1/.mvn>subchild1,child2/.mvn>subchild2}` it will randomly take child1 or
child2 as rootdir.
>
> Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
>
> Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
Imho, we need this definition before parsing any project POM , else use
cases such as https://github.com/apache/maven/pull/1059 or
https://github.com/apache/maven/pull/1062 cannot be covered. So I'm not
opposed to a different way of pinning, but not from pom files.
> 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-1489148686
> > But the parent/child relationship has to be done later in the process,
so can't be used for early interpolation.
>
> Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today. I'm
not to add new properties, really just to get a single functional rootdir one
(hopefully merged with multi one but if not at least reliable on any maven
compatible projects). My definition enables to use it for checkstyles, headers
etc even without a .mvn (whereas it works in a minority of cases -
statistically - if not done this way). It can also work when using an
aggregator if the pom uses properties to define paths exactly as .mvn case
which does not solve this issue since for a project with `root >
{child1/.mvn>subchild1,child2/.mvn>subchild2}` it will randomly take child1 or
child2 as rootdir.
>
> Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
>
> Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
Imho, we need this definition before parsing any project POM , else use
cases such as https://github.com/apache/maven/pull/1059 or
https://github.com/apache/maven/pull/1062 cannot be covered. So I'm not
opposed to a different way of pinning, but not from pom files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17706565#comment-17706565
]
Maximilian Novikov commented on MBUILDCACHE-47:
---
At the moment the build cache extension is most beneficial for multi-module
projects. Within single module the granularity is guaranteed per mojo
execution, eg. if you execute 'compile' and then 'test', what was cached till
'compile' phase is restored and execution continues from the next phase.
> 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-site] michael-o commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
michael-o commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489137504 > We are still on Doxia 2.0.0-M3 ( > > https://github.com/apache/maven-site/blob/4624b5cb3301670c7faac8d838844f0ba35bdfc9/pom.xml#L78 > ) therefore probably not affected by https://issues.apache.org/jira/browse/MSKINS-221, or am I missing something? We are because MSITE 4.0.0-M6 includes Doxia 2.0.0-M6. -- 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] (MSITE-933) mvn site fails when contains &
[
https://issues.apache.org/jira/browse/MSITE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706563#comment-17706563
]
Michael Osipov commented on MSITE-933:
--
Funny, found this in the code:
{code:java}
try {
// FIXME: this does not escape xml entities, see MSITE-226,
PLXCOMP-118
return interpolator.interpolate(siteDescriptorContent);
} catch (InterpolationException e) {
throw new SiteToolException("Cannot interpolate site descriptor",
e);
}
{code}
I will take care of this. Are you able to build and test from SCSM?
> mvn site fails when contains &
> -
>
> Key: MSITE-933
> URL: https://issues.apache.org/jira/browse/MSITE-933
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
> Environment: Ubuntu 22.04.2 LTS
> Apache Maven 3.9.0
> Java version: 17.0.4.1, vendor: Eclipse Adoptium
>Reporter: Heiko
>Assignee: Michael Osipov
>Priority: Major
>
> A project containing an escaped ampersand in the name element fails in mvn
> site.
> Consider a project containing nothing but this pom.xml:
>
> {code:java}
>
> 4.0.0
> experiments
> experiments
> client for A&B services
> 0.0.1-SNAPSHOT
> {code}
> This project builds fine with the standard build cycle, e.g. mvn install.
> However, with mvn site (or explicitly mvn site:4.0.0-M6:site) it throws an
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-cli) on
> project experiments: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character ' (position: START_DOCUMENT seen
> ...//maven.apache.org/xsd/decoration-2.0.0.xsd" name="client for A&B ...
> @2:142) -> [Help 1]
> {code}
> Escaping the ampersand twice helps, but it shouldn't be necessary:
> {code:java}
> client for A&B services {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-site] kwin commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
kwin commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489122877 We are still on Doxia 2.0.0-M3 (https://github.com/apache/maven-site/blob/4624b5cb3301670c7faac8d838844f0ba35bdfc9/pom.xml#L78) therefore probably not affected by https://issues.apache.org/jira/browse/MSKINS-221, or am I missing something? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MSITE-933) mvn site fails when contains &
[
https://issues.apache.org/jira/browse/MSITE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSITE-933:
Assignee: Michael Osipov
> mvn site fails when contains &
> -
>
> Key: MSITE-933
> URL: https://issues.apache.org/jira/browse/MSITE-933
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
> Environment: Ubuntu 22.04.2 LTS
> Apache Maven 3.9.0
> Java version: 17.0.4.1, vendor: Eclipse Adoptium
>Reporter: Heiko
>Assignee: Michael Osipov
>Priority: Major
>
> A project containing an escaped ampersand in the name element fails in mvn
> site.
> Consider a project containing nothing but this pom.xml:
>
> {code:java}
>
> 4.0.0
> experiments
> experiments
> client for A&B services
> 0.0.1-SNAPSHOT
> {code}
> This project builds fine with the standard build cycle, e.g. mvn install.
> However, with mvn site (or explicitly mvn site:4.0.0-M6:site) it throws an
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-cli) on
> project experiments: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character ' (position: START_DOCUMENT seen
> ...//maven.apache.org/xsd/decoration-2.0.0.xsd" name="client for A&B ...
> @2:142) -> [Help 1]
> {code}
> Escaping the ampersand twice helps, but it shouldn't be necessary:
> {code:java}
> client for A&B services {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-933) mvn site fails when contains &
[
https://issues.apache.org/jira/browse/MSITE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706557#comment-17706557
]
Michael Osipov commented on MSITE-933:
--
Your request is totally valid. What needs to happen is to escape all values to
have a valid XML and when values are passed down to template in Velocity code
they need to be escaped as well.
> mvn site fails when contains &
> -
>
> Key: MSITE-933
> URL: https://issues.apache.org/jira/browse/MSITE-933
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
> Environment: Ubuntu 22.04.2 LTS
> Apache Maven 3.9.0
> Java version: 17.0.4.1, vendor: Eclipse Adoptium
>Reporter: Heiko
>Priority: Major
>
> A project containing an escaped ampersand in the name element fails in mvn
> site.
> Consider a project containing nothing but this pom.xml:
>
> {code:java}
>
> 4.0.0
> experiments
> experiments
> client for A&B services
> 0.0.1-SNAPSHOT
> {code}
> This project builds fine with the standard build cycle, e.g. mvn install.
> However, with mvn site (or explicitly mvn site:4.0.0-M6:site) it throws an
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-cli) on
> project experiments: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character ' (position: START_DOCUMENT seen
> ...//maven.apache.org/xsd/decoration-2.0.0.xsd" name="client for A&B ...
> @2:142) -> [Help 1]
> {code}
> Escaping the ampersand twice helps, but it shouldn't be necessary:
> {code:java}
> client for A&B services {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-933) mvn site fails when contains &
[
https://issues.apache.org/jira/browse/MSITE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706556#comment-17706556
]
Michael Osipov commented on MSITE-933:
--
Well, yes I can confirm that the entire interpolation is not XML-safe because
it is performed with strings.
> mvn site fails when contains &
> -
>
> Key: MSITE-933
> URL: https://issues.apache.org/jira/browse/MSITE-933
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.12.1, 4.0.0-M6
> Environment: Ubuntu 22.04.2 LTS
> Apache Maven 3.9.0
> Java version: 17.0.4.1, vendor: Eclipse Adoptium
>Reporter: Heiko
>Priority: Major
>
> A project containing an escaped ampersand in the name element fails in mvn
> site.
> Consider a project containing nothing but this pom.xml:
>
> {code:java}
>
> 4.0.0
> experiments
> experiments
> client for A&B services
> 0.0.1-SNAPSHOT
> {code}
> This project builds fine with the standard build cycle, e.g. mvn install.
> However, with mvn site (or explicitly mvn site:4.0.0-M6:site) it throws an
> error:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-cli) on
> project experiments: SiteToolException: Error parsing site descriptor: entity
> reference name can not contain character ' (position: START_DOCUMENT seen
> ...//maven.apache.org/xsd/decoration-2.0.0.xsd" name="client for A&B ...
> @2:142) -> [Help 1]
> {code}
> Escaping the ampersand twice helps, but it shouldn't be necessary:
> {code:java}
> client for A&B services {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7656) Dependencies copied to target have stricter permissions
[
https://issues.apache.org/jira/browse/MNG-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706553#comment-17706553
]
Michael Osipov commented on MNG-7656:
-
[~cstamas], I think this is resolved. Please add the proper Maven version and
close this one out.
> Dependencies copied to target have stricter permissions
> ---
>
> Key: MNG-7656
> URL: https://issues.apache.org/jira/browse/MNG-7656
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.0, 4.0.0-alpha-3
>Reporter: Moshe Elisha
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: maven.log
>
>
> Dependency JARs that were copied during "clean install" to target have read
> and write permissions only to the user/owner and no permissions at all to the
> group and others.("-rw---")
> Not sure if the issue is when maven downloads the JARs from the repo or when
> the JARs are copied from the repo to the target (using
> "dependency:3.4.0:copy-dependencies")
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] kwin merged pull request #265: improve documentation of banDynamicVersions
kwin merged PR #265: URL: https://github.com/apache/maven-enforcer/pull/265 -- 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=17706547#comment-17706547
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489105642
> But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation.
Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today.
I'm not to add new properties, really just to get a single functional
rootdir one (hopefully merged with multi one but if not at least reliable on
any maven compatible projects).
My definition enables to use it for checkstyles, headers etc even without a
.mvn (whereas it works in a minority of cases - statistically - if not done
this way). It can also work when using an aggregator if the pom uses properties
to define paths exactly as .mvn case which does not solve this issue since for
a project with `root > {child1/.mvn>subchild1,child2/.mvn>subchild2}` it will
randomly take child1 or child2 as rootdir.
Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
> 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-1489105642
> But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation.
Interpolation does not really works there anyway so no, but yes it will
require a 2 phases processing, guess it is not a big blocker as of today.
I'm not to add new properties, really just to get a single functional
rootdir one (hopefully merged with multi one but if not at least reliable on
any maven compatible projects).
My definition enables to use it for checkstyles, headers etc even without a
.mvn (whereas it works in a minority of cases - statistically - if not done
this way). It can also work when using an aggregator if the pom uses properties
to define paths exactly as .mvn case which does not solve this issue since for
a project with `root > {child1/.mvn>subchild1,child2/.mvn>subchild2}` it will
randomly take child1 or child2 as rootdir.
Side note: using .mvn also has a nasty side effect, we couldnt use it in
nested directories for module specific configuration anymore whereas it can
come later if we support lock files, dependency routing or other metadata per
module we don't want to put in the pom to keep it readable. It would be a
natural location for me.
Maybe thinking out loud but do we attack the issue by the right side, for
configuration location we want to be able to pin absolutely a file (often the
root pom), shouldn't we enable it? Main issue is that `${project.}` is
interpolated per pom so maybe we should enable a definition pinning, ie
`${project.definition.basedir}` - name is bad but sharing the idea - would stay
`/opt/foo` for `/opt/foo/pom.xml` but also its child `/opt/foo/child/pom.xml`?
This looks pretty easy to handle in interpolation and drops this `rootdir` need
in properties for user/mojo configuration. Can it be an outcome?
--
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-site] michael-o commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
michael-o commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489093701 > It is broken currently! Is it worse with m3 or better? At least the table in https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html looks correct with m3 (and severely broken in 1.11.1). We can easily upgrade to M5 once released Well, verbatim source is broken as well. If you can wait two days than you can go to M5 directly. -- 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-site] kwin commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
kwin commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489081339 It is broken currently! Is it worse with m3 or better? At least the table in https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html looks correct with m3 (and severely broken in 1.11.1). We can easily upgrade to M5 once released -- 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=17706535#comment-17706535
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489078230
> So this PR just duplicates the properties we have without solving any new
feature but does it differently from before. Git is different because the
bubbling is cleaner whereas .mvn is an user dir pushed to the repos (compared
to git which is not) and this is what breaks current impl as explained (agree
it i as much as parent/child impl but as much both ways). If we can't do better
than what we have today, let's keep/enhance what we have instead of creating
something very confusing for end user and not better in terms of reliability
(which prop to use being said none is really what I want or has side effects).
>
> > If you aggregate projects using submodules in a bigger aggregator, the
definition of the rootdir indicates it won't bubble up, and that's definitely
what we want, else the project build may fail locating files that are pointed
to.
>
> Hmm, you can make it run in both case depending how you define it (with
.mvn in root but not children or with in children), so you still have broken
cases. If you aggregate you will get a single rootdir..so it is broken as soon
as you get 2 subprojects - actually one since parent will not have its rootdir
cleanly set.
>
> Ideally we need a marker to set the root dir, we could use git as
inspiration and force the presence of a `.mvn/.mvn_meta` which would be handled
at "clone"/setup time somehow (do we fail if this file is missing, how do we
ensure it is not committed and experience is smooth when a project is cloned?).
>
> The parent/child resolution + filtering to ensure the resolution does not
use .m2/remote is still way more reliable IMHO since it always works to get a
deterministic rootdir. Only case it is broken is when the child does not
reference the parent but then the intent of the user was to be able to run
either from the parent (rootdir=parent) or child only (rootdir=child) so we
always exactly match the intent whereas with .mvn we have several counter
examples since the presence is optional.
But the parent/child relationship has to be done later in the process, so
can't be used for early interpolation.If you can come up with a nice
definition, we can define additional properties. Although, those are already
available from various plugins, so not sure we do actually need them, unless
there is pressing needs, but I still don't grab the use case for those. For
example, they could not be used to locate checkstyle rules, headers files and
such, as those have to be local to the project when aggregated in a bigger
reactor. For those, the `.mvn` does work reliably. So what's your use case ?
> 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-1489078230 > So this PR just duplicates the properties we have without solving any new feature but does it differently from before. Git is different because the bubbling is cleaner whereas .mvn is an user dir pushed to the repos (compared to git which is not) and this is what breaks current impl as explained (agree it i as much as parent/child impl but as much both ways). If we can't do better than what we have today, let's keep/enhance what we have instead of creating something very confusing for end user and not better in terms of reliability (which prop to use being said none is really what I want or has side effects). > > > If you aggregate projects using submodules in a bigger aggregator, the definition of the rootdir indicates it won't bubble up, and that's definitely what we want, else the project build may fail locating files that are pointed to. > > Hmm, you can make it run in both case depending how you define it (with .mvn in root but not children or with in children), so you still have broken cases. If you aggregate you will get a single rootdir..so it is broken as soon as you get 2 subprojects - actually one since parent will not have its rootdir cleanly set. > > Ideally we need a marker to set the root dir, we could use git as inspiration and force the presence of a `.mvn/.mvn_meta` which would be handled at "clone"/setup time somehow (do we fail if this file is missing, how do we ensure it is not committed and experience is smooth when a project is cloned?). > > The parent/child resolution + filtering to ensure the resolution does not use .m2/remote is still way more reliable IMHO since it always works to get a deterministic rootdir. Only case it is broken is when the child does not reference the parent but then the intent of the user was to be able to run either from the parent (rootdir=parent) or child only (rootdir=child) so we always exactly match the intent whereas with .mvn we have several counter examples since the presence is optional. But the parent/child relationship has to be done later in the process, so can't be used for early interpolation.If you can come up with a nice definition, we can define additional properties. Although, those are already available from various plugins, so not sure we do actually need them, unless there is pressing needs, but I still don't grab the use case for those. For example, they could not be used to locate checkstyle rules, headers files and such, as those have to be local to the project when aggregated in a bigger reactor. For those, the `.mvn` does work reliably. So what's your use case ? -- 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-site] michael-o commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
michael-o commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489069675 > m-site-p is already on version 4.0.0-M6, > > https://github.com/apache/maven-site/blob/4624b5cb3301670c7faac8d838844f0ba35bdfc9/pom.xml#L116 Then you should wit for M5 of the skin. -- 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-site] kwin commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
kwin commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489067849 m-site-p is already on version 4.0.0-M6, https://github.com/apache/maven-site/blob/4624b5cb3301670c7faac8d838844f0ba35bdfc9/pom.xml#L116 -- 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-site] michael-o commented on pull request #404: Update to m-fluido 2.0.0-M3 due to
michael-o commented on PR #404: URL: https://github.com/apache/maven-site/pull/404#issuecomment-1489065395 This needs to go hand in hand with Maven Site Plugin, but consider that there might be plugins which aren't compatible anymore. They won't fail, but they might produce garbage output. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17706524#comment-17706524
]
Venelin Koulaxazov edited comment on MBUILDCACHE-47 at 3/29/23 5:51 PM:
Adding the property in the pom of this module seems to have done the trick
actually! Thank you for this pointer [~maximiln] !
Very quickly before I close the bug, if I make a small change in code in one of
the modules it will effectively recompile it entirely and not only the single
file that changed. Is there something in the roadmap for this extension to
recompile only what has changed or we're hitting limitations around the maven
tool itself and how things are packaged in the resulting .jar file
was (Author: JIRAUSER299290):
Adding the property in the pom of this module seems to have done the trick
actually! Thank you for this pointed [~maximiln] !
Very quickly before I close the bug, if I make a small change in code in one of
the modules it will effectively recompile it entirely and not only the single
file that changed. Is there something in the roadmap for this extension to
recompile only what has changed or we're hitting limitations around the maven
tool itself and how things are packaged in the resulting .jar file
> 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] [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=17706527#comment-17706527
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489045762
So this PR just duplicates the properties we have without solving any new
feature but does it differently from before.
Git is different because the bubbling is cleaner whereas .mvn is an user dir
pushed to the repos (compared to git which is not) and this is what breaks
current impl as explained (agree it i as much as parent/child impl but as much
both ways).
If we can't do better than what we have today, let's keep/enhance what we
have instead of creating something very confusing for end user and not better
in terms of reliability (which prop to use being said none is really what I
want or has side effects).
> If you aggregate projects using submodules in a bigger aggregator, the
definition of the rootdir indicates it won't bubble up, and that's definitely
what we want, else the project build may fail locating files that are pointed
to.
Hmm, you can make it run in both case depending how you define it (with .mvn
in root but not children or with in children), so you still have broken cases.
If you aggregate you will get a single rootdir..so it is broken as soon as
you get 2 subprojects - actually one since parent will not have its rootdir
cleanly set.
Ideally we need a marker to set the root dir, we could use git as
inspiration and force the presence of a `.mvn/.mvn_meta` which would be handled
at "clone"/setup time somehow (do we fail if this file is missing, how do we
ensure it is not committed and experience is smooth when a project is cloned?).
The parent/child resolution + filtering to ensure the resolution does not
use .m2/remote is still way more reliable IMHO since it always works to get a
deterministic rootdir. Only case it is broken is when the child does not
reference the parent but then the intent of the user was to be able to run
either from the parent (rootdir=parent) or child only (rootdir=child) so we
always exactly match the intent whereas with .mvn we have several counter
examples since the presence is optional.
> 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-1489045762 So this PR just duplicates the properties we have without solving any new feature but does it differently from before. Git is different because the bubbling is cleaner whereas .mvn is an user dir pushed to the repos (compared to git which is not) and this is what breaks current impl as explained (agree it i as much as parent/child impl but as much both ways). If we can't do better than what we have today, let's keep/enhance what we have instead of creating something very confusing for end user and not better in terms of reliability (which prop to use being said none is really what I want or has side effects). > If you aggregate projects using submodules in a bigger aggregator, the definition of the rootdir indicates it won't bubble up, and that's definitely what we want, else the project build may fail locating files that are pointed to. Hmm, you can make it run in both case depending how you define it (with .mvn in root but not children or with in children), so you still have broken cases. If you aggregate you will get a single rootdir..so it is broken as soon as you get 2 subprojects - actually one since parent will not have its rootdir cleanly set. Ideally we need a marker to set the root dir, we could use git as inspiration and force the presence of a `.mvn/.mvn_meta` which would be handled at "clone"/setup time somehow (do we fail if this file is missing, how do we ensure it is not committed and experience is smooth when a project is cloned?). The parent/child resolution + filtering to ensure the resolution does not use .m2/remote is still way more reliable IMHO since it always works to get a deterministic rootdir. Only case it is broken is when the child does not reference the parent but then the intent of the user was to be able to run either from the parent (rootdir=parent) or child only (rootdir=child) so we always exactly match the intent whereas with .mvn we have several counter examples since the presence is optional. -- 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] (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:comment-tabpanel&focusedCommentId=17706524#comment-17706524
]
Venelin Koulaxazov commented on MBUILDCACHE-47:
---
Adding the property in the pom of this module seems to have done the trick
actually! Thank you for this pointed [~maximiln] !
Very quickly before I close the bug, if I make a small change in code in one of
the modules it will effectively recompile it entirely and not only the single
file that changed. Is there something in the roadmap for this extension to
recompile only what has changed or we're hitting limitations around the maven
tool itself and how things are packaged in the resulting .jar file
> 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] [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=17706523#comment-17706523
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489027939
> > well the parent-child relation, and I often build setups where there are
not really parent/child
>
> as much as the `.mvn` thing actually, we are used to get it in the root
dir but with fake parents (submodules for ex) it can be in the wrong dir so
both strategies are as bad but relying on a recent addition and something not
required by the project sounds very fragile upfront.
I don't think it's broken, it's your use case which is wrong. If you
aggregate projects using submodules in a bigger aggregator, the definition of
the `rootdir` indicates it won't bubble up, and that's definitely what we want,
else the project build may fail locating files that are pointed to. If we want
a property that would point to the upper aggregator directory, we can define
another property for that in a new PR, but I'm not sure about the use case for
it yet, do you actually have one ? Ffwiw, `git` has some similar properties to
go up out of the gitmodule.
> 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-1489027939 > > well the parent-child relation, and I often build setups where there are not really parent/child > > as much as the `.mvn` thing actually, we are used to get it in the root dir but with fake parents (submodules for ex) it can be in the wrong dir so both strategies are as bad but relying on a recent addition and something not required by the project sounds very fragile upfront. I don't think it's broken, it's your use case which is wrong. If you aggregate projects using submodules in a bigger aggregator, the definition of the `rootdir` indicates it won't bubble up, and that's definitely what we want, else the project build may fail locating files that are pointed to. If we want a property that would point to the upper aggregator directory, we can define another property for that in a new PR, but I'm not sure about the use case for it yet, do you actually have one ? Ffwiw, `git` has some similar properties to go up out of the gitmodule. -- 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=17706521#comment-17706521
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489020126
> I'm very confused by this PR, what I see:
>
> 1. we had 2 dir properties and they are deprecated in favor of 2 dir
properties, can't we fix the previous ones?
My option was to not break anything, it was easier to define a new set of
properties and deprecate the old ones rather than trying to find all spots
where things could be impacted.
> 2. the root dir is defined by the `.mvn` presence which is still not
mainstream so will likely always fail instead of the top dir of linked project
by the parent/child relationship defined by pom (which always works)
Well, the current definition is closer to
`maven.multiModuleProjectDirectory` which has been used for years, even if not
really public. The idea to rely on parent/child relationship just does not
work imho : first, it would have to be computed after all projects are parsed,
which conflicts with the fact that one of the use case it during project
interpolation, or even very early during the command line interpolation.
Although, there's absolutely no guarantee that it will point to the root level
of the project, as I can point to lots of projects where this would not work.
And the main use case imho it to locate files on the file system, so the
parent/child relationship is completely unrelated and would not solve the
issue. It also have to never change for any build of the project, which would
not be the case for any computation based on parent/child relationship.
> So overall think the impl should be fixed (2) and we should probably
collapse most of the properties we have, in particular for v4 where it will
just be a clean up and avoid the redefinition of new props. The big pro of root
dir is the ability to define absolutely a file config (style.xml is what i have
in mind but there are multiple cases) so should absolutely be reliable for all
projects, even without .mvn IMHO.
It is at least very precisely defined and deterministic: you start from the
`topdir` and go up until you find a `.mvn` tree. If there's none, the property
is not defined. And it is fully compatible with all existing projects, that's
the benefit of having new properties.
> 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-1489020126 > I'm very confused by this PR, what I see: > > 1. we had 2 dir properties and they are deprecated in favor of 2 dir properties, can't we fix the previous ones? My option was to not break anything, it was easier to define a new set of properties and deprecate the old ones rather than trying to find all spots where things could be impacted. > 2. the root dir is defined by the `.mvn` presence which is still not mainstream so will likely always fail instead of the top dir of linked project by the parent/child relationship defined by pom (which always works) Well, the current definition is closer to `maven.multiModuleProjectDirectory` which has been used for years, even if not really public. The idea to rely on parent/child relationship just does not work imho : first, it would have to be computed after all projects are parsed, which conflicts with the fact that one of the use case it during project interpolation, or even very early during the command line interpolation. Although, there's absolutely no guarantee that it will point to the root level of the project, as I can point to lots of projects where this would not work. And the main use case imho it to locate files on the file system, so the parent/child relationship is completely unrelated and would not solve the issue. It also have to never change for any build of the project, which would not be the case for any computation based on parent/child relationship. > So overall think the impl should be fixed (2) and we should probably collapse most of the properties we have, in particular for v4 where it will just be a clean up and avoid the redefinition of new props. The big pro of root dir is the ability to define absolutely a file config (style.xml is what i have in mind but there are multiple cases) so should absolutely be reliable for all projects, even without .mvn IMHO. It is at least very precisely defined and deterministic: you start from the `topdir` and go up until you find a `.mvn` tree. If there's none, the property is not defined. And it is fully compatible with all existing projects, that's the benefit of having new properties. -- 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-site] kwin opened a new pull request, #404: Update to m-fluido 2.0.0-M3 due to
kwin opened a new pull request, #404: URL: https://github.com/apache/maven-site/pull/404 https://issues.apache.org/jira/browse/MSKINS-207 -- 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=17706519#comment-17706519
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1489011010
> well the parent-child relation, and I often build setups where there are
not really parent/child
as much as the `.mvn` thing actually, we are used to get it in the root dir
but with fake parents (submodules for ex) it can be in the wrong dir so both
strategies are as bad but relying on a recent addition and something not
required by the project sounds very fragile upfront.
The parent child relationship is pretty straight forward: resolve all the
graph while child is linked to a parent and relativepath != null and parent is
not resolved from .m2/remote. Then take the higher folder.
It is as fragile as the .mvn but always works.
It is fine for me to use the .mvn as a "stop bubbling" marker if present but
if none is found parent/child relationship should be used IMHO.
> 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-1489011010 > well the parent-child relation, and I often build setups where there are not really parent/child as much as the `.mvn` thing actually, we are used to get it in the root dir but with fake parents (submodules for ex) it can be in the wrong dir so both strategies are as bad but relying on a recent addition and something not required by the project sounds very fragile upfront. The parent child relationship is pretty straight forward: resolve all the graph while child is linked to a parent and relativepath != null and parent is not resolved from .m2/remote. Then take the higher folder. It is as fragile as the .mvn but always works. It is fine for me to use the .mvn as a "stop bubbling" marker if present but if none is found parent/child relationship should be used IMHO. -- 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=17706517#comment-17706517
]
ASF GitHub Bot commented on MNG-7038:
-
laeubi commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1488999749
I only can add that I always have a `.mvn` dir in any setup, so "still not
mainstream so will likely always fail " is probably depending on personal
use-cases and experience.
Also I like it very much as it is both very basic, and easy to understand
and **always** works and is global across the build, where any parent/child
relation depends on.. well the parent-child relation, and I often build setups
where there are not really parent/child but only an aggregator pom what
includes other modules that probably have another parent so there is now way
for a global property, eg. aggregator include `project1` that has `parentA` and
it includes `project2` that has `parentB`, while mabye at the same reactor or
even not, so what should this "parent/child defined property" point to?
> 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-1488999749 I only can add that I always have a `.mvn` dir in any setup, so "still not mainstream so will likely always fail " is probably depending on personal use-cases and experience. Also I like it very much as it is both very basic, and easy to understand and **always** works and is global across the build, where any parent/child relation depends on.. well the parent-child relation, and I often build setups where there are not really parent/child but only an aggregator pom what includes other modules that probably have another parent so there is now way for a global property, eg. aggregator include `project1` that has `parentA` and it includes `project2` that has `parentB`, while mabye at the same reactor or even not, so what should this "parent/child defined property" point to? -- 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=17706509#comment-17706509
]
ASF GitHub Bot commented on MNG-7038:
-
rmannibucau commented on PR #1061:
URL: https://github.com/apache/maven/pull/1061#issuecomment-1488942008
I'm very confused by this PR, what I see:
1. we had 2 dir properties and they are deprecated in favor of 2 dir
properties, can't we fix the previous ones?
2. the root dir is defined by the `.mvn` presence which is still not
mainstream so will likely always fail instead of the top dir of linked project
by the parent/child relationship defined by pom (which always works)
So overall think the impl should be fixed (2) and we should probably
collapse most of the properties we have, in particular for v4 where it will
just be a clean up and avoid the redefinition of new props.
The big pro of root dir is the ability to define absolutely a file config
(style.xml is what i have in mind but there are multiple cases) so should
absolutely be reliable for all projects, even without .mvn IMHO.
> 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-1488942008 I'm very confused by this PR, what I see: 1. we had 2 dir properties and they are deprecated in favor of 2 dir properties, can't we fix the previous ones? 2. the root dir is defined by the `.mvn` presence which is still not mainstream so will likely always fail instead of the top dir of linked project by the parent/child relationship defined by pom (which always works) So overall think the impl should be fixed (2) and we should probably collapse most of the properties we have, in particular for v4 where it will just be a clean up and avoid the redefinition of new props. The big pro of root dir is the ability to define absolutely a file config (style.xml is what i have in mind but there are multiple cases) so should absolutely be reliable for all projects, even without .mvn IMHO. -- 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-enforcer] kwin opened a new pull request, #265: improve documentation of banDynamicVersions
kwin opened a new pull request, #265: URL: https://github.com/apache/maven-enforcer/pull/265 fix wrong description of allowRanges add JIRA link for allowRangesWithIdenticalBounds clarify excludedScopes Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MENFORCER) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (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=17706497#comment-17706497
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152181028
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
Very good, agreed.
> 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_r1152181028
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
Very good, agreed.
--
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=17706438#comment-17706438
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152107242
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
> How does this then collide with `${project.basedir}`? The devs should be
able to acces the current module project basedir. This should not change.
Yes, I meant to deprecate `${basedir}` and favor `${project.basedir}`.
> 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_r1152107242
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
> How does this then collide with `${project.basedir}`? The devs should be
able to acces the current module project basedir. This should not change.
Yes, I meant to deprecate `${basedir}` and favor `${project.basedir}`.
--
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=17706424#comment-17706424
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152079980
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
> That's true, if we don't support the non prefixed expression, we can
simply use the code which follows and which should handle `session.rootdir` and
`session.topdir` perfectly. Would you prefer that ?
Yes, strive for consistency
> 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_r1152079980
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
> That's true, if we don't support the non prefixed expression, we can
simply use the code which follows and which should handle `session.rootdir` and
`session.topdir` perfectly. Would you prefer that ?
Yes, strive for consistency
--
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=17706423#comment-17706423
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152077350
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
Accepted
> 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_r1152077350
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
Accepted
--
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=17706410#comment-17706410
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152028179
##
maven-model-builder/src/main/java/org/apache/maven/model/interpolation/AbstractStringBasedModelInterpolator.java:
##
@@ -133,6 +134,21 @@ public Object getValue(String expression) {
valueSources.add(new
BuildTimestampValueSource(config.getBuildStartTime(), modelProperties));
}
+valueSources.add(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+if ("rootdir".equals(expression)) {
+Path path = config.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
Agreed, I'll fix them all.
> 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_r1152028179
##
maven-model-builder/src/main/java/org/apache/maven/model/interpolation/AbstractStringBasedModelInterpolator.java:
##
@@ -133,6 +134,21 @@ public Object getValue(String expression) {
valueSources.add(new
BuildTimestampValueSource(config.getBuildStartTime(), modelProperties));
}
+valueSources.add(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+if ("rootdir".equals(expression)) {
+Path path = config.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
Agreed, I'll fix them all.
--
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=17706408#comment-17706408
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152023745
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But we can't know early if someone uses the `${session.rootdir}`or
`${rootdir}` in the model, profile activation or a plugin configuration. If we
fail early, this will mean that all projects will be required to add this
`.mvn` direction. Note that we already have a warning if this directory does
not exist.
> 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)
[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=17706409#comment-17706409
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152023745
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But we can't know early if someone uses the `${session.rootdir}`or
`${rootdir}` in the model, profile activation or a plugin configuration. If we
fail early, this will mean that all projects will be required to add this
`.mvn` direction, whether they actually use it or not. Note that we already
have a warning if this directory does not exist.
> 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_r1152023745
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But we can't know early if someone uses the `${session.rootdir}`or
`${rootdir}` in the model, profile activation or a plugin configuration. If we
fail early, this will mean that all projects will be required to add this
`.mvn` direction, whether they actually use it or not. Note that we already
have a warning if this directory does not exist.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] gnodet 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_r1152023745
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But we can't know early if someone uses the `${session.rootdir}`or
`${rootdir}` in the model, profile activation or a plugin configuration. If we
fail early, this will mean that all projects will be required to add this
`.mvn` direction. Note that we already have a warning if this directory does
not exist.
--
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] 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_r1152018222
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
How does this then collide with `${project.basedir}`? The devs should be
able to acces the current module project basedir. This should not change.
--
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=17706403#comment-17706403
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152018222
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
How does this then collide with `${project.basedir}`? The devs should be
able to acces the current module project basedir. This should not change.
> 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)
[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=17706402#comment-17706402
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152016383
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But rather fail early than after 30 min of a build?
> 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)
[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=17706401#comment-17706401
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152000103
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,50 @@ 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.
+ * If there's no such file, an {@code IllegalArgumentException} will be
thrown.
+ *
+ * @throws IllegalArgumentException if the root directory could not be
found
Review Comment:
Isn't this `IllegalStateException`?
##
maven-model-builder/src/main/java/org/apache/maven/model/interpolation/AbstractStringBasedModelInterpolator.java:
##
@@ -133,6 +134,21 @@ public Object getValue(String expression) {
valueSources.add(new
BuildTimestampValueSource(config.getBuildStartTime(), modelProperties));
}
+valueSources.add(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+if ("rootdir".equals(expression)) {
+Path path = config.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
ISE rather? The expression isn't invalid but the state within, no?
##
maven-model-builder/src/main/java/org/apache/maven/model/path/ProfileActivationFilePathInterpolator.java:
##
@@ -79,6 +80,25 @@ public Object getValue(String expression) {
return null;
}
+interpolator.addValueSource(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+/*
+ * We intentionally only support ${rootdir} and not
${session.rootdir} as the latter form
+ * would suggest that other session.* expressions can be used
which is beyond the design.
+ */
+if ("rootdir".equals(expression)) {
+Path path = context.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
Same here
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -321,6 +323,46 @@ void initialize(CliRequest cliRequest) throws
ExitException {
}
}
+Path topdir = Paths.get(cliRequest.workingDirectory);
+boolean isAltFile = false;
+for (String arg : cliRequest.args) {
+if (isAltFile) {
+Path path = Paths.get(arg);
+if (Files.isDirectory(path)) {
Review Comment:
Granted.
> 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 w
[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_r1152016383
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
But rather fail early than after 30 min of a build?
--
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] 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_r1152000103
##
maven-core/src/main/java/org/apache/maven/execution/MavenExecutionRequest.java:
##
@@ -494,14 +504,50 @@ 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.
+ * If there's no such file, an {@code IllegalArgumentException} will be
thrown.
+ *
+ * @throws IllegalArgumentException if the root directory could not be
found
Review Comment:
Isn't this `IllegalStateException`?
##
maven-model-builder/src/main/java/org/apache/maven/model/interpolation/AbstractStringBasedModelInterpolator.java:
##
@@ -133,6 +134,21 @@ public Object getValue(String expression) {
valueSources.add(new
BuildTimestampValueSource(config.getBuildStartTime(), modelProperties));
}
+valueSources.add(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+if ("rootdir".equals(expression)) {
+Path path = config.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
ISE rather? The expression isn't invalid but the state within, no?
##
maven-model-builder/src/main/java/org/apache/maven/model/path/ProfileActivationFilePathInterpolator.java:
##
@@ -79,6 +80,25 @@ public Object getValue(String expression) {
return null;
}
+interpolator.addValueSource(new AbstractValueSource(false) {
+@Override
+public Object getValue(String expression) {
+/*
+ * We intentionally only support ${rootdir} and not
${session.rootdir} as the latter form
+ * would suggest that other session.* expressions can be used
which is beyond the design.
+ */
+if ("rootdir".equals(expression)) {
+Path path = context.getRootdir();
+if (path != null) {
+return path.toString();
+}
+throw new IllegalArgumentException("Unable to find the
root directory. "
Review Comment:
Same here
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -321,6 +323,46 @@ void initialize(CliRequest cliRequest) throws
ExitException {
}
}
+Path topdir = Paths.get(cliRequest.workingDirectory);
+boolean isAltFile = false;
+for (String arg : cliRequest.args) {
+if (isAltFile) {
+Path path = Paths.get(arg);
+if (Files.isDirectory(path)) {
Review Comment:
Granted.
--
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=17706399#comment-17706399
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152011959
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
The goal is to throw an exception when actually used. So it's not a hard
requirement unless you actually use it somehow in a plugin or in a model, in
which case, yes, it becomes a hard requirement.
> 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_r1152011959
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
The goal is to throw an exception when actually used. So it's not a hard
requirement unless you actually use it somehow in a plugin or in a model, in
which case, yes, it becomes a hard requirement.
--
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=17706398#comment-17706398
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1152003319
##
maven-model-builder/src/site/apt/index.apt:
##
@@ -192,6 +192,10 @@ Maven Model Builder
*+--+--+
| <<>> | The path to the current Maven home. |
<<<$\{maven.home\}>>> |
*+--+--+
+| <<>> | the directory containing the root <<>> file
of a multi module project, in a single module project this is the same as
<<>> | <<<$\{maven.rootdir\}>>> |
+*+--+--+
+| <<>> | the directory containing the top-level <<>> in
this reactor build | <<<$\{maven.topdir\}>>> |
+*+--+--+
Review Comment:
`topdir` is not really new, it's mostly a rename of the `executionRootDir`
property to make it more coherent with `basedir` and `rootdir`, else we end up
with `root directory` and `execution root directory` for different things, and
that will definitely lead to problems imho.
> 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_r1152003319
##
maven-model-builder/src/site/apt/index.apt:
##
@@ -192,6 +192,10 @@ Maven Model Builder
*+--+--+
| <<>> | The path to the current Maven home. |
<<<$\{maven.home\}>>> |
*+--+--+
+| <<>> | the directory containing the root <<>> file
of a multi module project, in a single module project this is the same as
<<>> | <<<$\{maven.rootdir\}>>> |
+*+--+--+
+| <<>> | the directory containing the top-level <<>> in
this reactor build | <<<$\{maven.topdir\}>>> |
+*+--+--+
Review Comment:
`topdir` is not really new, it's mostly a rename of the `executionRootDir`
property to make it more coherent with `basedir` and `rootdir`, else we end up
with `root directory` and `execution root directory` for different things, and
that will definitely lead to problems imho.
--
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=17706395#comment-17706395
]
ASF GitHub Bot commented on MNG-7038:
-
michael-o commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151997995
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
This needs to be documented since it looks like a hard requirement now.
> 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_r1151997995
##
maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequest.java:
##
@@ -1051,16 +1057,44 @@ public MavenExecutionRequest setToolchains(Map> too
return this;
}
+@Deprecated
@Override
public void setMultiModuleProjectDirectory(File directory) {
this.multiModuleProjectDirectory = directory;
}
+@Deprecated
@Override
public File getMultiModuleProjectDirectory() {
return multiModuleProjectDirectory;
}
+@Override
+public Path getRootdir() {
+if (rootdir == null) {
+throw new IllegalArgumentException("Unable to find the root
directory. "
Review Comment:
This needs to be documented since it looks like a hard requirement now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-project-info-reports-plugin] elharo commented on pull request #46: [MPIR-432] upgrade to parent POM 39
elharo commented on PR #46: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/46#issuecomment-1488648543 https://github.com/google/google-java-format/issues/697 -- 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-project-info-reports-plugin] elharo commented on pull request #46: [MPIR-432] upgrade to parent POM 39
elharo commented on PR #46: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/46#issuecomment-1488644198 Fixed the duplicate licenses. The Modifier.SEALED problem remains. I am really not happy with the palantir-java-format. It seems quite buggy and unreliable. I wonder if google-java-format is better? This problem could mean that palantir-java-format is looking at the byte code and getting confused about VM versions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on issue #828: Failed to load native library:jansi-2.4.0-b00c64e8b23a020c-jansi.dll. osinfo: Windows/x86_64
ppalaga commented on issue #828: URL: https://github.com/apache/maven-mvnd/issues/828#issuecomment-1488609917 Perhaps a duplicate of https://github.com/apache/maven-mvnd/issues/571? - that one suggests to upgrade to a newer Java 11 version. You say you have openjdk 20. Does it work with an older JDK version, such as 17 or 11 for you? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga commented on pull request #810: Add configuration to send build scans to https://ge.apache.org
ppalaga commented on PR #810: URL: https://github.com/apache/maven-mvnd/pull/810#issuecomment-1488602421 Sorry gentlemen, no time at all for mvnd this month. -- 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] (MSITE-933) mvn site fails when contains &
Heiko Selber created MSITE-933:
--
Summary: mvn site fails when contains &
Key: MSITE-933
URL: https://issues.apache.org/jira/browse/MSITE-933
Project: Maven Site Plugin
Issue Type: Bug
Affects Versions: 4.0.0-M6, 3.12.1
Environment: Ubuntu 22.04.2 LTS
Apache Maven 3.9.0
Java version: 17.0.4.1, vendor: Eclipse Adoptium
Reporter: Heiko Selber
A project containing an escaped ampersand in the name element fails in mvn site.
Consider a project containing nothing but this pom.xml:
{code:java}
4.0.0
experiments
experiments
client for A&B services
0.0.1-SNAPSHOT
{code}
This project builds fine with the standard build cycle, e.g. mvn install.
However, with mvn site (or explicitly mvn site:4.0.0-M6:site) it throws an
error:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:4.0.0-M6:site (default-cli) on
project experiments: SiteToolException: Error parsing site descriptor: entity
reference name can not contain character ' (position: START_DOCUMENT seen
...//maven.apache.org/xsd/decoration-2.0.0.xsd" name="client for A&B ...
@2:142) -> [Help 1]
{code}
Escaping the ampersand twice helps, but it shouldn't be necessary:
{code:java}
client for A&B services {code}
--
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=17706355#comment-17706355
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151777611
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
@michael-o fwiw, the addition of `rootdir` and `topdir` was done to be in
line with `basedir`, so maybe we should deprecate that one ? I'll raise a PR
to clean at least the v4 expression evaluator, as plugins will have to migrate
to switch to it anyway.
> 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_r1151777611
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
@michael-o fwiw, the addition of `rootdir` and `topdir` was done to be in
line with `basedir`, so maybe we should deprecate that one ? I'll raise a PR
to clean at least the v4 expression evaluator, as plugins will have to migrate
to switch to it anyway.
--
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=17706352#comment-17706352
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151777611
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
@michael-o fwiw, the addition of `rootdir` and `topdir` was done to be in
line with `basedir`, so maybe we should deprecate that one ?
> 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_r1151777611
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
@michael-o fwiw, the addition of `rootdir` and `topdir` was done to be in
line with `basedir`, so maybe we should deprecate that one ?
--
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=17706308#comment-17706308
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151708471
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
Review Comment:
That makes sense
> 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_r1151708471
##
api/maven-api-core/src/main/java/org/apache/maven/api/Project.java:
##
@@ -86,8 +86,34 @@ default String getId() {
return getModel().getId();
}
+/**
+ * @deprecated use {@link #isTopdirProject()} instead
+ */
+@Deprecated
boolean isExecutionRoot();
+/**
+ * Returns a boolean indicating if the project is the top leve project for
+ * this reactor build. The top level project may be different from the
+ * {@code rootDirProject}, especially if a subtree of the project is being
+ * built, either because maven has been launched in a subdirectory or using
+ * a {@code -f} option.
+ *
+ * @return {@code true} if the project is the top level project for this
build
+ */
+boolean isTopdirProject();
Review Comment:
That makes sense
--
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=17706306#comment-17706306
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151706480
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
That's true, if we don't support the non prefixed expression, we can simply
use the code which follows and which should handle `session.rootdir` and
`session.topdir` perfectly. Would you prefer that ?
> 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_r1151706480
##
maven-core/src/main/java/org/apache/maven/plugin/PluginParameterExpressionEvaluator.java:
##
@@ -165,7 +165,11 @@ public Object evaluate(String expr, Class type) throws
ExpressionEvaluationEx
MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
-if ("localRepository".equals(expression)) {
+if ("rootdir".equals(expression) ||
"session.rootdir".equals(expression)) {
+value = session.getRootdir();
+} else if ("topdir".equals(expression) ||
"session.topdir".equals(expression)) {
+value = session.getTopdir();
Review Comment:
That's true, if we don't support the non prefixed expression, we can simply
use the code which follows and which should handle `session.rootdir` and
`session.topdir` perfectly. Would you prefer that ?
--
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=17706305#comment-17706305
]
ASF GitHub Bot commented on MNG-7038:
-
gnodet commented on code in PR #1061:
URL: https://github.com/apache/maven/pull/1061#discussion_r1151704300
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -321,6 +323,46 @@ void initialize(CliRequest cliRequest) throws
ExitException {
}
}
+Path topdir = Paths.get(cliRequest.workingDirectory);
+boolean isAltFile = false;
+for (String arg : cliRequest.args) {
+if (isAltFile) {
+Path path = Paths.get(arg);
+if (Files.isDirectory(path)) {
Review Comment:
The `commandLine` variable is initialised in a following step. Also, if we
want to allow some interpolation in the command line arguments, we definitely
need to compute this variable early.
> 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_r1151704300
##
maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:
##
@@ -321,6 +323,46 @@ void initialize(CliRequest cliRequest) throws
ExitException {
}
}
+Path topdir = Paths.get(cliRequest.workingDirectory);
+boolean isAltFile = false;
+for (String arg : cliRequest.args) {
+if (isAltFile) {
+Path path = Paths.get(arg);
+if (Files.isDirectory(path)) {
Review Comment:
The `commandLine` variable is initialised in a following step. Also, if we
want to allow some interpolation in the command line arguments, we definitely
need to compute this variable early.
--
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
