[jira] [Updated] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-4917: - Fix Version/s: 4.1.0 > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0, 3.8.5 >Reporter: Benson Margulies >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.1.0 > > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887322#comment-17887322 ] Guillaume Nodet commented on MNG-4917: -- This should be handled as part of MNG-8292. > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0, 3.8.5 >Reporter: Benson Margulies >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.1.0 > > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8294) Add a consistency check when loading parent
Guillaume Nodet created MNG-8294:
Summary: Add a consistency check when loading parent
Key: MNG-8294
URL: https://issues.apache.org/jira/browse/MNG-8294
Project: Maven
Issue Type: Improvement
Reporter: Guillaume Nodet
Fix For: 4.0.0-beta-5
MNG-2196 provides an IT which was failing, but for the wrong reason. With the
addition of GAV inference in Maven 4, we need to revisit this bit to:
* move the default parent \{{relativePath}} \{{..}} as a default value when
loading the parent, rather than as a default value in the model
* this will allow checking consistency between the provided value (if there's
one) and the loaded model and fail if not equals
In short, if the parent {{relativePath}} is provided, it should be correct,
else Maven 4 can find it automatically in the reactor, else load it from
repository. In the first case, we need to verify the correct GAV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887365#comment-17887365
]
Michael Osipov commented on DOXIA-747:
--
This means that the sink needs to be stateful?
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}/
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887333#comment-17887333 ] Guillaume Nodet commented on MNG-4917: -- > > When we talk about a default value, this usually indicates "a value when no > > other value was explicitly given". > It's true. And the value is the activity, boolean. "The profile is active > unless explicitly deactivated". Playing with other profiles should not affect > this one. I think in this case, it was meant as "part of the set of profiles active by default", i.e. if no set of profiles if explicitely given. > > what's the benefit of having an always active profile ? > Say one have "sign" profile. Build artifacts should be signed by default, but > there should be a way to disable signing to produce "weaker" build for debug > purposes. Makes total sense. Thx ! The current plan is to merged those two booleans somehow into the new activation mechanism and to deprecate existing stuff, as part of MNG-8292. Feel free to chime in if you want. > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0, 3.8.5 >Reporter: Benson Margulies >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.1.0 > > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887357#comment-17887357
]
Michael Osipov commented on DOXIASITETOOLS-343:
---
So no need to do anything with Sitetools?
> Rewrite DefaultSiteTools project management
> ---
>
> Key: DOXIASITETOOLS-343
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The code loads MavenProject from local repositories and uses
> {{project.getBasedir() == null}} to check if the project was loaded from the
> local repository or if it is a real project.
> This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
> model from the local repository, one should use {{ModelBuilder}} and only use
> {{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887358#comment-17887358
]
Michael Osipov edited comment on DOXIA-746 at 10/7/24 2:12 PM:
---
I belive that such an overload is wrong because if the LS is part of the
format's semantic the specific should do that. In APT, I guess LS before and
after is mandatory.
was (Author: michael-o):
I belive that such an overload is wrong because if the LS is part of the
format's semantic the specific should do that. In Apt, I guess LS before and
after is mandatory.
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887358#comment-17887358
]
Michael Osipov commented on DOXIA-746:
--
I belive that such an overload is wrong because if the LS is part of the
format's semantic the specific should do that. In Apt, I guess LS before and
after is mandatory.
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus moved SLING-12447 to DOXIA-747:
---
Key: DOXIA-747 (was: SLING-12447)
Workflow: Default workflow, editable Closed status (was:
no-reopen-closed,doc-test-required)
Project: Maven Doxia (was: Sling)
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle}} with
> some text it is not emitted on a dedicated line.
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned DOXIA-747:
-
Assignee: Konrad Windszus
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}/
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-747:
--
Description:
If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
with some text it is not emitted on a dedicated line through the
{{MarkdownSink}}/
However according to https://spec.commonmark.org/0.31.2/#atx-headings
{quote} The opening # character may be preceded by up to three spaces of
indentation {quote}
was:
If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle}} with
some text it is not emitted on a dedicated line.
However according to https://spec.commonmark.org/0.31.2/#atx-headings
{quote} The opening # character may be preceded by up to three spaces of
indentation {quote}
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}/
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887359#comment-17887359
]
Konrad Windszus edited comment on DOXIA-746 at 10/7/24 2:19 PM:
If you consider the LS part of the comment this will lead to the following
HTML/Markdown
{code}
{code}
what is intended is
{code}
{code}
was (Author: kwin):
If you consider the LS part of the comment this will lead to the following HTML
{code}
{code}
what is intended is
{code}
{code}
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887359#comment-17887359
]
Konrad Windszus edited comment on DOXIA-746 at 10/7/24 2:18 PM:
If you consider the LS part of the comment this will lead to the following HTML
{code}
{code}
what is intended is
{code}
{code}
was (Author: kwin):
If you consider the LS part of the comment this will lead to the following HTML
{code}
{code}
what is intended is
{code}
{code}
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887359#comment-17887359
]
Konrad Windszus commented on DOXIA-746:
---
If you consider the LS part of the comment this will lead to the following HTML
{code}
{code}
what is intended is
{code}
{code}
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887360#comment-17887360
]
Michael Osipov commented on DOXIA-746:
--
Maybe I was not explicit enough: The sink impl must add the LS on its own if
the syntax requires it. Much like Python's indentation. The latter looks good
to me -- and right.
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8288) Path cannot be null while building reactor modules
[
https://issues.apache.org/jira/browse/MNG-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8288:
Assignee: Tamas Cservenak
> Path cannot be null while building reactor modules
> --
>
> Key: MNG-8288
> URL: https://issues.apache.org/jira/browse/MNG-8288
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Exception trace
> {noformat}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.IllegalArgumentException: path cannot be null
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:157)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.doExecute
> (DefaultMavenInvoker.java:449)
> at org.apache.maven.cli.DaemonMavenInvoker.doExecute
> (DaemonMavenInvoker.java:135)
> at org.apache.maven.cli.DaemonMavenInvoker.doExecute
> (DaemonMavenInvoker.java:39)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute
> (DefaultMavenInvoker.java:104)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute
> (DefaultMavenInvoker.java:72)
> at org.apache.maven.cling.invoker.LookupInvoker.doInvoke
> (LookupInvoker.java:202)
> at org.apache.maven.cling.invoker.LookupInvoker.invoke
> (LookupInvoker.java:177)
> at org.apache.maven.cli.DaemonMavenCling.main (DaemonMavenCling.java:76)
> at org.mvndaemon.mvnd.daemon.Server.handle (Server.java:616)
> at org.mvndaemon.mvnd.daemon.Server.client (Server.java:292)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2 (Server.java:254)
> at java.lang.Thread.run (Thread.java:1583)
> Caused by: java.lang.IllegalArgumentException: path cannot be null
> at org.apache.maven.api.services.BaseRequest.nonNull (BaseRequest.java:50)
> at org.apache.maven.api.services.ModelSource.fromPath
> (ModelSource.java:57)
> at org.apache.maven.api.services.ModelSource.fromPath
> (ModelSource.java:52)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.doReadFileModel
> (DefaultModelBuilder.java:1331)
> at
> org.apache.maven.internal.impl.model.DefaultModelCache$CachingSupplier.get
> (DefaultModelCache.java:178)
> at org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent
> (DefaultModelCache.java:65)
> at org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent
> (DefaultModelCache.java:56)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.cache
> (DefaultModelBuilder.java:1654)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.readFileModel
> (DefaultModelBuilder.java:1170)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadFilePom
> (DefaultModelBuilder.java:727)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadFromRoot
> (DefaultModelBuilder.java:705)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.buildBuildPom
> (DefaultModelBuilder.java:652)
> at org.apache.maven.internal.impl.model.DefaultModelBuilder$1.build
> (DefaultModelBuilder.java:227)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.build
> (DefaultProjectBuilder.java:491)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.lambda$doBuild$5
> (DefaultProjectBuilder.java:468)
> at java.util.stream.ReferencePipeline$3$1.accept
> (ReferencePipeline.java:197)
> at java.util.Collections$2.tryAdvance (Collections.java:5073)
> at java.util.Collections$2.forEachRemaining (Collections.java:5081)
> at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto
> (AbstractPipeline.java:499)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential
> (ReduceOps.java:921)
> at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:682)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.doBuild
> (DefaultProjectBuilder.java:470)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.build
> (DefaultProjectBuilder.java:444)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:183)
> at
> org.apache.maven.project.collector.DefaultProjectsSelector.selectProjects
> (DefaultProjectsSelector.java:61)
> at
> org.apache.maven.project.collector.RequestPomCollectionStrategy.collectProjects
> (RequestPomCollectionStrategy.java
[jira] [Closed] (MNG-8288) Path cannot be null while building reactor modules
[
https://issues.apache.org/jira/browse/MNG-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8288.
Resolution: Fixed
> Path cannot be null while building reactor modules
> --
>
> Key: MNG-8288
> URL: https://issues.apache.org/jira/browse/MNG-8288
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Exception trace
> {noformat}
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.IllegalArgumentException: path cannot be null
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:157)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.doExecute
> (DefaultMavenInvoker.java:449)
> at org.apache.maven.cli.DaemonMavenInvoker.doExecute
> (DaemonMavenInvoker.java:135)
> at org.apache.maven.cli.DaemonMavenInvoker.doExecute
> (DaemonMavenInvoker.java:39)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute
> (DefaultMavenInvoker.java:104)
> at org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute
> (DefaultMavenInvoker.java:72)
> at org.apache.maven.cling.invoker.LookupInvoker.doInvoke
> (LookupInvoker.java:202)
> at org.apache.maven.cling.invoker.LookupInvoker.invoke
> (LookupInvoker.java:177)
> at org.apache.maven.cli.DaemonMavenCling.main (DaemonMavenCling.java:76)
> at org.mvndaemon.mvnd.daemon.Server.handle (Server.java:616)
> at org.mvndaemon.mvnd.daemon.Server.client (Server.java:292)
> at org.mvndaemon.mvnd.daemon.Server.lambda$accept$2 (Server.java:254)
> at java.lang.Thread.run (Thread.java:1583)
> Caused by: java.lang.IllegalArgumentException: path cannot be null
> at org.apache.maven.api.services.BaseRequest.nonNull (BaseRequest.java:50)
> at org.apache.maven.api.services.ModelSource.fromPath
> (ModelSource.java:57)
> at org.apache.maven.api.services.ModelSource.fromPath
> (ModelSource.java:52)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.doReadFileModel
> (DefaultModelBuilder.java:1331)
> at
> org.apache.maven.internal.impl.model.DefaultModelCache$CachingSupplier.get
> (DefaultModelCache.java:178)
> at org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent
> (DefaultModelCache.java:65)
> at org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent
> (DefaultModelCache.java:56)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.cache
> (DefaultModelBuilder.java:1654)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.readFileModel
> (DefaultModelBuilder.java:1170)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadFilePom
> (DefaultModelBuilder.java:727)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadFromRoot
> (DefaultModelBuilder.java:705)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.buildBuildPom
> (DefaultModelBuilder.java:652)
> at org.apache.maven.internal.impl.model.DefaultModelBuilder$1.build
> (DefaultModelBuilder.java:227)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.build
> (DefaultProjectBuilder.java:491)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.lambda$doBuild$5
> (DefaultProjectBuilder.java:468)
> at java.util.stream.ReferencePipeline$3$1.accept
> (ReferencePipeline.java:197)
> at java.util.Collections$2.tryAdvance (Collections.java:5073)
> at java.util.Collections$2.forEachRemaining (Collections.java:5081)
> at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:509)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto
> (AbstractPipeline.java:499)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential
> (ReduceOps.java:921)
> at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:682)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.doBuild
> (DefaultProjectBuilder.java:470)
> at org.apache.maven.project.DefaultProjectBuilder$BuildSession.build
> (DefaultProjectBuilder.java:444)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:183)
> at
> org.apache.maven.project.collector.DefaultProjectsSelector.selectProjects
> (DefaultProjectsSelector.java:61)
> at
> org.apache.maven.project.collector.RequestPomCollectionStrategy.collectProjects
> (RequestPomCollectionStrategy.java:49)
> at org
[jira] [Created] (MNG-8295) Dependency Manager Transitivity (now default) handles dependency management inconsistently
Didier Loiseau created MNG-8295:
---
Summary: Dependency Manager Transitivity (now default) handles
dependency management inconsistently
Key: MNG-8295
URL: https://issues.apache.org/jira/browse/MNG-8295
Project: Maven
Issue Type: Bug
Components: API, Core
Affects Versions: 4.0.0-beta-4
Reporter: Didier Loiseau
Attachments: dependency-transitivity-inconsistency.zip
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is a feature request
(that should have been implemented by MNG-7982), I thought it would make more
sense to track this inconsistency as a bug.
The attached [^dependency-transitivity-inconsistency.zip] (copied from
MNG-5761) can be used to show the issue.
I’m running with
{code:java}
$ mvn -v
Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
Java version: 21.0.2, vendor: Oracle Corporation, runtime:
/home/didier/.sdkman/candidates/java/21.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
{code}
First you can see that {{dependent-pom}} manages the version of
{{commons-collections}} to *3.2.2* ({{{}commons-beanutils:1.9.2{}}} depends on
3.2.1):
{code:java}
$ mvn dependency:tree -f dependent-pom.xml
…
[INFO] MNG-5761:dependent:pom:1.0-SNAPSHOT
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO]+- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]\- commons-collections:commons-collections:jar:3.2.2:compile
{code}
Now install {{parent-pom}} and {{{}dependent-pom{}}}, and check the
dependencies of {{{}depending-pom{}}}:
{code:java}
$ mvn install -f parent-pom.xml
$ mvn install -f dependent-pom.xml
$ mvn dependency:tree -f depending-pom.xml
…
[INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO]\- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
{code}
you can see that the {{}} of {{dependent}} is ignored
(like with Maven 3), and we get {{commons-collections}} *3.2.1* instead.
However, if we install {{dependent-pom}} and check the dependencies of
{{{}dependent-pom2{}}}, we get:
{code:java}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
[INFO]\- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.2:compile
{code}
So now we get {{commons-collections}} *3.2.2* again! {{}}
is taken into account at depth 2+ (and 0) but not at depth 1.
This is due to [these 3
lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
in {{{}ClassicDependencyManager{}}}:
{code:java}
@Override
public DependencyManager deriveChildManager(DependencyCollectionContext
context) {
// MNG-4720: Maven2 backward compatibility
// Removing this IF makes one IT fail here (read comment above):
//
https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
if (depth == 1) {
return newInstance(managedVersions, managedScopes,
managedOptionals, managedLocalPaths, managedExclusions);
}
return super.deriveChildManager(context);
}
{code}
I have also created [a PR with integration
tests|https://github.com/apache/maven-integration-testing/pull/379] for
MNG-7982, which shows the issue as well.
I simple fix would be to use the {{TransitiveDependencyManager}} when
{{{}{{{}maven.resolver.dependencyManagerTransitivity{}}}=true{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887413#comment-17887413 ] Didier Loiseau commented on MNG-5761: - I thought this inconsistency would be better tracked as a bug than as part of this feature request, so I created MNG-8295. I think the current behavior of Maven 4.0.0-beta-4 is worse than with Maven 3. [~schulte77], I think if the dependency management transitivity can be implemented in a consistent manner, maybe your work on 3.4 might not have been entirely lost, even if it happens 10 years later 😉 I think it makes sense to have this change in a major release though. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 4.0.x-candidate > > Attachments: MNG-5761.zip, depending-pom2.xml > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887309#comment-17887309 ] Andrey Kuznetsov commented on MNG-4917: --- > the behaviour was there by design from the beginning It was bad design :) > When we talk about a default value, this usually indicates "a value when no > other value was explicitly given". It's true. And the value is the activity, boolean. "The profile is active unless explicitly deactivated". Playing with other profiles should not affect this one. > what's the benefit of having an always active profile ? Say one have "sign" profile. Build artifacts should be signed by default, but there should be a way to disable signing to produce "weaker" build for debug purposes. > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0, 3.8.5 >Reporter: Benson Margulies >Assignee: Guillaume Nodet >Priority: Major > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8290) Bump org.ow2.asm:asm from 9.7 to 9.7.1
[ https://issues.apache.org/jira/browse/MNG-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8290. Fix Version/s: 4.0.0-beta-5 Assignee: Guillaume Nodet Resolution: Fixed > Bump org.ow2.asm:asm from 9.7 to 9.7.1 > -- > > Key: MNG-8290 > URL: https://issues.apache.org/jira/browse/MNG-8290 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > > GitHub Pull Request: https://github.com/apache/maven/pull/1781 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8291) Bump org.junit:junit-bom from 5.11.1 to 5.11.2
Guillaume Nodet created MNG-8291: Summary: Bump org.junit:junit-bom from 5.11.1 to 5.11.2 Key: MNG-8291 URL: https://issues.apache.org/jira/browse/MNG-8291 Project: Maven Issue Type: Task Reporter: Guillaume Nodet GitHub Pull Request: https://github.com/apache/maven/pull/1780 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8291) Bump org.junit:junit-bom from 5.11.1 to 5.11.2
[ https://issues.apache.org/jira/browse/MNG-8291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8291. Fix Version/s: 4.0.0-beta-5 Assignee: Guillaume Nodet Resolution: Fixed > Bump org.junit:junit-bom from 5.11.1 to 5.11.2 > -- > > Key: MNG-8291 > URL: https://issues.apache.org/jira/browse/MNG-8291 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-5 > > > GitHub Pull Request: https://github.com/apache/maven/pull/1780 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8290) Bump org.ow2.asm:asm from 9.7 to 9.7.1
Guillaume Nodet created MNG-8290: Summary: Bump org.ow2.asm:asm from 9.7 to 9.7.1 Key: MNG-8290 URL: https://issues.apache.org/jira/browse/MNG-8290 Project: Maven Issue Type: Task Reporter: Guillaume Nodet GitHub Pull Request: https://github.com/apache/maven/pull/1781 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887276#comment-17887276
]
Konrad Windszus commented on DOXIA-746:
---
As every markup language is semantically different in this regard I would
propose to extend the Sink API's {{comment(String)}} method with an overloaded
{{command(String, boolean)}} where the latter argument determines whether the
comment should be followed by a line separator.
Open Question: Do we need the same for a preceding new line? How would two
comments in two consecutives lines look like then in Sink API?
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Description:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the first
occurrence of substring in string, or -1 if not found.
* {{{}contains(string, substring){}}}: Checks if the string contains the
substring.
* {{{}matches(string, regex){}}}: Checks if the string matches the given
regular expression.
* {{{}not(condition){}}}: Negates the given condition.
* {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
condition is true, falseValue otherwise.
* {{{}exists(path){}}}: Checks if a file matching the given glob pattern
exists.
* {{{}missing(path){}}}: Checks if a file matching the given glob pattern does
not exist.
* {{{}inrange(version, range){}}}: Checks if the given version is within the
specified version range.
h2. Supported properties
The following properties are supported in expressions:
* {{{}project.basedir{}}}: The project directory
* {{{}project.rootDirectory{}}}: The root directory of the project
* {{{}project.artifactId{}}}: The artifactId of the project
* {{{}project.packaging{}}}: The packaging of the project
* user properties
* system properties (including environment variables prefixed with env.)
h2. Examples
* JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
* OS check: {{${os.name} == 'windows'}}
* File existence: {{exists('${project.basedir}/src/**{*}/{*}.xsd')}}
* Property check: {{${my.property} != 'some-value'}}
* Regex matching: {{matches(${os.version}, '.*aws')}}
* Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
inrange(${os.version}, '[10,)')}}
* String length check: {{length(${user.name}) > 5}}
* Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
* Using indexOf: {{indexOf(${java.version}, '-') > 0}}
* Conditional logic: {{if(contains(${java.version}, '{-}'),
substring(${java.version}, 0, indexOf(${java.version}, '{-}')),
${java.version})}}
This flexible condition mechanism allows for more precise control over profile
activation, enabling developers to create profiles that respond to a wide range
of environmental factors and project states.
This will be triggered using a new profile activation in the 4.1.0 model:
{code:xml}
inrange(${maven.version}, '[4,)')
{code}
was:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Description:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the first
occurrence of substring in string, or -1 if not found.
* {{{}contains(string, substring){}}}: Checks if the string contains the
substring.
* {{{}matches(string, regex){}}}: Checks if the string matches the given
regular expression.
* {{{}not(condition){}}}: Negates the given condition.
* {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
condition is true, falseValue otherwise.
* {{{}exists(path){}}}: Checks if a file matching the given glob pattern
exists.
* {{{}missing(path){}}}: Checks if a file matching the given glob pattern does
not exist.
* {{{}inrange(version, range){}}}: Checks if the given version is within the
specified version range.
h2. Supported properties
The following properties are supported in expressions:
* {{{}project.basedir{}}}: The project directory
* {{{}project.rootDirectory{}}}: The root directory of the project
* {{{}project.artifactId{}}}: The artifactId of the project
* {{{}project.packaging{}}}: The packaging of the project
* user properties
* system properties (including environment variables prefixed with env.)
h2. Examples
* JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
* OS check: {{${os.name} == 'windows'}}
* File existence: {{exists('${project.basedir}/src/{*}**{*}/*.xsd')}}
* Property check: {{${my.property} != 'some-value'}}
* Regex matching: {{matches(${os.version}, '.*aws')}}
* Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
inrange(${os.version}, '[10,)')}}
* String length check: {{length(${user.name}) > 5}}
* Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
* Using indexOf: {{indexOf(${java.version}, '-') > 0}}
* Conditional logic: {{if(contains(${java.version}, '-'),
substring(${java.version}, 0, indexOf(${java.version}, '-')), ${java.version})}}
This flexible condition mechanism allows for more precise control over profile
activation, enabling developers to create profiles that respond to a wide range
of environmental factors and project states.
This will be triggered using a new profile activation in the 4.1.0 model:
{code:xml}
inrange(${maven.version}, '[4,)')
{code}
was:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of t
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Description:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the first
occurrence of substring in string, or -1 if not found.
* {{{}contains(string, substring){}}}: Checks if the string contains the
substring.
* {{{}matches(string, regex){}}}: Checks if the string matches the given
regular expression.
* {{{}not(condition){}}}: Negates the given condition.
* {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
condition is true, falseValue otherwise.
* {{{}exists(path){}}}: Checks if a file matching the given glob pattern
exists.
* {{{}missing(path){}}}: Checks if a file matching the given glob pattern does
not exist.
* {{{}inrange(version, range){}}}: Checks if the given version is within the
specified version range.
h2. Supported properties
The following properties are supported in expressions:
* {{{}project.basedir{}}}: The project directory
* {{{}project.rootDirectory{}}}: The root directory of the project
* {{{}project.artifactId{}}}: The artifactId of the project
* {{{}project.packaging{}}}: The packaging of the project
* user properties
* system properties (including environment variables prefixed with env.)
h2. Examples
* JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
* OS check: {{${os.name} == 'windows'}}
* File existence: {{exists('${project.basedir}/src/**/*.xsd')}}
* Property check: {{${my.property} != 'some-value'}}
* Regex matching: {{matches(${os.version}, '.*aws')}}
* Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
inrange(${os.version}, '[10,)')}}
* String length check: {{length(${user.name}) > 5}}
* Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
* Using indexOf: {{indexOf(${java.version}, '-') > 0}}
* Conditional logic: {{if(contains(${java.version}, '{-}'),
substring(${java.version}, 0, indexOf(${java.version}, '{-}')),
${java.version})}}
This flexible condition mechanism allows for more precise control over profile
activation, enabling developers to create profiles that respond to a wide range
of environmental factors and project states.
This will be triggered using a new profile activation in the 4.1.0 model:
{code:xml}
inrange(${maven.version}, '[4,)')
{code}
was:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of th
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Description:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the first
occurrence of substring in string, or -1 if not found.
* {{{}contains(string, substring){}}}: Checks if the string contains the
substring.
* {{{}matches(string, regex){}}}: Checks if the string matches the given
regular expression.
* {{{}not(condition){}}}: Negates the given condition.
* {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
condition is true, falseValue otherwise.
* {{{}exists(path){}}}: Checks if a file matching the given glob pattern
exists.
* {{{}missing(path){}}}: Checks if a file matching the given glob pattern does
not exist.
* {{{}inrange(version, range){}}}: Checks if the given version is within the
specified version range.
h2. Supported properties
The following properties are supported in expressions:
* {{{}project.basedir{}}}: The project directory
* {{{}project.rootDirectory{}}}: The root directory of the project
* {{{}project.artifactId{}}}: The artifactId of the project
* {{{}project.packaging{}}}: The packaging of the project
* user properties
* system properties (including environment variables prefixed with env.)
h2. Examples
* JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
* OS check: {{${os.name} == 'windows'}}
* File existence: {{exists('${project.basedir}/src/** /*.xsd')}}
* Property check: {{${my.property} != 'some-value'}}
* Regex matching: {{matches(${os.version}, '.*aws')}}
* Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
inrange(${os.version}, '[10,)')}}
* String length check: {{length(${user.name}) > 5}}
* Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
* Using indexOf: {{indexOf(${java.version}, '-') > 0}}
* Conditional logic: {{if(contains(${java.version}, '-'),
substring(${java.version}, 0, indexOf(${java.version}, '-')), ${java.version})}}
This flexible condition mechanism allows for more precise control over profile
activation, enabling developers to create profiles that respond to a wide range
of environmental factors and project states.
This will be triggered using a new profile activation in the 4.1.0 model:
{code:xml}
inrange(${maven.version}, '[4,)')
{code}
was:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the fi
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Description:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of the first
occurrence of substring in string, or -1 if not found.
* {{{}contains(string, substring){}}}: Checks if the string contains the
substring.
* {{{}matches(string, regex){}}}: Checks if the string matches the given
regular expression.
* {{{}not(condition){}}}: Negates the given condition.
* {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
condition is true, falseValue otherwise.
* {{{}exists(path){}}}: Checks if a file matching the given glob pattern
exists.
* {{{}missing(path){}}}: Checks if a file matching the given glob pattern does
not exist.
* {{{}inrange(version, range){}}}: Checks if the given version is within the
specified version range.
h2. Supported properties
The following properties are supported in expressions:
* {{{}project.basedir{}}}: The project directory
* {{{}project.rootDirectory{}}}: The root directory of the project
* {{{}project.artifactId{}}}: The artifactId of the project
* {{{}project.packaging{}}}: The packaging of the project
* user properties
* system properties (including environment variables prefixed with env.)
h2. Examples
* JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
* OS check: {{${os.name} == 'windows'}}
* File existence: {{exists('${project.basedir}/src/** /*.xsd')}}
* Property check: {{${my.property} != 'some-value'}}
* Regex matching: {{matches(${os.version}, '.*aws')}}
* Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
inrange(${os.version}, '[10,)')}}
* String length check: {{length(${user.name}) > 5}}
* Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
* Using indexOf: {{indexOf(${java.version}, '-') > 0}}
* Conditional logic: {{if(contains(${java.version}, '{-}'),
substring(${java.version}, 0, indexOf(${java.version}, '{-}')),
${java.version})}}
This flexible condition mechanism allows for more precise control over profile
activation, enabling developers to create profiles that respond to a wide range
of environmental factors and project states.
This will be triggered using a new profile activation in the 4.1.0 model:
{code:xml}
inrange(${maven.version}, '[4,)')
{code}
was:
GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
h1. Condition-Based Profile Activation in Maven
In addition to the traditional activation mechanisms (JDK version, OS
properties, file existence, etc.), Maven now supports a powerful
condition-based activation through the condition field. This new mechanism
allows for more flexible and expressive profile activation rules.
h2. Condition Syntax
The condition is specified as a string expression that can include various
functions, comparisons, and logical operators.
Some key features include:
Property access: {{{}$\{property.name{
Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}}, {{{}<={}}},
{{>=}}
Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
{{{}inrange(...){}}}, and more
h2. Supported Functions
The following functions are supported in condition expressions:
* {{{}length(string){}}}: Returns the length of the given string.
* {{{}upper(string){}}}: Converts the string to uppercase.
* {{{}lower(string){}}}: Converts the string to lowercase.
* {{{}substring(string, start, [end]){}}}: Returns a substring of the given
string.
* {{{}indexOf(string, substring){}}}: Returns the index of t
[jira] [Comment Edited] (MNG-4917) Profile not active even though it has activeByDefault set to true
[
https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887263#comment-17887263
]
Guillaume Nodet edited comment on MNG-4917 at 10/7/24 7:00 AM:
---
Actually, that would lead to yet another set of boolean options which are
mutually exclusive. So a better way may be to define
{code}
inactive | active | if-no-other
{code}
Anyway, one question that comes to my mind is: what's the benefit of having an
always active profile ? Why not injecting the content of the profile directly
in the project ? I suppose the lack of clear use case was the reason why
there's no immediate way to make a profile always active.
was (Author: gnt):
Actually, that would lead to yet another set of boolean options which are
mutually exclusive. So a better way may be to define
{code}
inactive | active | if-no-other
{code}
Anyway, one question that comes to my mind is: what's the benefit of having an
always active profile ? Why not injecting the content of the profile directly
in the project ?
> Profile not active even though it has activeByDefault set to true
> -
>
> Key: MNG-4917
> URL: https://issues.apache.org/jira/browse/MNG-4917
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.0, 3.8.5
>Reporter: Benson Margulies
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: pom.xml
>
>
> I've got a parent pom with a profile with
> true.
> You can retrieve it for yourself via git clone
> git://git.apache.org/webservices-xmlschema.git.
> The problem is the sourcecheck profile in the parent pom.
> running mvn -Psourcecheck works as expected, but running without the -P fails
> to activate the profile.
> the help plugin, I think, has separate problems in this area, or perhaps it's
> not supposed to look at -P?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-681) [REGRESSION] Output from archetype verification is no longer logged
[
https://issues.apache.org/jira/browse/ARCHETYPE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887287#comment-17887287
]
Wolfgang Knauf commented on ARCHETYPE-681:
--
Thanks for fixing this issue!
[~sjaranowski] I am blocked by
https://issues.apache.org/jira/browse/ARCHETYPE-649 (seems to be a false
warning)
> [REGRESSION] Output from archetype verification is no longer logged
> ---
>
> Key: ARCHETYPE-681
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-681
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Wolfgang Knauf
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.3.1
>
>
> When build an archetype project, there is a step the generates a sample
> project from the archetype.
>
> With 3.1.2, the maven output to create and build a sample project from the
> archetype was logged (see duplicated "[INFO] [INFO]" lines):
>
> {{[INFO] Project created from Archetype in dir:
> C:\Temp\github\wildfly-archetypes\wildfly-jakartaee-webapp-archetype\target\test-classes\projects\multi\project\multi}}
> {{[INFO] Invoking post-archetype-generation goals: verify}}
> {{[INFO] [INFO] Error stacktraces are turned on.}}
> {{[INFO] [INFO] Scanning for projects...}}
> {{[INFO] [INFO]}}
> {{[INFO] [INFO] -{-}{{-}}< foo.bar:multi
> >{{-}}{-}--}}
> {{[INFO] [INFO] Building multi 0.0.1-SNAPSHOT}}
> {{[INFO] [INFO] from pom.xml}}
> {{...}}
>
> With 3.3.0, there is just this output:
> {{[INFO] Project created from Archetype in dir:
> C:\Temp\github\wildfly-archetypes\wildfly-jakartaee-webapp-archetype\target\test-classes\projects\multi\project\multi}}
> {{[INFO] Invoking post-archetype-generation goals: verify}}
> {{[INFO] Post-archetype-generation invoker exit code: 0}}
> {{...}}
>
> This is not good, as building the sample project might take a long time, or
> might even fail, and you don't see a reason for the long delay after the line
> "Invoking post-archetype-generation goals: verify" is printed. I had also a
> situation where creating and building the sample project failed, and here not
> details about the error were logged.
> Could you bring back the old behavior to log the INFO output?
>
> To reproduce: you could pull the wildfly archetypes:
> [https://github.com/wildfly/wildfly-archetypes]
> At the end of the root pom.xml, change the archetype version to "3.3.0" - we
> are currently stuck with 3.1.2 due to another issue.
> Then build one of the archetype modules (invoke it in the root directory -
> building all archetypes will not work, as one has additional requirements):
> {{mvn -pl wildfly-jakartaee-webapp-archetype clean install}}
>
> Or is there a configuration option to enable logging again?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8292) Rework profile activation
[
https://issues.apache.org/jira/browse/MNG-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8292:
-
Description:
Profile activation needs to be reworked.
I propose to deprecate the full {{}} element and replace it with a
single {{ ... }} element which would contain an
expression as described in MNG-8286. The only missing bit is the
{{activeByDefault}} feature which may need a few additional functions such as
{{active(profile-id)}} and {{{}inactive(profile-id){}}}.
A few points to keep in mind:
* project properties are used in a non coherent way now, this needs to be
cleaned up. There are use cases to leverage those properties during profile
activation, but we need to ensure that the early activated profile (computed on
the file model to get the list of subprojects) are stable. One way would be to
make sure that the list of subprojects does not change between the activated
file model and the effective model, either by checking that the resulting lists
are the same, or by actually doing it in two steps: a first activation would
inject the subprojects into the file model and a later step would compute the
effective model, ignoring the subprojects
* ultimately, the profile activation interpolation step should go away, as
properties can be interpolated on the fly during the expression evaluation (and
I would not go into interpreting the value of a property as an expression
recursively)
* for cascading profiles, my initial idea was that a profile can never be
deactivated once activated. So to compute the list of profiles, you start from
a complete list, find out which ones are activated, remove them from the list
and incorporate the properties into the context, and loop. This ensures we
can't run into infinite loops where a profile is activated, then deactivate...,
then activated, etc...
was:
Profile activation needs to be reworked.
I propose to deprecate the full {{}} element and replace it with a
single \{{ ... }} element which would contain an
expression as described in MNG-8286. The only missing bit is the
\{{activeByDefault}} feature which may need a few additional functions such as
\{{active(profile-id)}} and \{{inactive(profile-id)}}.
> Rework profile activation
> -
>
> Key: MNG-8292
> URL: https://issues.apache.org/jira/browse/MNG-8292
> Project: Maven
> Issue Type: Task
> Components: Profiles
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.1.0
>
>
> Profile activation needs to be reworked.
> I propose to deprecate the full {{}} element and replace it with
> a single {{ ... }} element which would contain an
> expression as described in MNG-8286. The only missing bit is the
> {{activeByDefault}} feature which may need a few additional functions such as
> {{active(profile-id)}} and {{{}inactive(profile-id){}}}.
> A few points to keep in mind:
> * project properties are used in a non coherent way now, this needs to be
> cleaned up. There are use cases to leverage those properties during profile
> activation, but we need to ensure that the early activated profile (computed
> on the file model to get the list of subprojects) are stable. One way would
> be to make sure that the list of subprojects does not change between the
> activated file model and the effective model, either by checking that the
> resulting lists are the same, or by actually doing it in two steps: a first
> activation would inject the subprojects into the file model and a later step
> would compute the effective model, ignoring the subprojects
> * ultimately, the profile activation interpolation step should go away, as
> properties can be interpolated on the fly during the expression evaluation
> (and I would not go into interpreting the value of a property as an
> expression recursively)
> * for cascading profiles, my initial idea was that a profile can never be
> deactivated once activated. So to compute the list of profiles, you start
> from a complete list, find out which ones are activated, remove them from the
> list and incorporate the properties into the context, and loop. This ensures
> we can't run into infinite loops where a profile is activated, then
> deactivate..., then activated, etc...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8292) Rework profile activation
[
https://issues.apache.org/jira/browse/MNG-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8292:
-
Description:
Profile activation needs to be reworked.
I propose to deprecate the full {{}} element and replace it with a
single \{{ ... }} element which would contain an
expression as described in MNG-8286. The only missing bit is the
\{{activeByDefault}} feature which may need a few additional functions such as
\{{active(profile-id)}} and \{{inactive(profile-id)}}.
> Rework profile activation
> -
>
> Key: MNG-8292
> URL: https://issues.apache.org/jira/browse/MNG-8292
> Project: Maven
> Issue Type: Task
> Components: Profiles
>Reporter: Guillaume Nodet
>Priority: Major
> Fix For: 4.1.0
>
>
> Profile activation needs to be reworked.
> I propose to deprecate the full {{}} element and replace it with
> a single \{{ ... }} element which would contain an
> expression as described in MNG-8286. The only missing bit is the
> \{{activeByDefault}} feature which may need a few additional functions such
> as \{{active(profile-id)}} and \{{inactive(profile-id)}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-3309) Cascading profile activation
[
https://issues.apache.org/jira/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-3309:
-
Fix Version/s: 4.1.0
(was: 4.0.0-beta-5)
> Cascading profile activation
>
>
> Key: MNG-3309
> URL: https://issues.apache.org/jira/browse/MNG-3309
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Affects Versions: 2.0.7
>Reporter: Andreas Höhmann
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: needs-discussion
> Fix For: 4.1.0
>
>
> I want include profiles from profiles ... a example ... please tell me if
> this is nonsense :-)
> {code:xml}
>
>
>
> default
>
> true
>
>
>
> 6
>
> myfaces12
>
> true
>
> false
>
>
>
>
> seam
>
> false
>
> seam
> true
>
>
> ...
>
>
>
> richfaces
>
> false
>
> richfaces
> true
>
>
> ...
>
>
>
> myfaces12
>
> false
>
> jsf
> myfaces12
>
>
> ...
>
>
>
> myfaces11
>
> false
>
> jsf
> myfaces11
>
>
> ...
>
>
>
> jsfri12
>
> false
>
> jsf
> ri12
>
>
>
>
>
>
> tomcat5
>
> false
>
> tomcat
> 5
>
>
>
> jetty:run
>
>
>
> javax.servlet
> servlet-api
> 2.4
> provided
>
>
> javax.servlet.jsp
> jsp-api
> 2.0
> provided
>
>
> javax.el
> el-api
> 1.0
>
>
> el-impl
> el-impl
> 1.0
>
>
>
>
>
> tomcat6
>
> false
>
> tomcat
> 6
>
>
>
> jetty:run
>
>
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
>
> javax.servlet.jsp
> jsp-api
> 2.1
> provided
>
>
> javax.el
> el-api
> 1.0
> provided
>
>
> el-impl
> el-impl
> 1.0
> provided
>
>
>
> ...
> {code}
> {noformat}
> 'mvn -Pdefault eclipse:eclipse' should create a tomcat6, myfaces12,
> richfaces project
> 'mvn -Pdevel eclipse:eclipse' should create a tomcat5, myfaces12, richfaces
> project
> 'mvn -Pproductiv eclipse:eclipse' should create a jboss, myfaces12,
> richfaces project
>
> {noformat}
> any ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-3309) Cascading profile activation
[
https://issues.apache.org/jira/browse/MNG-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-3309:
-
Parent: MNG-8292
Issue Type: Sub-task (was: New Feature)
> Cascading profile activation
>
>
> Key: MNG-3309
> URL: https://issues.apache.org/jira/browse/MNG-3309
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Affects Versions: 2.0.7
>Reporter: Andreas Höhmann
>Assignee: Guillaume Nodet
>Priority: Major
> Labels: needs-discussion
> Fix For: 4.0.0-beta-5
>
>
> I want include profiles from profiles ... a example ... please tell me if
> this is nonsense :-)
> {code:xml}
>
>
>
> default
>
> true
>
>
>
> 6
>
> myfaces12
>
> true
>
> false
>
>
>
>
> seam
>
> false
>
> seam
> true
>
>
> ...
>
>
>
> richfaces
>
> false
>
> richfaces
> true
>
>
> ...
>
>
>
> myfaces12
>
> false
>
> jsf
> myfaces12
>
>
> ...
>
>
>
> myfaces11
>
> false
>
> jsf
> myfaces11
>
>
> ...
>
>
>
> jsfri12
>
> false
>
> jsf
> ri12
>
>
>
>
>
>
> tomcat5
>
> false
>
> tomcat
> 5
>
>
>
> jetty:run
>
>
>
> javax.servlet
> servlet-api
> 2.4
> provided
>
>
> javax.servlet.jsp
> jsp-api
> 2.0
> provided
>
>
> javax.el
> el-api
> 1.0
>
>
> el-impl
> el-impl
> 1.0
>
>
>
>
>
> tomcat6
>
> false
>
> tomcat
> 6
>
>
>
> jetty:run
>
>
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
>
> javax.servlet.jsp
> jsp-api
> 2.1
> provided
>
>
> javax.el
> el-api
> 1.0
> provided
>
>
> el-impl
> el-impl
> 1.0
> provided
>
>
>
> ...
> {code}
> {noformat}
> 'mvn -Pdefault eclipse:eclipse' should create a tomcat6, myfaces12,
> richfaces project
> 'mvn -Pdevel eclipse:eclipse' should create a tomcat5, myfaces12, richfaces
> project
> 'mvn -Pproductiv eclipse:eclipse' should create a jboss, myfaces12,
> richfaces project
>
> {noformat}
> any ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Parent: MNG-8292
Issue Type: Sub-task (was: New Feature)
> Add a condition profile based on a simple expressions
> -
>
> Key: MNG-8286
> URL: https://issues.apache.org/jira/browse/MNG-8286
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
> h1. Condition-Based Profile Activation in Maven
> In addition to the traditional activation mechanisms (JDK version, OS
> properties, file existence, etc.), Maven now supports a powerful
> condition-based activation through the condition field. This new mechanism
> allows for more flexible and expressive profile activation rules.
> h2. Condition Syntax
> The condition is specified as a string expression that can include various
> functions, comparisons, and logical operators.
> Some key features include:
> Property access: {{{}$\{property.name{
> Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}},
> {{{}<={}}}, {{>=}}
> Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
> Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
> {{{}inrange(...){}}}, and more
> h2. Supported Functions
> The following functions are supported in condition expressions:
> * {{{}length(string){}}}: Returns the length of the given string.
> * {{{}upper(string){}}}: Converts the string to uppercase.
> * {{{}lower(string){}}}: Converts the string to lowercase.
> * {{{}substring(string, start, [end]){}}}: Returns a substring of the given
> string.
> * {{{}indexOf(string, substring){}}}: Returns the index of the first
> occurrence of substring in string, or -1 if not found.
> * {{{}contains(string, substring){}}}: Checks if the string contains the
> substring.
> * {{{}matches(string, regex){}}}: Checks if the string matches the given
> regular expression.
> * {{{}not(condition){}}}: Negates the given condition.
> * {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
> condition is true, falseValue otherwise.
> * {{{}exists(path){}}}: Checks if a file matching the given glob pattern
> exists.
> * {{{}missing(path){}}}: Checks if a file matching the given glob pattern
> does not exist.
> * {{{}inrange(version, range){}}}: Checks if the given version is within the
> specified version range.
> h2. Supported properties
> The following properties are supported in expressions:
> * {{{}project.basedir{}}}: The project directory
> * {{{}project.rootDirectory{}}}: The root directory of the project
> * {{{}project.artifactId{}}}: The artifactId of the project
> * {{{}project.packaging{}}}: The packaging of the project
> * user properties
> * system properties (including environment variables prefixed with env.)
> h2. Examples
> * JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
> * OS check: {{${os.name} == 'windows'}}
> * File existence: {{exists('${project.basedir}/src/** /*.xsd')}}
> * Property check: {{${my.property} != 'some-value'}}
> * Regex matching: {{matches(${os.version}, '.*aws')}}
> * Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
> inrange(${os.version}, '[10,)')}}
> * String length check: {{length(${user.name}) > 5}}
> * Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
> * Using indexOf: {{indexOf(${java.version}, '-') > 0}}
> * Conditional logic: {{if(contains(${java.version}, '-'),
> substring(${java.version}, 0, indexOf(${java.version}, '-')),
> ${java.version})}}
> This flexible condition mechanism allows for more precise control over
> profile activation, enabling developers to create profiles that respond to a
> wide range of environmental factors and project states.
> This will be triggered using a new profile activation in the 4.1.0 model:
> {code:xml}
>
>
> inrange(${maven.version}, '[4,)')
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8292) Rework profile activation
Guillaume Nodet created MNG-8292: Summary: Rework profile activation Key: MNG-8292 URL: https://issues.apache.org/jira/browse/MNG-8292 Project: Maven Issue Type: Task Components: Profiles Reporter: Guillaume Nodet Fix For: 4.1.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887327#comment-17887327
]
Guillaume Nodet commented on DOXIASITETOOLS-343:
The problem isn't really in DoxiaTools, which uses the MavenProject being
injected by Maven into the mojo. The problem is more related to
maven-project-info-reports-plugin which uses the {{ProjectBuilder}} instead of
{{{}ModelBuilder{}}}.
> Rewrite DefaultSiteTools project management
> ---
>
> Key: DOXIASITETOOLS-343
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The code loads MavenProject from local repositories and uses
> {{project.getBasedir() == null}} to check if the project was loaded from the
> local repository or if it is a real project.
> This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
> model from the local repository, one should use {{ModelBuilder}} and only use
> {{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-343) Rewrite DefaultSiteTools project management
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887328#comment-17887328
]
Guillaume Nodet commented on DOXIASITETOOLS-343:
However, this would be a major refactoring and should be done either as part of
[https://issues.apache.org/jira/projects/MPIR/issues/MPIR-458] or even as part
of migrating to Maven 4 API.
> Rewrite DefaultSiteTools project management
> ---
>
> Key: DOXIASITETOOLS-343
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-343
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The code loads MavenProject from local repositories and uses
> {{project.getBasedir() == null}} to check if the project was loaded from the
> local repository or if it is a real project.
> This is wrong imho (and was broken in 4.0.0-alpha-8 to beta-3). To load a
> model from the local repository, one should use {{ModelBuilder}} and only use
> {{ProjectBuilder}} to load projects which are _real_ projects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8294) Add a consistency check when loading parent
[
https://issues.apache.org/jira/browse/MNG-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8294:
Assignee: Guillaume Nodet
> Add a consistency check when loading parent
> ---
>
> Key: MNG-8294
> URL: https://issues.apache.org/jira/browse/MNG-8294
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> MNG-2196 provides an IT which was failing, but for the wrong reason. With
> the addition of GAV inference in Maven 4, we need to revisit this bit to:
> * move the default parent \{{relativePath}} \{{..}} as a default value when
> loading the parent, rather than as a default value in the model
> * this will allow checking consistency between the provided value (if
> there's one) and the loaded model and fail if not equals
> In short, if the parent {{relativePath}} is provided, it should be correct,
> else Maven 4 can find it automatically in the reactor, else load it from
> repository. In the first case, we need to verify the correct GAV.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887385#comment-17887385
]
Michael Osipov commented on DOXIA-747:
--
OK, then this makes sense. A documented {{IllegalStateException}} would be
imperative.
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}/
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887386#comment-17887386
]
Michael Osipov commented on DOXIA-746:
--
Shouldn't the MarkdownSink behave differently to the HTML5Sink?
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8286) Add a condition profile based on a simple expressions
[
https://issues.apache.org/jira/browse/MNG-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8286:
-
Fix Version/s: 4.1.0
(was: 4.0.0-beta-5)
> Add a condition profile based on a simple expressions
> -
>
> Key: MNG-8286
> URL: https://issues.apache.org/jira/browse/MNG-8286
> Project: Maven
> Issue Type: Sub-task
> Components: Profiles
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.1.0
>
>
> GitHub Pull Request: [https://github.com/apache/maven/pull/1771]
> h1. Condition-Based Profile Activation in Maven
> In addition to the traditional activation mechanisms (JDK version, OS
> properties, file existence, etc.), Maven now supports a powerful
> condition-based activation through the condition field. This new mechanism
> allows for more flexible and expressive profile activation rules.
> h2. Condition Syntax
> The condition is specified as a string expression that can include various
> functions, comparisons, and logical operators.
> Some key features include:
> Property access: {{{}$\{property.name{
> Comparison operators: {{{}=={}}}, {{{}!={}}}, {{{}<{}}}, {{{}>{}}},
> {{{}<={}}}, {{>=}}
> Logical operators: {{&&}} (AND), {{||}} (OR), {{not(...)}}
> Functions: {{{}exists(...){}}}, {{{}missing(...){}}}, {{{}matches(...){}}},
> {{{}inrange(...){}}}, and more
> h2. Supported Functions
> The following functions are supported in condition expressions:
> * {{{}length(string){}}}: Returns the length of the given string.
> * {{{}upper(string){}}}: Converts the string to uppercase.
> * {{{}lower(string){}}}: Converts the string to lowercase.
> * {{{}substring(string, start, [end]){}}}: Returns a substring of the given
> string.
> * {{{}indexOf(string, substring){}}}: Returns the index of the first
> occurrence of substring in string, or -1 if not found.
> * {{{}contains(string, substring){}}}: Checks if the string contains the
> substring.
> * {{{}matches(string, regex){}}}: Checks if the string matches the given
> regular expression.
> * {{{}not(condition){}}}: Negates the given condition.
> * {{{}if(condition, trueValue, falseValue){}}}: Returns trueValue if the
> condition is true, falseValue otherwise.
> * {{{}exists(path){}}}: Checks if a file matching the given glob pattern
> exists.
> * {{{}missing(path){}}}: Checks if a file matching the given glob pattern
> does not exist.
> * {{{}inrange(version, range){}}}: Checks if the given version is within the
> specified version range.
> h2. Supported properties
> The following properties are supported in expressions:
> * {{{}project.basedir{}}}: The project directory
> * {{{}project.rootDirectory{}}}: The root directory of the project
> * {{{}project.artifactId{}}}: The artifactId of the project
> * {{{}project.packaging{}}}: The packaging of the project
> * user properties
> * system properties (including environment variables prefixed with env.)
> h2. Examples
> * JDK version range: {{inrange(${java.version}, '[11,)')}} (JDK 11 or higher)
> * OS check: {{${os.name} == 'windows'}}
> * File existence: {{exists('${project.basedir}/src/** /*.xsd')}}
> * Property check: {{${my.property} != 'some-value'}}
> * Regex matching: {{matches(${os.version}, '.*aws')}}
> * Complex condition: {{${os.name} == 'windows' && ${os.arch} != 'amd64' &&
> inrange(${os.version}, '[10,)')}}
> * String length check: {{length(${user.name}) > 5}}
> * Substring with version: {{substring(${java.version}, 0, 3) == '1.8'}}
> * Using indexOf: {{indexOf(${java.version}, '-') > 0}}
> * Conditional logic: {{if(contains(${java.version}, '-'),
> substring(${java.version}, 0, indexOf(${java.version}, '-')),
> ${java.version})}}
> This flexible condition mechanism allows for more precise control over
> profile activation, enabling developers to create profiles that respond to a
> wide range of environmental factors and project states.
> This will be triggered using a new profile activation in the 4.1.0 model:
> {code:xml}
>
>
> inrange(${maven.version}, '[4,)')
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[ https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887321#comment-17887321 ] Alexander Kriegisch commented on MNG-4917: -- [~gnodet], feel free to not understand my semantic concern. After 14 years, I didn't have much hope that anyone would ever take it seriously anyway. Thanks for considering to enhance the documentation and for your feedback. > Profile not active even though it has activeByDefault set to true > - > > Key: MNG-4917 > URL: https://issues.apache.org/jira/browse/MNG-4917 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 3.0, 3.8.5 >Reporter: Benson Margulies >Assignee: Guillaume Nodet >Priority: Major > Attachments: pom.xml > > > I've got a parent pom with a profile with > true. > You can retrieve it for yourself via git clone > git://git.apache.org/webservices-xmlschema.git. > The problem is the sourcecheck profile in the parent pom. > running mvn -Psourcecheck works as expected, but running without the -P fails > to activate the profile. > the help plugin, I think, has separate problems in this area, or perhaps it's > not supposed to look at -P? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8293) Maven4 lost ability to import BOM from within reactor
Tamas Cservenak created MNG-8293:
Summary: Maven4 lost ability to import BOM from within reactor
Key: MNG-8293
URL: https://issues.apache.org/jira/browse/MNG-8293
Project: Maven
Issue Type: Bug
Components: Core
Reporter: Tamas Cservenak
Fix For: 4.0.0, 4.0.0-beta-5
If project has a BOM import of a BOM that is member of same reactor, build
fails.
The BOM is attempted to be resolved from remote repositories.
{noformat}
[cstamas@angeleyes maven-mvnd (mvnd-cling *)]$ cd
integration-tests/target/mvnd-tests/NewManagedModuleTest/project/parent/
[cstamas@angeleyes parent (mvnd-cling *)]$ ll
total 4
drwxr-xr-x. 1 cstamas cstamas 14 Oct 7 14:56 bom
drwxr-xr-x. 1 cstamas cstamas 20 Oct 7 14:56 module
-rw-r--r--. 1 cstamas cstamas 3170 Oct 7 14:56 pom.xml
[cstamas@angeleyes parent (mvnd-cling *)]$
~/Tools/maven/apache-maven-4.0.0-beta-5-SNAPSHOT/bin/mvn validate
[INFO] Scanning for projects...
[ERROR] Internal error:
org.apache.maven.api.services.model.ModelResolverException: Unable to resolve
artifact: The following artifacts could not be resolved:
org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
(absent) (remote repositories: central (https://repo.maven.apache.org/maven2/,
default, releases)) -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
org.apache.maven.api.services.model.ModelResolverException: Unable to resolve
artifact: The following artifacts could not be resolved:
org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
(absent) (remote repositories: central (https://repo.maven.apache.org/maven2/,
default, releases))
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:157)
at
org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.doExecute(DefaultMavenInvoker.java:449)
at
org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute(DefaultMavenInvoker.java:104)
at
org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute(DefaultMavenInvoker.java:72)
at
org.apache.maven.cling.invoker.LookupInvoker.doInvoke(LookupInvoker.java:202)
at
org.apache.maven.cling.invoker.LookupInvoker.invoke(LookupInvoker.java:177)
at org.apache.maven.cling.ClingSupport.run(ClingSupport.java:71)
at org.apache.maven.cling.MavenCling.main(MavenCling.java:51)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke(Method.java:580)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
Caused by: org.apache.maven.api.services.model.ModelResolverException: Unable
to resolve artifact: The following artifacts could not be resolved:
org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
(absent) (remote repositories: central (https://repo.maven.apache.org/maven2/,
default, releases))
at
org.apache.maven.internal.impl.resolver.DefaultModelResolver.resolveModel(DefaultModelResolver.java:152)
at
org.apache.maven.internal.impl.resolver.DefaultModelResolver.resolveModel(DefaultModelResolver.java:85)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.doLoadDependencyManagement(DefaultModelBuilder.java:1580)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.lambda$loadDependencyManagement$10(DefaultModelBuilder.java:1548)
at
org.apache.maven.internal.impl.model.DefaultModelCache$CachingSupplier.get(DefaultModelCache.java:178)
at
org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent(DefaultModelCache.java:65)
at
org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent(DefaultModelCache.java:50)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.cache(DefaultModelBuilder.java:1653)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadDependencyManagement(DefaultModelBuilder.java:1543)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.importDependencyManagement(DefaultModelBuilder.java:1478)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.buildEffectiveModel(DefaultModelBuilder.java:821)
at
org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.lambda$buildBuildPom$7(DefaultModelBuilder.java:668)
at
org.apache.maven.internal.impl.util.PhasingExecutor.lambda$execute$0(PhasingExecutor.java:80)
at
java.util
[jira] [Closed] (MNG-8293) Maven4 lost ability to import BOM from within reactor
[
https://issues.apache.org/jira/browse/MNG-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-8293.
Assignee: Guillaume Nodet
Resolution: Fixed
> Maven4 lost ability to import BOM from within reactor
> -
>
> Key: MNG-8293
> URL: https://issues.apache.org/jira/browse/MNG-8293
> Project: Maven
> Issue Type: Bug
> Components: Core
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-5
>
>
> If project has a BOM import of a BOM that is member of same reactor, build
> fails.
> The BOM is attempted to be resolved from remote repositories.
> {noformat}
> [cstamas@angeleyes maven-mvnd (mvnd-cling *)]$ cd
> integration-tests/target/mvnd-tests/NewManagedModuleTest/project/parent/
> [cstamas@angeleyes parent (mvnd-cling *)]$ ll
> total 4
> drwxr-xr-x. 1 cstamas cstamas 14 Oct 7 14:56 bom
> drwxr-xr-x. 1 cstamas cstamas 20 Oct 7 14:56 module
> -rw-r--r--. 1 cstamas cstamas 3170 Oct 7 14:56 pom.xml
> [cstamas@angeleyes parent (mvnd-cling *)]$
> ~/Tools/maven/apache-maven-4.0.0-beta-5-SNAPSHOT/bin/mvn validate
> [INFO] Scanning for projects...
> [ERROR] Internal error:
> org.apache.maven.api.services.model.ModelResolverException: Unable to resolve
> artifact: The following artifacts could not be resolved:
> org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
> (absent) (remote repositories: central
> (https://repo.maven.apache.org/maven2/, default, releases)) -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> org.apache.maven.api.services.model.ModelResolverException: Unable to resolve
> artifact: The following artifacts could not be resolved:
> org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
> (absent) (remote repositories: central
> (https://repo.maven.apache.org/maven2/, default, releases))
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:157)
> at
> org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.doExecute(DefaultMavenInvoker.java:449)
> at
> org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute(DefaultMavenInvoker.java:104)
> at
> org.apache.maven.cling.invoker.mvn.DefaultMavenInvoker.execute(DefaultMavenInvoker.java:72)
> at
> org.apache.maven.cling.invoker.LookupInvoker.doInvoke(LookupInvoker.java:202)
> at
> org.apache.maven.cling.invoker.LookupInvoker.invoke(LookupInvoker.java:177)
> at org.apache.maven.cling.ClingSupport.run(ClingSupport.java:71)
> at org.apache.maven.cling.MavenCling.main(MavenCling.java:51)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:255)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:201)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:361)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
> Caused by: org.apache.maven.api.services.model.ModelResolverException: Unable
> to resolve artifact: The following artifacts could not be resolved:
> org.mvndaemon.mvnd.test.new-managed-module:new-managed-module-bom:pom:0.0.1-SNAPSHOT
> (absent) (remote repositories: central
> (https://repo.maven.apache.org/maven2/, default, releases))
> at
> org.apache.maven.internal.impl.resolver.DefaultModelResolver.resolveModel(DefaultModelResolver.java:152)
> at
> org.apache.maven.internal.impl.resolver.DefaultModelResolver.resolveModel(DefaultModelResolver.java:85)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.doLoadDependencyManagement(DefaultModelBuilder.java:1580)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.lambda$loadDependencyManagement$10(DefaultModelBuilder.java:1548)
> at
> org.apache.maven.internal.impl.model.DefaultModelCache$CachingSupplier.get(DefaultModelCache.java:178)
> at
> org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent(DefaultModelCache.java:65)
> at
> org.apache.maven.internal.impl.model.DefaultModelCache.computeIfAbsent(DefaultModelCache.java:50)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.cache(DefaultModelBuilder.java:1653)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.loadDependencyManagement(DefaultModelBuilder.java:1543)
> at
> org.apache.maven.internal.impl.model.DefaultModelBuilder$DefaultModelBuilderSession.importDependencyManagem
[jira] [Updated] (MNG-8222) Provide more information to PropertyContributors
[ https://issues.apache.org/jira/browse/MNG-8222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated MNG-8222: - Fix Version/s: 4.0.0-beta-6 (was: 4.0.0-beta-5) > Provide more information to PropertyContributors > > > Key: MNG-8222 > URL: https://issues.apache.org/jira/browse/MNG-8222 > Project: Maven > Issue Type: Improvement > Components: API >Affects Versions: 4.0.0-beta-3 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-6 > > > The property contributor lacks a lot of "contextual" data. It would be better > if it could: > * inspect "so far discovered user properties" -- this is OK, they are in the > passed in map > * inspect "maven discovered Java System Properties" -- to not touch > System.getProperty method > * inspect maybe things like topDirectory, cwd etc? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-5668) post- should always be executed after
[
https://issues.apache.org/jira/browse/MNG-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-5668:
-
Fix Version/s: 4.0.0-beta-6
(was: 4.0.0-beta-5)
> post- should always be executed after
>
>
> Key: MNG-5668
> URL: https://issues.apache.org/jira/browse/MNG-5668
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 4.0.0-beta-6
>
>
> Original proposal:
> {quote}
> There are right now 3 phases which also have a pre- and post-,
> namely integration-test, clean and site. However, even if one has bound goals
> to the post-phases, they're probably never called.
> When there's an integration-test starting up some server, you'd probably
> always want to kill it no matter what happens during the IT (let say a NPE).
> The proposal is to execute the post- as the finally block in Java. If
> you really want to execute only the integration-test without the post, the
> phase should be marked, e.g. 'mvn [integration-test]', where the brackets
> lock the phase.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887379#comment-17887379
]
Konrad Windszus commented on DOXIA-746:
---
I am talking about APTParser and MarkdownSink/Html5Sink. Since comments in
general are inline in HTML5 I don't expect the sink to always add line
delimiters, otherwise stuff like
{code}
headline
{code}
would no longer be possible to emit with the Html5Sink.
I don't see any need to restrict in line comments in HTML/Markdown!
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887379#comment-17887379
]
Konrad Windszus edited comment on DOXIA-746 at 10/7/24 3:49 PM:
I am talking about APTParser and MarkdownSink/Html5Sink. Since comments in
general are inline in HTML5 I don't expect the sink to always add line
delimiters, otherwise stuff like
{code}
headline
{code}
would no longer be possible to emit with the Html5Sink.
I don't see any need to restrict in line comments in HTML/Markdown!
was (Author: kwin):
I am talking about APTParser and MarkdownSink/Html5Sink. Since comments in
general are inline in HTML5 I don't expect the sink to always add line
delimiters, otherwise stuff like
{code}
headline
{code}
would no longer be possible to emit with the Html5Sink.
I don't see any need to restrict in line comments in HTML/Markdown!
> MarkdownSink: Comment missing EOLs
> --
>
> Key: DOXIA-746
> URL: https://issues.apache.org/jira/browse/DOXIA-746
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The sink API is not clear about whether comments are block or inline elements
> (although never rendered the question is how they should appear in the markup
> sources)
> In APT
> [comments|https://maven.apache.org/doxia/references/apt-format.html#comment]
> always end with the line ending (as there is no dedicated end comment
> delimiter).
> OTOH in markdown/html they have a dedicated end character.
> Currently two consecutive comments in APT are emitted as
> {code}
> sink.comment("comment1")
> sink.comment("comment2")
> {code}
> In APT they are separated by newlines but in Sink API and Markdown/HTML they
> are not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-747) MarkdownSink: Section headings must be located at the beginning of a line
[
https://issues.apache.org/jira/browse/DOXIA-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887380#comment-17887380
]
Konrad Windszus commented on DOXIA-747:
---
Yes, it already is (for the Markdown case)!
> MarkdownSink: Section headings must be located at the beginning of a line
> -
>
> Key: DOXIA-747
> URL: https://issues.apache.org/jira/browse/DOXIA-747
> Project: Maven Doxia
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> If currently a {{Sink.comment()}} is followed by a {{Sink.sectionTitle(...)}}
> with some text it is not emitted on a dedicated line through the
> {{MarkdownSink}}/
> However according to https://spec.commonmark.org/0.31.2/#atx-headings
> {quote} The opening # character may be preceded by up to three spaces of
> indentation {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8285) Implement mvnenc, new CLI tool for password management
[ https://issues.apache.org/jira/browse/MNG-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-8285: Assignee: Tamas Cservenak > Implement mvnenc, new CLI tool for password management > -- > > Key: MNG-8285 > URL: https://issues.apache.org/jira/browse/MNG-8285 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8295) Dependency Manager Transitivity (now default) handles dependency management inconsistently
[
https://issues.apache.org/jira/browse/MNG-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Didier Loiseau updated MNG-8295:
Description:
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is a feature request
(that should have been implemented by MNG-7982), I thought it would make more
sense to track this inconsistency as a bug.
The attached [^dependency-transitivity-inconsistency.zip] (copied from
MNG-5761) can be used to show the issue.
I’m running with
{code:java}
$ mvn -v
Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
Java version: 21.0.2, vendor: Oracle Corporation, runtime:
/home/didier/.sdkman/candidates/java/21.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
{code}
First you can see that {{dependent-pom}} manages the version of
{{commons-collections}} to *3.2.2* ({{{}commons-beanutils:1.9.2{}}} depends on
3.2.1):
{code:java}
$ mvn dependency:tree -f dependent-pom.xml
…
[INFO] MNG-5761:dependent:pom:1.0-SNAPSHOT
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO]+- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]\- commons-collections:commons-collections:jar:3.2.2:compile
{code}
Now install {{parent-pom}} and {{{}dependent-pom{}}}, and check the
dependencies of {{{}depending-pom{}}}:
{code:java}
$ mvn install -f parent-pom.xml
$ mvn install -f dependent-pom.xml
$ mvn dependency:tree -f depending-pom.xml
…
[INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO]\- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
{code}
you can see that the {{}} of {{dependent}} is ignored
(like with Maven 3), and we get {{commons-collections}} *3.2.1* instead.
However, if we install {{dependent-pom}} and check the dependencies of
{{{}dependent-pom2{}}}, we get:
{code:java}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
[INFO]\- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.2:compile
{code}
So now we get {{commons-collections}} *3.2.2* again! {{}}
is taken into account at depth 2+ (and 0) but not at depth 1.
This is due to [these 3
lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
in {{{}ClassicDependencyManager{}}}:
{code:java}
@Override
public DependencyManager deriveChildManager(DependencyCollectionContext
context) {
// MNG-4720: Maven2 backward compatibility
// Removing this IF makes one IT fail here (read comment above):
//
https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
if (depth == 1) {
return newInstance(managedVersions, managedScopes,
managedOptionals, managedLocalPaths, managedExclusions);
}
return super.deriveChildManager(context);
}
{code}
I have also created [a PR with integration
tests|https://github.com/apache/maven-integration-testing/pull/379] for
MNG-7982, which shows the issue as well.
I simple fix would be to use the {{TransitiveDependencyManager}} when
{{maven.resolver.dependencyManagerTransitivity=true}}.
was:
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is a feature request
(that should have been implemented by MNG-7982), I thought it would make more
sense to track this inconsistency as a bug.
The attached [^dependency-transitivity-inconsistency.z
[jira] [Updated] (MNG-8295) Dependency Manager Transitivity (now default) handles dependency management inconsistently
[
https://issues.apache.org/jira/browse/MNG-8295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Didier Loiseau updated MNG-8295:
Description:
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is originally a
different issue (that should have been fixed by MNG-7982), I thought it would
make more sense to track this inconsistency as a separate bug.
The attached [^dependency-transitivity-inconsistency.zip] (copied from
MNG-5761) can be used to show the issue.
I’m running with
{code:java}
$ mvn -v
Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
Java version: 21.0.2, vendor: Oracle Corporation, runtime:
/home/didier/.sdkman/candidates/java/21.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
{code}
First you can see that {{dependent-pom}} manages the version of
{{commons-collections}} to *3.2.2* ({{{}commons-beanutils:1.9.2{}}} depends on
3.2.1):
{code:java}
$ mvn dependency:tree -f dependent-pom.xml
…
[INFO] MNG-5761:dependent:pom:1.0-SNAPSHOT
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO]+- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]\- commons-collections:commons-collections:jar:3.2.2:compile
{code}
Now install {{parent-pom}} and {{{}dependent-pom{}}}, and check the
dependencies of {{{}depending-pom{}}}:
{code:java}
$ mvn install -f parent-pom.xml
$ mvn install -f dependent-pom.xml
$ mvn dependency:tree -f depending-pom.xml
…
[INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO]\- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
{code}
you can see that the {{}} of {{dependent}} is ignored
(like with Maven 3), and we get {{commons-collections}} *3.2.1* instead.
However, if we install {{dependent-pom}} and check the dependencies of
{{{}dependent-pom2{}}}, we get:
{code:java}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
[INFO]\- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.2:compile
{code}
So now we get {{commons-collections}} *3.2.2* again! {{}}
is taken into account at depth 2+ (and 0) but not at depth 1.
This is due to [these 3
lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
in {{{}ClassicDependencyManager{}}}:
{code:java}
@Override
public DependencyManager deriveChildManager(DependencyCollectionContext
context) {
// MNG-4720: Maven2 backward compatibility
// Removing this IF makes one IT fail here (read comment above):
//
https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
if (depth == 1) {
return newInstance(managedVersions, managedScopes,
managedOptionals, managedLocalPaths, managedExclusions);
}
return super.deriveChildManager(context);
}
{code}
I have also created [a PR with integration
tests|https://github.com/apache/maven-integration-testing/pull/379] for
MNG-7982, which shows the issue as well.
I simple fix would be to use the {{TransitiveDependencyManager}} when
{{{}maven.resolver.dependencyManagerTransitivity=true{}}}.
was:
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is a feature request
(that should have been implemented by MNG-7982), I thought it would make more
sense to track this inconsistency as a bug.
The attached [^dependency-transitivi
[jira] [Created] (DOXIA-748) Support file filtering in Doxia ParserModule
Abel Salgado Romero created DOXIA-748: - Summary: Support file filtering in Doxia ParserModule Key: DOXIA-748 URL: https://issues.apache.org/jira/browse/DOXIA-748 Project: Maven Doxia Issue Type: Improvement Components: Core Affects Versions: 2.0.0 Reporter: Abel Salgado Romero When defining a module one can define the file extensions to process. However, more complex scenarios require more than a extension. For example, in the [Asciidoctor module|https://github.com/asciidoctor/asciidoctor-maven-plugin/issues] it's possible to have "hidden" (use _ prefix) files that are not to be converted directly, instead these are to be included in others. My first though is to be able to pass a `FilenameFilter` in the constructor. The filter would be matched against files that comply with the file extensions to confirm whether these should be processed or not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887475#comment-17887475 ] Christian Schulte commented on MNG-5761: [~Didier Loiseau] Just do not invest any more time in things like that. It will not happen. I presented various ways on how to introduce changes like that in a backwards compatible way. All of those got denied. It would have been easy to just make the model version an attribute to detect what resolution behaviour an author intended to be used. I tried to introduce 4.1.0 for this. It would have been perfectly fine for Maven to behave differently based on the model version declared in a POM. All of this got denied. You cannot do anything about it. There will be no model version 5.0.0 in the next decades. You seem to have started using Maven and seem to verify things are working as advertised. Very few users are doing that. They just configure theire POMs in a way it works for them, do not care about anything and will then start complaining if an updated version of Maven starts fixing bugs. There is no way out of this. One of the biggest mistakes in my life was using Maven. Full of bugs and inconsistent behaviour no one will ever take care of, just because of ignorance. Maven project management has blocked itself from any kind of progress. What I mean by this is, even Maven 10 would still keep inconsistencies introduced by Maven 2, just because users are to ignorant to notice they are relying on bugs in Maven Core or Resolver. Most of them do not even notice. Maven is broken by management, not by design - and it will stay that way for the lifetime of the project. Just don't bother filing issues. They will not get fixed. > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 4.0.x-candidate > > Attachments: MNG-5761.zip, depending-pom2.xml > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian Jira (v8.20.10#820010)
