maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miroslav Zaťko (JIRA) <j...@apache.org>
Subject [jira] [Updated] (MPOM-139) maven profile activation in child poms using variable profile.parent.artifactId doesn't work
Date Wed, 12 Oct 2016 22:28:20 GMT

     [ https://issues.apache.org/jira/browse/MPOM-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Miroslav Zaťko updated MPOM-139:
--------------------------------
    Description: 
I created a profile activated using property "profile.parent.artifactId" in parent pom so
I expected it will be active in child(module) executions. It doesn't work even when its value
is as expected
{noformat}
<profile>
         <activation>
            <property>
               <name>project.parent.artifactId</name>
               <value>my_parent_artifactId</value>
            </property>
         </activation>
.........
<profile>
{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working in child(module)
executions:
{noformat}
<profile>
         <activation>
            <file><exists>${basedir}/../pom.xml</exists></file>
         </activation>
.........
<profile>
{noformat}

simple project showing this bug set at https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not set, so "this
is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to "parent", as
we can see in output, so activation condition for profile "profile" is met. Anyway, it is
not activated and "this is default execution" echoed again. In this step "this is profile
execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or deactivated at
very beginning of build process, not for each module separately. However, now we can change
directory to child and will see same behavior when starting from child module. This is definitely
a bug.

Correct behavior we can see if we switch to branch fileactivation... BTW. it means my assumption
about "profiles are activated or deactivated at very beginning of build process" was not correct...

  was:
I created a profile activated using property "profile.parent.artifactId" in parent pom so
I expected it will be active in child(module) executions. It doesn't work even when its value
is as expected
{noformat}
<profile>
         <activation>
            <property>
               <name>project.parent.artifactId</name>
               <value>my_parent_artifactId</value>
            </property>
         </activation>
.........
<profile>
{noformat}
Anyway, activation using file+exists, again defined in parent pom, is working in child(module)
executions:
{noformat}
<profile>
         <activation>
            <file><exists>${basedir}/../pom.xml</exists></file>
         </activation>
.........
<profile>
{noformat}

simple project showing this bug set at https://github.com/mireczatko/maven-bug.git

{{mvn validate}}

*1st* round: parent is build, property {{project.parent.artifactId}} is not set, so "this
is default execution"  echoed by maven-antrun-plugin is correct
*2nd* round: child is build, property {{project.parent.artifactId}} is set to "parent", as
we can see in output, so activation condition for profile "profile" is met. Anyway, it is
not activated and "this is default execution" echoed again. In this step "this is profile
execution" should be echoed

This would be obvious (even not expected) assuming profiles are activated or deactivated at
very beginning of build process, not for each module separately. However, now we can change
directory to child and will see same behavior when starting from child module. This is definitely
a bug.


> maven profile activation in child poms using variable profile.parent.artifactId doesn't
work
> --------------------------------------------------------------------------------------------
>
>                 Key: MPOM-139
>                 URL: https://issues.apache.org/jira/browse/MPOM-139
>             Project: Maven POMs
>          Issue Type: Bug
>          Components: maven
>            Reporter: Miroslav Zaťko
>
> I created a profile activated using property "profile.parent.artifactId" in parent pom
so I expected it will be active in child(module) executions. It doesn't work even when its
value is as expected
> {noformat}
> <profile>
>          <activation>
>             <property>
>                <name>project.parent.artifactId</name>
>                <value>my_parent_artifactId</value>
>             </property>
>          </activation>
> .........
> <profile>
> {noformat}
> Anyway, activation using file+exists, again defined in parent pom, is working in child(module)
executions:
> {noformat}
> <profile>
>          <activation>
>             <file><exists>${basedir}/../pom.xml</exists></file>
>          </activation>
> .........
> <profile>
> {noformat}
> simple project showing this bug set at https://github.com/mireczatko/maven-bug.git
> {{mvn validate}}
> *1st* round: parent is build, property {{project.parent.artifactId}} is not set, so "this
is default execution"  echoed by maven-antrun-plugin is correct
> *2nd* round: child is build, property {{project.parent.artifactId}} is set to "parent",
as we can see in output, so activation condition for profile "profile" is met. Anyway, it
is not activated and "this is default execution" echoed again. In this step "this is profile
execution" should be echoed
> This would be obvious (even not expected) assuming profiles are activated or deactivated
at very beginning of build process, not for each module separately. However, now we can change
directory to child and will see same behavior when starting from child module. This is definitely
a bug.
> Correct behavior we can see if we switch to branch fileactivation... BTW. it means my
assumption about "profiles are activated or deactivated at very beginning of build process"
was not correct...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message