[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=17654439#comment-17654439
]
Stefan Bischof commented on MNG-7038:
-
Any Progress on this? Does *Fix Version/s:*[Issues to be reviewed for
4.x|https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+%22Issues+to+be+reviewed+for+4.x%22]
mean that it will be in 4.0 Release?
Both properties seems to be adequate
{*}maven.multiModuleProjectDirectory{*} and *{{project.topdir}}*
After reading
[https://maven.apache.org/guides/mini/guide-multiple-modules-4.html] and if you
just wand to have it in reactor builds i would use
*project.reactor.dir*
But the discussion about the naming is not so important. its more importat to
have a proper description how it is calculated and in which cases it should be
uses and in which it would fail.
> 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] [Comment Edited] (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=17654439#comment-17654439
]
Stefan Bischof edited comment on MNG-7038 at 1/4/23 12:32 PM:
--
Any Progress on this? Does *Fix Version/s:* [Issues to be reviewed for
4.x|https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+%22Issues+to+be+reviewed+for+4.x%22]
mean that it will be in 4.0 Release?
Both properties seems to be adequate
*maven.multiModuleProjectDirectory* and *{{project.topdir}}*
After reading
[https://maven.apache.org/guides/mini/guide-multiple-modules-4.html] and if you
just wand to have it in reactor builds i would use
*project.reactor.dir* or *project.reactor.topdir*
But the discussion about the naming is not so important. its more important to
have a proper description how it is calculated and in which cases it should be
uses and in which it would fail.
And the description in the PR-840 seems clear.
"the directory containing the top level <<>> file of a multi module
project, in a single module project this is the same as <<>>"
was (Author: bisch...@jena.de):
Any Progress on this? Does *Fix Version/s:*[Issues to be reviewed for
4.x|https://issues.apache.org/jira/issues/?jql=project+%3D+MNG+AND+fixVersion+%3D+%22Issues+to+be+reviewed+for+4.x%22]
mean that it will be in 4.0 Release?
Both properties seems to be adequate
{*}maven.multiModuleProjectDirectory{*} and *{{project.topdir}}*
After reading
[https://maven.apache.org/guides/mini/guide-multiple-modules-4.html] and if you
just wand to have it in reactor builds i would use
*project.reactor.dir*
But the discussion about the naming is not so important. its more importat to
have a proper description how it is calculated and in which cases it should be
uses and in which it would fail.
> 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] [Created] (MNG-8058) Allow variables defined in .mvn/maven.config used as constants
Stefan Bischof created MNG-8058:
---
Summary: Allow variables defined in .mvn/maven.config used as
constants
Key: MNG-8058
URL: https://issues.apache.org/jira/browse/MNG-8058
Project: Maven
Issue Type: Improvement
Affects Versions: 4.0.0-alpha-12, 3.9.6
Reporter: Stefan Bischof
I would like to have all variables defined in .mvn/maven.config to be allowed
as constants.
My setup uses different versions on each module but i want to define them
central.
in my `.mvn/maven.config` file I define the variables
{code:java}
-Drevision.org.aaa.bbb=0.0.1-SNAPSHOT
-Drevision.org.aaa.bbb.ccc=0.0.2-SNAPSHOT
-Drevision.org.aaa.bbb.ddd=0.0.3-SNAPSHOT {code}
In my pom i want to use this variables to set version of perant ans artifact
itsselfe
{code:java}
org.aaa
org.aaa.bbb
${revision.org.aaa.bbb}
org.aaa.bbb.ccc
${revision.org.aaa.bbb.ccc} {code}
I am getting the warning
{code:java}
'version' contains an expression but should be a constant. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8058) Allow variables defined in .mvn/maven.config used as constants
[
https://issues.apache.org/jira/browse/MNG-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818799#comment-17818799
]
Stefan Bischof commented on MNG-8058:
-
i know about [https://maven.apache.org/maven-ci-friendly.html]
Thought it is an question of `is the value a constants` in full build process.
and are all this constants known at the very beginning.
[~michael-o]
What is the problem of `resolution hell` that will come up in this case?.
> Allow variables defined in .mvn/maven.config used as constants
> --
>
> Key: MNG-8058
> URL: https://issues.apache.org/jira/browse/MNG-8058
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Stefan Bischof
>Priority: Major
>
> I would like to have all variables defined in .mvn/maven.config to be allowed
> as constants.
> My setup uses different versions on each module but i want to define them
> central.
> in my `.mvn/maven.config` file I define the variables
>
> {code:java}
> -Drevision.org.aaa.bbb=0.0.1-SNAPSHOT
> -Drevision.org.aaa.bbb.ccc=0.0.2-SNAPSHOT
> -Drevision.org.aaa.bbb.ddd=0.0.3-SNAPSHOT {code}
>
> In my pom i want to use this variables to set version of perant ans artifact
> itsselfe
> {code:java}
>
> org.aaa
> org.aaa.bbb
> ${revision.org.aaa.bbb}
>
> org.aaa.bbb.ccc
> ${revision.org.aaa.bbb.ccc} {code}
> I am getting the warning
>
> {code:java}
> 'version' contains an expression but should be a constant. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17054234#comment-17054234 ] Stefan Bischof commented on MJAR-193: - @[~khmarbaise] [~kwin] [~rfscholte] Any update? > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler >Priority: Major > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAR-193) Allow other mojos to contribute to the manifest
[ https://issues.apache.org/jira/browse/MJAR-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17054383#comment-17054383 ] Stefan Bischof commented on MJAR-193: - if you give some KeyFacts someone could make a PR Are you open for this way? i only see one open Question: - maven-archiver or maven-jar-plugin [~rotty3000] are you still open to help? > Allow other mojos to contribute to the manifest > --- > > Key: MJAR-193 > URL: https://issues.apache.org/jira/browse/MJAR-193 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Carsten Ziegeler >Priority: Major > Fix For: waiting-for-feedback > > > It would be great to have a programmatic way to add entries to the manifest > from other mojos. The most important client of such a way would be the maven > bundle plugin (from the Apache Felix project) that calculates additional > headers for OSGi bundles. Right now, that bundle does not only do the > calculation but generates the jar file as well. > While a workaround would be to let the bundle plugin generate the full > manifest and configure the jar plugin to use it, this is not very elegant. > Passing down a map of manifest entries from one mojo to the jar plugin would > solve this in a much better way. > And I could imagine that other mojos/plugins might benefit for this as well. > This would be a simple but very convenient enhancement to the plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-8058) Allow variables defined in .mvn/maven.config used as constants
[
https://issues.apache.org/jira/browse/MNG-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888775#comment-17888775
]
Stefan Bischof commented on MNG-8058:
-
does this now work with the change:
https://issues.apache.org/jira/browse/MNG-8230
https://github.com/apache/maven/pull/1710
> Allow variables defined in .mvn/maven.config used as constants
> --
>
> Key: MNG-8058
> URL: https://issues.apache.org/jira/browse/MNG-8058
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.9.6, 4.0.0-alpha-12
>Reporter: Stefan Bischof
>Priority: Major
>
> I would like to have all variables defined in .mvn/maven.config to be allowed
> as constants.
> My setup uses different versions on each module but i want to define them
> central.
> in my `.mvn/maven.config` file I define the variables
>
> {code:java}
> -Drevision.org.aaa.bbb=0.0.1-SNAPSHOT
> -Drevision.org.aaa.bbb.ccc=0.0.2-SNAPSHOT
> -Drevision.org.aaa.bbb.ddd=0.0.3-SNAPSHOT {code}
>
> In my pom i want to use this variables to set version of perant ans artifact
> itsselfe
> {code:java}
>
> org.aaa
> org.aaa.bbb
> ${revision.org.aaa.bbb}
>
> org.aaa.bbb.ccc
> ${revision.org.aaa.bbb.ccc} {code}
> I am getting the warning
>
> {code:java}
> 'version' contains an expression but should be a constant. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
