[jira] [Closed] (ARCHETYPE-570) Goal integration-test of maven-archetype-plugin fails "Archetype IT blueprint failed: Execution failure: exit code = 1"
[
https://issues.apache.org/jira/browse/ARCHETYPE-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed ARCHETYPE-570.
-
Resolution: Information Provided
Old issue without response ... If problem still exist should be tested with the
latest version of all components
> Goal integration-test of maven-archetype-plugin fails "Archetype IT blueprint
> failed: Execution failure: exit code = 1"
> ---
>
> Key: ARCHETYPE-570
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-570
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 2.2
> Environment: maven-archetype-plugin 2.2
>Reporter: Gennady Chmelev
>Priority: Major
>
> Installing old version Karaf 2.3.11 and get error
> {code:java}
> Apache Maven 3.0.4 (r1232337; 2012-01-17 11:44:56+0300)
> Maven home: /mvn/apache-maven-3.0.4
> Java version: 1.6.0_65, vendor: Apple Inc.
> Java home: /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> Default locale: ru_RU, platform encoding: MacCyrillic
> OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"
> ...
> [INFO] Apache Karaf :: Tooling :: Maven2 Command Help plugin SUCCESS [2.751s]
> [INFO] Apache Karaf :: Tooling :: Exam Testing Framework . SUCCESS [0.705s]
> [INFO] Apache Karaf :: Tooling :: Exam Testing Framework :: Options SUCCESS
> [0.766s]
> [INFO] Apache Karaf :: Tooling :: Exam Testing Framework :: Container SUCCESS
> [1.829s]
> [INFO] Apache Karaf :: Archetypes SUCCESS [0.449s]
> [INFO] Apache Karaf :: Archetypes :: Assembly Archetype .. FAILURE [26.041s]
> [INFO] Apache Karaf :: Archetypes :: Blueprint Archetype . SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Bundle Archetype SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Command Archetype ... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Feature Archetype ... SKIPPED
> [INFO] Apache Karaf :: Archetypes :: Kar Archetype ... SKIPPED
> [INFO] Apache Karaf :: Integration Tests . SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2:58.002s
> [INFO] Finished at: Mon Jul 08 16:01:11 MSD 2019
> [INFO] Final Memory: 108M/403M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:2.2:integration-test
> (default-integration-test) on project karaf-blueprint-archetype:
> [ERROR] Archetype IT 'blueprint' failed: Execution failure: exit code = 1
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-archetype-plugin:2.2:integration-test
> (default-integration-test) on project karaf-blueprint-archetype:
> Archetype IT 'blueprint' failed: Execution failure: exit code = 1
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Archetype IT 'blueprint' fa
[jira] [Closed] (ARCHETYPE-424) Conditionally include or exclude a fileSet from an archetype when project is generated
[
https://issues.apache.org/jira/browse/ARCHETYPE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed ARCHETYPE-424.
-
Resolution: Duplicate
> Conditionally include or exclude a fileSet from an archetype when project is
> generated
> --
>
> Key: ARCHETYPE-424
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-424
> Project: Maven Archetype
> Issue Type: New Feature
>Reporter: Adrian Gonzalez
>Priority: Major
>
> I'm creating a project generating code samples for accessing Oracle and
> Mainframe.
> I want to conditionnaly generate the samples based on user input
> Define value for groupId: : com.example
> Define value for artifactId: : myproject
> Define value for package: com.example: :
> Define value for SGBD Sample : : Y
> Define value for Mainframe Sample : : N
> Could it be possible to add this functionnality ?
> i.e. This could be done by adding an attribute into fileSet element which
> would indicate if the fileSet directive needs to be taken into account :
> {code:xml}
>
> src/main/java
>
> mainframe/*.java
>
>
> {code}
> Some links :
> *
> [http://stackoverflow.com/questions/1919704/how-do-i-conditionally-include-or-exclude-a-file-from-an-archetype-when-project]
> * [ARCHETYPE-58|http://jira.codehaus.org/browse/ARCHETYPE-58] (this one
> didn't adressed this issue)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-537) fileset exclude or include on conditions
[ https://issues.apache.org/jira/browse/ARCHETYPE-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed ARCHETYPE-537. - Resolution: Duplicate > fileset exclude or include on conditions > > > Key: ARCHETYPE-537 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-537 > Project: Maven Archetype > Issue Type: New Feature > Components: Archetypes >Affects Versions: 3.0.1 > Environment: >Reporter: Dong Xu >Priority: Major > Labels: features > > I think this will be an useful feature: > maven archetype user can choose to include files or not according to a > required property. > For Example: > I am xxx-archetype developer, and I set "*useRedis*" as one required > property. > Now some guys want to use xxx-archetype, so if he give a "N" value to this > property , the "*src/main/resources/spring/redis.xml*" will be excluded. > Otherwise, the generated project will include > "*src/main/resources/spring/redis.xml*". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-540) Upgrade from 2.x compatible archetype to 3.x document
[ https://issues.apache.org/jira/browse/ARCHETYPE-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated ARCHETYPE-540: -- Fix Version/s: waiting-for-feedback > Upgrade from 2.x compatible archetype to 3.x document > -- > > Key: ARCHETYPE-540 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-540 > Project: Maven Archetype > Issue Type: Wish >Reporter: Tim Pizey >Priority: Major > Fix For: waiting-for-feedback > > > I had a nice archetype, I cannot discover how to make it work, nor can I go > back to 2.x series. > > The move from 2 to 3 is breaking a change but there is no upgrade document. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-629) Lexical Error when archetype-resource contains excel file
[
https://issues.apache.org/jira/browse/ARCHETYPE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated ARCHETYPE-629:
--
Fix Version/s: waiting-for-feedback
> Lexical Error when archetype-resource contains excel file
> -
>
> Key: ARCHETYPE-629
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-629
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.2.1
>Reporter: Deepak
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have created an archetype where my archetype-resources under
> src/main/resources contains an template excel that will get copied when a
> project will be created out of it. While executing the archetype:generate on
> this, it throws lexical error while creating the excel file.
>
> Exception Trace:
> {code:java}
> [ERROR] ResourceManager.getResource() parse exception
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\ufffd" (65533), after : "" at
> archetype-resources/src/test/resources/XYZZ.xlsx[line 50, column 138]
> at org.apache.velocity.Template.process (Template.java:151)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource
> (ResourceManagerImpl.java:437)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource
> (ResourceManagerImpl.java:352)
> at org.apache.velocity.runtime.RuntimeInstance.getTemplate
> (RuntimeInstance.java:1533)
> at org.apache.velocity.app.VelocityEngine.mergeTemplate
> (VelocityEngine.java:343)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processTemplate
> (DefaultFilesetArchetypeGenerator.java:715)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFileSet
> (DefaultFilesetArchetypeGenerator.java:513)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processTemplates
> (DefaultFilesetArchetypeGenerator.java:758)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processArchetypeTemplates
> (DefaultFilesetArchetypeGenerator.java:487)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFilesetProject
> (DefaultFilesetArchetypeGenerator.java:605)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFilesetModule
> (DefaultFilesetArchetypeGenerator.java:538)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype
> (DefaultFilesetArchetypeGenerator.java:206)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype
> (DefaultArchetypeGenerator.java:133)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:104)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:148)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:163)
> at
> org.apache.maven.archetype.DefaultArchetypeManager.generateProjectFromArchetype
> (DefaultArchetypeManager.java:75)
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute
> (CreateProjectFromArchetypeMojo.java:211)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAcces
[jira] [Commented] (ARCHETYPE-629) Lexical Error when archetype-resource contains excel file
[
https://issues.apache.org/jira/browse/ARCHETYPE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887180#comment-17887180
]
Slawomir Jaranowski commented on ARCHETYPE-629:
---
binary files should not be filtered
> Lexical Error when archetype-resource contains excel file
> -
>
> Key: ARCHETYPE-629
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-629
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.2.1
>Reporter: Deepak
>Priority: Major
>
> I have created an archetype where my archetype-resources under
> src/main/resources contains an template excel that will get copied when a
> project will be created out of it. While executing the archetype:generate on
> this, it throws lexical error while creating the excel file.
>
> Exception Trace:
> {code:java}
> [ERROR] ResourceManager.getResource() parse exception
> org.apache.velocity.exception.ParseErrorException: Lexical error,
> Encountered: "\ufffd" (65533), after : "" at
> archetype-resources/src/test/resources/XYZZ.xlsx[line 50, column 138]
> at org.apache.velocity.Template.process (Template.java:151)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.loadResource
> (ResourceManagerImpl.java:437)
> at org.apache.velocity.runtime.resource.ResourceManagerImpl.getResource
> (ResourceManagerImpl.java:352)
> at org.apache.velocity.runtime.RuntimeInstance.getTemplate
> (RuntimeInstance.java:1533)
> at org.apache.velocity.app.VelocityEngine.mergeTemplate
> (VelocityEngine.java:343)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processTemplate
> (DefaultFilesetArchetypeGenerator.java:715)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFileSet
> (DefaultFilesetArchetypeGenerator.java:513)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processTemplates
> (DefaultFilesetArchetypeGenerator.java:758)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processArchetypeTemplates
> (DefaultFilesetArchetypeGenerator.java:487)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFilesetProject
> (DefaultFilesetArchetypeGenerator.java:605)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.processFilesetModule
> (DefaultFilesetArchetypeGenerator.java:538)
> at
> org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype
> (DefaultFilesetArchetypeGenerator.java:206)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype
> (DefaultArchetypeGenerator.java:133)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:104)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:148)
> at
> org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype
> (DefaultArchetypeGenerator.java:163)
> at
> org.apache.maven.archetype.DefaultArchetypeManager.generateProjectFromArchetype
> (DefaultArchetypeManager.java:75)
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute
> (CreateProjectFromArchetypeMojo.java:211)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.Nati
[jira] [Updated] (DOXIA-746) MarkdownSink: Comment missing EOLs
[
https://issues.apache.org/jira/browse/DOXIA-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-746:
--
Description:
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.
was:Comments must be treated as block elements, i.e. if other block elements
are following they must be separated by a EOL. Currently e.g. two consecutive
comments are emitted without a EOL in between.
> 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=17887184#comment-17887184
]
Konrad Windszus commented on DOXIA-746:
---
There are two ways of fixing this:
# Make APTParser always emit a EOL at the end of a comment
# Make MarkdownSink/HTML5Sink always emit comments with a EOL suffix
[~michael-o] Any opinion about this?
> 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] (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=17887261#comment-17887261
]
Guillaume Nodet commented on MNG-4917:
--
I find it hard to fully understand the semantic concern. When we talk about a
default value, this usually indicates "a value when no other value was
explicitly given". That's what _active by default_ also implies.
So what if we add a {{alwaysActive}} boolean instead of those workaround ? The
meaning is very clear and would lead people to understand that the
{{activeByDefault}} clearly indicates that this is not _always active_.
> 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] [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=17887261#comment-17887261
]
Guillaume Nodet edited comment on MNG-4917 at 10/7/24 6:43 AM:
---
[~kriegaex] I find it hard to fully understand the semantic concern. When we
talk about a default value, this usually indicates "a value when no other value
was explicitly given". That's what _active by default_ also implies.
So what if we add a {{alwaysActive}} boolean instead of those workaround ? The
meaning is very clear and would lead people to understand that the
{{activeByDefault}} clearly indicates that this is not _always active_.
was (Author: gnt):
I find it hard to fully understand the semantic concern. When we talk about a
default value, this usually indicates "a value when no other value was
explicitly given". That's what _active by default_ also implies.
So what if we add a {{alwaysActive}} boolean instead of those workaround ? The
meaning is very clear and would lead people to understand that the
{{activeByDefault}} clearly indicates that this is not _always active_.
> 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] [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 6:55 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-none-else
{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 ?
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-else
{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] (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 commented on MNG-4917:
--
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-else
{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] [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 6:56 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 ?
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-none-else
{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] [Reopened] (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 reopened MNG-4917: -- Reopening to at least improve doc. > 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] (MWRAPPER-151) Maven Wrapper not handling usernames with spaces on Windows
Jack Green created MWRAPPER-151:
---
Summary: Maven Wrapper not handling usernames with spaces on
Windows
Key: MWRAPPER-151
URL: https://issues.apache.org/jira/browse/MWRAPPER-151
Project: Maven Wrapper
Issue Type: Bug
Affects Versions: 3.3.2
Reporter: Jack Green
When Maven wrapper is run on a username with spaces on Windows, it doesn’t work
and an error is produced:
{code:java}
'C:\Users\Test' is not recognized as an internal or external command, operable
program or batch file.
Cannot start maven from wrapper {code}
Reproducer:
- Have a username with spaces is in it (e.g. {{{}Test User Name{}}})
- Create Maven wrapper ({{{}mvn wrapper:wrapper{}}})
- Run the newly created Maven wrapper ({{{}mvnw –version{}}})
I _suspect_ this is being caused by the following pattern:
{{Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"}}
Where $MAVEN_HOME contains spaces and is not being quoted correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-151) Maven Wrapper not handling usernames with spaces on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Green updated MWRAPPER-151:
Description:
When Maven wrapper is run on a username with spaces on Windows, it doesn’t work
and an error is produced:
{code:java}
'C:\Users\Test' is not recognized as an internal or external command, operable
program or batch file.
Cannot start maven from wrapper {code}
Reproducer:
- Have a username with spaces is in it (e.g. {{{}Test User Name{}}})
- Create Maven wrapper ({{{}mvn wrapper:wrapper{}}})
- Run the newly created Maven wrapper ({{{}mvnw –version{}}})
I _suspect_ this is being caused by the following pattern:
{{Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"}}
Where {{$MAVEN_HOME}} contains spaces and is not being quoted correctly.
was:
When Maven wrapper is run on a username with spaces on Windows, it doesn’t work
and an error is produced:
{code:java}
'C:\Users\Test' is not recognized as an internal or external command, operable
program or batch file.
Cannot start maven from wrapper {code}
Reproducer:
- Have a username with spaces is in it (e.g. {{{}Test User Name{}}})
- Create Maven wrapper ({{{}mvn wrapper:wrapper{}}})
- Run the newly created Maven wrapper ({{{}mvnw –version{}}})
I _suspect_ this is being caused by the following pattern:
{{Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"}}
Where $MAVEN_HOME contains spaces and is not being quoted correctly.
> Maven Wrapper not handling usernames with spaces on Windows
> ---
>
> Key: MWRAPPER-151
> URL: https://issues.apache.org/jira/browse/MWRAPPER-151
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Jack Green
>Priority: Major
>
> When Maven wrapper is run on a username with spaces on Windows, it doesn’t
> work and an error is produced:
>
> {code:java}
> 'C:\Users\Test' is not recognized as an internal or external command,
> operable program or batch file.
> Cannot start maven from wrapper {code}
>
>
> Reproducer:
> - Have a username with spaces is in it (e.g. {{{}Test User Name{}}})
> - Create Maven wrapper ({{{}mvn wrapper:wrapper{}}})
> - Run the newly created Maven wrapper ({{{}mvnw –version{}}})
>
> I _suspect_ this is being caused by the following pattern:
> {{Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"}}
>
> Where {{$MAVEN_HOME}} contains spaces and is not being quoted correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-151) Maven Wrapper not handling usernames with spaces on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887177#comment-17887177
]
Jack Green commented on MWRAPPER-151:
-
I did _try_ to raise this on the [mailing
list|https://lists.apache.org/list.html?us...@maven.apache.org], but my message
wouldn't post.
> Maven Wrapper not handling usernames with spaces on Windows
> ---
>
> Key: MWRAPPER-151
> URL: https://issues.apache.org/jira/browse/MWRAPPER-151
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.3.2
>Reporter: Jack Green
>Priority: Major
>
> When Maven wrapper is run on a username with spaces on Windows, it doesn’t
> work and an error is produced:
>
> {code:java}
> 'C:\Users\Test' is not recognized as an internal or external command,
> operable program or batch file.
> Cannot start maven from wrapper {code}
>
>
> Reproducer:
> - Have a username with spaces is in it (e.g. {{{}Test User Name{}}})
> - Create Maven wrapper ({{{}mvn wrapper:wrapper{}}})
> - Run the newly created Maven wrapper ({{{}mvnw –version{}}})
>
> I _suspect_ this is being caused by the following pattern:
> {{Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"}}
>
> Where $MAVEN_HOME contains spaces and is not being quoted correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-497) An archetype descriptor with resources in the root folder is not handled very well.
[ https://issues.apache.org/jira/browse/ARCHETYPE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated ARCHETYPE-497: -- Fix Version/s: waiting-for-feedback > An archetype descriptor with resources in the root folder is not handled very > well. > --- > > Key: ARCHETYPE-497 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-497 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Reporter: Kedar Mhaswade >Priority: Minor > Fix For: waiting-for-feedback > > Original Estimate: 96h > Remaining Estimate: 96h > > I have created a detailed project on GitHub explaining the problem. Simply > put, it is not possible right now to copy the resources using the fileset > that refers to the current directory to something else other than > (src/main/resources). > Please see the [readme | > https://github.com/kedarmhaswade/is-this-archetype-bug/blob/master/README.md] > of the test case for details. Let me know if you need more information. If > there is a workaround, please let me know that too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-497) An archetype descriptor with resources in the root folder is not handled very well.
[ https://issues.apache.org/jira/browse/ARCHETYPE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887183#comment-17887183 ] Slawomir Jaranowski commented on ARCHETYPE-497: --- Is connected with ... ARCHETYPE-684? > An archetype descriptor with resources in the root folder is not handled very > well. > --- > > Key: ARCHETYPE-497 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-497 > Project: Maven Archetype > Issue Type: Bug > Components: Generator >Reporter: Kedar Mhaswade >Priority: Minor > Original Estimate: 96h > Remaining Estimate: 96h > > I have created a detailed project on GitHub explaining the problem. Simply > put, it is not possible right now to copy the resources using the fileset > that refers to the current directory to something else other than > (src/main/resources). > Please see the [readme | > https://github.com/kedarmhaswade/is-this-archetype-bug/blob/master/README.md] > of the test case for details. Let me know if you need more information. If > there is a workaround, please let me know that too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIA-746) MarkdownSink: Comment missing EOLs
Konrad Windszus created DOXIA-746: - Summary: 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 Comments must be treated as block elements, i.e. if other block elements are following they must be separated by a EOL. Currently e.g. two consecutive comments are emitted without a EOL in between. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (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:all-tabpanel
]
Slawomir Jaranowski closed ARCHETYPE-681.
-
Resolution: Fixed
> [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] (MPIR-469) Broken link to Git documentation page
[ https://issues.apache.org/jira/browse/MPIR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-469: Summary: Broken link to Git documentation page (was: Broken link to git documentation page) > Broken link to Git documentation page > - > > Key: MPIR-469 > URL: https://issues.apache.org/jira/browse/MPIR-469 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: scm >Reporter: Dan Rollo >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.1 > > > The git doc site layout has changed, and the old general link in all > generated maven report sites is no longer valid. I've pushed [PR# > 77|https://github.com/apache/maven-project-info-reports-plugin/pull/77] to > change the old link: > [https://git-scm.com/documentation] > to point to the new general git doc link: > [https://git-scm.com/doc]. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (MJAR-315) Use a predefined constant for project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MJAR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski deleted MJAR-315: - > Use a predefined constant for project.build.outputTimestamp > --- > > Key: MJAR-315 > URL: https://issues.apache.org/jira/browse/MJAR-315 > Project: Maven JAR Plugin > Issue Type: Improvement >Reporter: Sergey Ponomarev >Priority: Minor > > Duplicate of MJAR-314 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPIR-469) Broken link to Git documentation page
[ https://issues.apache.org/jira/browse/MPIR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-469. --- Resolution: Fixed Fixed with [9def033da3d6be0080ddadc21e86bf4ad1698b84|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=9def033da3d6be0080ddadc21e86bf4ad1698b84]. > Broken link to Git documentation page > - > > Key: MPIR-469 > URL: https://issues.apache.org/jira/browse/MPIR-469 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: scm >Reporter: Dan Rollo >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.1 > > > The git doc site layout has changed, and the old general link in all > generated maven report sites is no longer valid. I've pushed [PR# > 77|https://github.com/apache/maven-project-info-reports-plugin/pull/77] to > change the old link: > [https://git-scm.com/documentation] > to point to the new general git doc link: > [https://git-scm.com/doc]. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-684) Not providing a directory element in the fileset results in a null directory instead
[
https://issues.apache.org/jira/browse/ARCHETYPE-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed ARCHETYPE-684.
-
Resolution: Fixed
> Not providing a directory element in the fileset results in a null directory
> instead
>
>
> Key: ARCHETYPE-684
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-684
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Giovanni van der Schelde
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.3.1
>
> Attachments: reproducer.zip
>
>
> When you have a directory structure like:
> {code:java}
> src/
> main/resources/
>src/
>example.yml{code}
> And a fileSet in the archetype-descriptor like:
> {code:java}
>
>
>
> *.yml
>
> {code}
> When you generate the archetype you won't get the .yml files, but instead you
> get an empty directory with the name `null`.
> When you explicitly provide the element, the `null` directory
> disappears and the .yml file is copied.
> I think it would make sense to either;
> a) Log an error or warning that the xml is incomplete
> b) When no directory is provided, use a default (of the root directory)
> instead
> Where option B makes to most sense to me.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-352) Upgrade to Velocity 2.4
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIASITETOOLS-352: -- Summary: Upgrade to Velocity 2.4 (was: Upgrade to Velocity 2.3) > Upgrade to Velocity 2.4 > --- > > Key: DOXIASITETOOLS-352 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-352 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Priority: Major > Fix For: 2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-353) Upgrade to Plexus Velocity 2.2.0
Michael Osipov created DOXIASITETOOLS-353: - Summary: Upgrade to Plexus Velocity 2.2.0 Key: DOXIASITETOOLS-353 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-353 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Fix For: 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-352) Upgrade to Velocity 2.3
Michael Osipov created DOXIASITETOOLS-352: - Summary: Upgrade to Velocity 2.3 Key: DOXIASITETOOLS-352 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-352 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Fix For: 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-353) Upgrade to Plexus Velocity 2.2.0
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-353. - Resolution: Fixed Fixed with [c9cb8e0d95c3f3b634d2f0bb77928df3994aec29|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=c9cb8e0d95c3f3b634d2f0bb77928df3994aec29]. > Upgrade to Plexus Velocity 2.2.0 > > > Key: DOXIASITETOOLS-353 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-353 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Priority: Major > Fix For: 2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-352) Upgrade to Velocity 2.4
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-352. - Resolution: Fixed Fixed with [a0a555b1c3a093e2aa5d25dcefa7701390ef1bce|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=a0a555b1c3a093e2aa5d25dcefa7701390ef1bce]. > Upgrade to Velocity 2.4 > --- > > Key: DOXIASITETOOLS-352 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-352 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Priority: Major > Fix For: 2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-354) Upgrade to Maven Reporting API 4.0.0
Michael Osipov created DOXIASITETOOLS-354: - Summary: Upgrade to Maven Reporting API 4.0.0 Key: DOXIASITETOOLS-354 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-354 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-354) Upgrade to Maven Reporting API 4.0.0
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-354. - Resolution: Fixed Fixed with [4d455f7acc89362883b03e9cf8740560af098d45|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=4d455f7acc89362883b03e9cf8740560af098d45]. > Upgrade to Maven Reporting API 4.0.0 > > > Key: DOXIASITETOOLS-354 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-354 > Project: Maven Doxia Sitetools > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0 > > -- 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=17887185#comment-17887185
]
Michael Osipov commented on DOXIA-746:
--
There is a bug where the APT comment not properly converted to HTML, read line
separator missing. I am in favor of terminating evey APT comment with a LS
especially because the docs say that everything after {{~~}} is ignored until
end of line.
Markdown comments (https://spec.commonmark.org/0.31.2/#html-comment) use HTML
comments so I don't see a need to add a LS. Is that what you are asking for?
> 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] (MSHARED-1204) Consider special casing slf4j-simple et al
[ https://issues.apache.org/jira/browse/MSHARED-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887206#comment-17887206 ] Elliotte Rusty Harold edited comment on MSHARED-1204 at 10/6/24 2:59 PM: - Just noting for myself that I expect to have a little free time in the near future, and I should take a run at this one, whether here or in maven-dependency-plugin was (Author: elharo): Just noting for myself that I expect to have a little free time in the near future, and I should take a run at this one. > Consider special casing slf4j-simple et al > -- > > Key: MSHARED-1204 > URL: https://issues.apache.org/jira/browse/MSHARED-1204 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > slf4j-simple is sometimes added to classpaths to shut up annoying warnings > from SLF4J at run and test time, even though it isn't absolutely required. > Can we do better with our analysis of the common case and similar ones, > rather than reporting it as declared but unused? > ``` > > org.slf4j > slf4j-simple > test > > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1204) Consider special casing slf4j-simple et al
[ https://issues.apache.org/jira/browse/MSHARED-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned MSHARED-1204: -- Assignee: Elliotte Rusty Harold > Consider special casing slf4j-simple et al > -- > > Key: MSHARED-1204 > URL: https://issues.apache.org/jira/browse/MSHARED-1204 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > slf4j-simple is sometimes added to classpaths to shut up annoying warnings > from SLF4J at run and test time, even though it isn't absolutely required. > Can we do better with our analysis of the common case and similar ones, > rather than reporting it as declared but unused? > ``` > > org.slf4j > slf4j-simple > test > > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1204) Consider special casing slf4j-simple et al
[ https://issues.apache.org/jira/browse/MSHARED-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887206#comment-17887206 ] Elliotte Rusty Harold commented on MSHARED-1204: Just noting for myself that I expect to have a little free time in the near future, and I should take a run at this one. > Consider special casing slf4j-simple et al > -- > > Key: MSHARED-1204 > URL: https://issues.apache.org/jira/browse/MSHARED-1204 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-dependency-analyzer >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > > slf4j-simple is sometimes added to classpaths to shut up annoying warnings > from SLF4J at run and test time, even though it isn't absolutely required. > Can we do better with our analysis of the common case and similar ones, > rather than reporting it as declared but unused? > ``` > > org.slf4j > slf4j-simple > test > > ``` -- 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=17887244#comment-17887244
]
Alexander Kriegisch commented on MNG-4917:
--
[~gnodet], that the behaviour was there by design or even that it is documented
as-is does not mean that it makes much sense or is anything but
counter-intuitive and more harmful than helpful due to its raising false
expectations, stealing every developer's time playing with it and your time
answering related issues. The very fact that two workarounds - namely
{{[1.)}} and {{true}} - were suggested here
and that workarounds are even necessary for something so simple because the
existing option with a name implying to do what developers need, might clue you
in to the fact that something might be wrong in this picture.
> 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] [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=17887244#comment-17887244
]
Alexander Kriegisch edited comment on MNG-4917 at 10/7/24 1:19 AM:
---
[~gnodet], that the behaviour was there by design or even that it is documented
as-is does not mean that it makes much sense or is anything but
counter-intuitive and more harmful than helpful due to its raising false
expectations, stealing every developer's time playing with it and your time
answering related issues. The very fact that two workarounds - namely
{{[1.)}} and {{true}} - were suggested here
and that workarounds are even necessary for something so simple because the
existing option with a name implying to do what developers need, might clue you
in to the fact that something might be wrong in this picture.
The least you could do if you are so concerned about a some developers relying
on the existing behaviour, is to document the two workarounds in the two places
you pointed to earlier, explaining that if users want to _really_ activate a
profile by default, even if no other profile was activated manually or by a
condition, they could use those workarounds.
was (Author: kriegaex):
[~gnodet], that the behaviour was there by design or even that it is documented
as-is does not mean that it makes much sense or is anything but
counter-intuitive and more harmful than helpful due to its raising false
expectations, stealing every developer's time playing with it and your time
answering related issues. The very fact that two workarounds - namely
{{[1.)}} and {{true}} - were suggested here
and that workarounds are even necessary for something so simple because the
existing option with a name implying to do what developers need, might clue you
in to the fact that something might be wrong in this picture.
> 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] [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] [Created] (MJAR-315) Use a predefined constant for project.build.outputTimestamp
Sergey Ponomarev created MJAR-315:
-
Summary: Use a predefined constant for
project.build.outputTimestamp
Key: MJAR-315
URL: https://issues.apache.org/jira/browse/MJAR-315
Project: Maven JAR Plugin
Issue Type: Improvement
Reporter: Sergey Ponomarev
The "Configuring for Reproducible Builds" guide shows and example how to
specify a static outputTimestamp:
2023-01-01T00:00:00Z
The date inside is really doesn't matter and I used the property as is but was
afraid of being asked on a review why the 2023 year was used so used the
current year.
But still during a review I was asked:
bq. these changes are likely going to confuse future developers ("This date
shouldn't be static! Lets make it a variable!").
The Gradle has an option preserveFileTimestamps = false that will just put 1
Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
Jan has some special treatment by Java that's why the Gradle team used the 1
Feb.
See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
I don't think it worth to declare some new property e.g.
true
But we can simply make a special constant value like:
REPRODUCIBLE_BUILD_STATIC_DATE
Then the constant will be replaced with the same 1 Feb 1980 to be similar with
Gradle produced artifacts.
This constant should make it more clear intention of the outputTimestamp but
also easier to find an explanation for this.
The outputTimestamp parsing is performed in the maven-archiver but the
maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-600) Use a predefined constant for project.build.outputTimestamp
Sergey Ponomarev created MCOMPILER-600:
--
Summary: Use a predefined constant for
project.build.outputTimestamp
Key: MCOMPILER-600
URL: https://issues.apache.org/jira/browse/MCOMPILER-600
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Sergey Ponomarev
The "Configuring for Reproducible Builds" guide shows and example how to
specify a static outputTimestamp:
2023-01-01T00:00:00Z
The date inside is really doesn't matter and I used the property as is but was
afraid of being asked on a review why the 2023 year was used so used the
current year.
But still during a review I was asked:
bq. these changes are likely going to confuse future developers ("This date
shouldn't be static! Lets make it a variable!").
The Gradle has an option preserveFileTimestamps = false that will just put 1
Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
Jan has some special treatment by Java that's why the Gradle team used the 1
Feb.
See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
I don't think it worth to declare some new property e.g.
true
But we can simply make a special constant value like:
REPRODUCIBLE_BUILD_STATIC_DATE
Then the constant will be replaced with the same 1 Feb 1980 to be similar with
Gradle produced artifacts.
This constant should make it more clear intention of the outputTimestamp but
also easier to find an explanation for this.
The outputTimestamp parsing is performed in the maven-archiver but the
maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-315) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887209#comment-17887209
]
Sergey Ponomarev commented on MJAR-315:
---
Sorry, I wanted to create the issue in the maven-compiler-plugin. Please close
it as duplicate of MJAR-314
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-315
> URL: https://issues.apache.org/jira/browse/MJAR-315
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAR-315) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Ponomarev updated MJAR-315:
--
Description: Duplicate of MJAR-314 (was: The "Configuring for Reproducible
Builds" guide shows and example how to specify a static outputTimestamp:
2023-01-01T00:00:00Z
The date inside is really doesn't matter and I used the property as is but was
afraid of being asked on a review why the 2023 year was used so used the
current year.
But still during a review I was asked:
bq. these changes are likely going to confuse future developers ("This date
shouldn't be static! Lets make it a variable!").
The Gradle has an option preserveFileTimestamps = false that will just put 1
Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
Jan has some special treatment by Java that's why the Gradle team used the 1
Feb.
See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
I don't think it worth to declare some new property e.g.
true
But we can simply make a special constant value like:
REPRODUCIBLE_BUILD_STATIC_DATE
Then the constant will be replaced with the same 1 Feb 1980 to be similar with
Gradle produced artifacts.
This constant should make it more clear intention of the outputTimestamp but
also easier to find an explanation for this.
The outputTimestamp parsing is performed in the maven-archiver but the
maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
the outputTimestamp config option)
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-315
> URL: https://issues.apache.org/jira/browse/MJAR-315
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> Duplicate of MJAR-314
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1430) Use a predefined constant for project.build.outputTimestamp
Sergey Ponomarev created MSHARED-1430:
-
Summary: Use a predefined constant for
project.build.outputTimestamp
Key: MSHARED-1430
URL: https://issues.apache.org/jira/browse/MSHARED-1430
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-archiver
Reporter: Sergey Ponomarev
The "Configuring for Reproducible Builds" guide shows and example how to
specify a static outputTimestamp:
2023-01-01T00:00:00Z
The date inside is really doesn't matter and I used the property as is but was
afraid of being asked on a review why the 2023 year was used so used the
current year.
But still during a review I was asked:
bq. these changes are likely going to confuse future developers ("This date
shouldn't be static! Lets make it a variable!").
The Gradle has an option preserveFileTimestamps = false that will just put 1
Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
Jan has some special treatment by Java that's why the Gradle team used the 1
Feb.
See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
I don't think it worth to declare some new property e.g.
true
But we can simply make a special constant value like:
REPRODUCIBLE_BUILD_STATIC_DATE
Then the constant will be replaced with the same 1 Feb 1980 to be similar with
Gradle produced artifacts.
This constant should make it more clear intention of the outputTimestamp but
also easier to find an explanation for this.
The outputTimestamp parsing is performed in the maven-archiver but the
maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8289) Update Plexus annotations to 2.2.0
Sylwester Lachiewicz created MNG-8289: - Summary: Update Plexus annotations to 2.2.0 Key: MNG-8289 URL: https://issues.apache.org/jira/browse/MNG-8289 Project: Maven Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz Assignee: Sylwester Lachiewicz Fix For: 3.9.10 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (ARCHETYPE-680) Integration test should report ERROR instead of WARNING when failing
[
https://issues.apache.org/jira/browse/ARCHETYPE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned ARCHETYPE-680:
-
Assignee: Slawomir Jaranowski
> Integration test should report ERROR instead of WARNING when failing
>
>
> Key: ARCHETYPE-680
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-680
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Giovanni van der Schelde
>Assignee: Slawomir Jaranowski
>Priority: Major
> Attachments: repro.zip
>
>
> When you run the integration test goal against a reference project the build
> fails when the content of the file is not equal. However, it is logged as a
> warning, not an error. I'd expect it to be an error just like when the file
> name is not equal. This results in a failing build with an error instead.
> I've tested it in both with Maven 3 and Maven 4 and both new release (3.3.0)
> and previous release (3.2.1) with the same results, so no regression in 3.3.0.
> 1. Run integration test against mismatch in content, only logs warning but
> build fails
> {code:java}
> ➜ mvn clean verify -f repro/pom.xml
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> [WARNING] Version not locked for default bindings plugins
> [maven-resources-plugin, maven-archetype-plugin], you should define versions
> in pluginManagement section of your pom.xml or parent
> [WARNING] Property ignoreEOLStyle was not set - files will be compared
> considering their EOL style!
> [WARNING] Property ignoreEOLStyle was not set - files will be compared
> considering their EOL style!
> [WARNING] Contents of file src/main/java/com/example/App.java are not equal
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.3.0:integration-test
> (default-integration-test) on project repro:
> [ERROR] Archetype IT 'integration-test-1' failed: Some content are not equals
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> 2. Rename a file in the reference project
> {code:java}
> ➜ mv
> repro/src/test/resources/projects/integration-test-1/reference/src/main/java/com/example/App.java
>
> repro/src/test/resources/projects/integration-test-1/reference/src/main/java/com/example/SomeApp.java
> {code}
> 3. Build fails with an error instead of warning
> {code:java}
> ➜ mvn clean verify -f repro/pom.xml
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> [WARNING] Version not locked for default bindings plugins
> [maven-resources-plugin, maven-archetype-plugin], you should define versions
> in pluginManagement section of your pom.xml or parent
> [ERROR] Not contained src/main/java/com/example/SomeApp.java
> [ERROR] Remains [src/main/java/com/example/App.java]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.3.0:integration-test
> (default-integration-test) on project repro:
> [ERROR] Archetype IT 'integration-test-1' failed: Reference and generated
> project differs (missing: 1, unexpected: 1)
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-536) AptParser does not force linebreak in Sink after a comment is written
[
https://issues.apache.org/jira/browse/DOXIA-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887231#comment-17887231
]
Michael Osipov commented on DOXIA-536:
--
[~kwin], you are looking for this one.
> AptParser does not force linebreak in Sink after a comment is written
> -
>
> Key: DOXIA-536
> URL: https://issues.apache.org/jira/browse/DOXIA-536
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Apt
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Minor
> Labels: intern
>
> Consider this comment block:
> {noformat}
> ~~ Copyright 2012 Michael Osipov
> ~~
> ~~ Licensed under the Apache License, Version 2.0 (the "License");
> ~~ you may not use this file except in compliance with the License.
> ~~ You may obtain a copy of the License at
> ~~
> ~~ http://www.apache.org/licenses/LICENSE-2.0
> ~~
> ~~ Unless required by applicable law or agreed to in writing, software
> ~~ distributed under the License is distributed on an "AS IS" BASIS,
> ~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> ~~ See the License for the specific language governing permissions and
> ~~ limitations under the License.
> {noformat}
> Apt's comment syntax goes to the end of the line which would mean that if the
> {{AptParser}} hits a comment it has to create a line break with the target
> {{Sink}} too. Unfortunately, the result in, e.g., HTML is:
> {noformat}
>
> {noformat}
> This is ugly doesn't make the comment readible at all. Investigate how we can
> send a {{line.separator}}, i.e., pretty-print the output.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (ARCHETYPE-680) Integration test should report ERROR instead of WARNING when failing
[
https://issues.apache.org/jira/browse/ARCHETYPE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated ARCHETYPE-680:
--
Fix Version/s: 3.3.1
> Integration test should report ERROR instead of WARNING when failing
>
>
> Key: ARCHETYPE-680
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-680
> Project: Maven Archetype
> Issue Type: Improvement
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Giovanni van der Schelde
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.3.1
>
> Attachments: repro.zip
>
>
> When you run the integration test goal against a reference project the build
> fails when the content of the file is not equal. However, it is logged as a
> warning, not an error. I'd expect it to be an error just like when the file
> name is not equal. This results in a failing build with an error instead.
> I've tested it in both with Maven 3 and Maven 4 and both new release (3.3.0)
> and previous release (3.2.1) with the same results, so no regression in 3.3.0.
> 1. Run integration test against mismatch in content, only logs warning but
> build fails
> {code:java}
> ➜ mvn clean verify -f repro/pom.xml
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> [WARNING] Version not locked for default bindings plugins
> [maven-resources-plugin, maven-archetype-plugin], you should define versions
> in pluginManagement section of your pom.xml or parent
> [WARNING] Property ignoreEOLStyle was not set - files will be compared
> considering their EOL style!
> [WARNING] Property ignoreEOLStyle was not set - files will be compared
> considering their EOL style!
> [WARNING] Contents of file src/main/java/com/example/App.java are not equal
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.3.0:integration-test
> (default-integration-test) on project repro:
> [ERROR] Archetype IT 'integration-test-1' failed: Some content are not equals
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> 2. Rename a file in the reference project
> {code:java}
> ➜ mv
> repro/src/test/resources/projects/integration-test-1/reference/src/main/java/com/example/App.java
>
> repro/src/test/resources/projects/integration-test-1/reference/src/main/java/com/example/SomeApp.java
> {code}
> 3. Build fails with an error instead of warning
> {code:java}
> ➜ mvn clean verify -f repro/pom.xml
> -Dorg.slf4j.simpleLogger.defaultLogLevel=warn
> [WARNING] Version not locked for default bindings plugins
> [maven-resources-plugin, maven-archetype-plugin], you should define versions
> in pluginManagement section of your pom.xml or parent
> [ERROR] Not contained src/main/java/com/example/SomeApp.java
> [ERROR] Remains [src/main/java/com/example/App.java]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-archetype-plugin:3.3.0:integration-test
> (default-integration-test) on project repro:
> [ERROR] Archetype IT 'integration-test-1' failed: Reference and generated
> project differs (missing: 1, unexpected: 1)
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-686) Bump org.apache.velocity:velocity-engine-core from 2.3 to 2.4
[ https://issues.apache.org/jira/browse/ARCHETYPE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed ARCHETYPE-686. - Resolution: Fixed > Bump org.apache.velocity:velocity-engine-core from 2.3 to 2.4 > - > > Key: ARCHETYPE-686 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-686 > Project: Maven Archetype > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (ARCHETYPE-687) Bump org.codehaus.plexus:plexus-velocity from 2.1.0 to 2.2.0
Slawomir Jaranowski created ARCHETYPE-687: - Summary: Bump org.codehaus.plexus:plexus-velocity from 2.1.0 to 2.2.0 Key: ARCHETYPE-687 URL: https://issues.apache.org/jira/browse/ARCHETYPE-687 Project: Maven Archetype Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: 3.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (ARCHETYPE-687) Bump org.codehaus.plexus:plexus-velocity from 2.1.0 to 2.2.0
[ https://issues.apache.org/jira/browse/ARCHETYPE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed ARCHETYPE-687. - Resolution: Fixed > Bump org.codehaus.plexus:plexus-velocity from 2.1.0 to 2.2.0 > > > Key: ARCHETYPE-687 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-687 > Project: Maven Archetype > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1431) Update org.apache.bcel:bcel to 6.10.0
[ https://issues.apache.org/jira/browse/MSHARED-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MSHARED-1431. - Resolution: Fixed > Update org.apache.bcel:bcel to 6.10.0 > - > > Key: MSHARED-1431 > URL: https://issues.apache.org/jira/browse/MSHARED-1431 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-shared-jar >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-shared-3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1431) Update org.apache.bcel:bcel to 6.10.0
Sylwester Lachiewicz created MSHARED-1431: - Summary: Update org.apache.bcel:bcel to 6.10.0 Key: MSHARED-1431 URL: https://issues.apache.org/jira/browse/MSHARED-1431 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-shared-jar Reporter: Sylwester Lachiewicz Assignee: Sylwester Lachiewicz Fix For: maven-shared-3.1.2 -- 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 o
[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 inde
