Maven 2 & 3

Properties defined in top-level profiles.xml do no propagate to child modules

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Won't Fix
  • Affects Version/s: 2.0.2
  • Fix Version/s: None
  • Component/s: POM
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

I have a multi-module build, and at the top-level I have a profile called 'release-environment', which is activated by -Denv=release.

I need the local release build to use different values for JDBC configuration to run integration tests, and defined them in a profiles.xml:

<?xml version="1.0" encoding="UTF-8"?>

<settings>

    <profiles>
        <profile>
            <id>local-release-environment</id>
            <activation>
                <property>
                    <name>env</name>
                    <value>release</value>
                </property>
            </activation>
            
            <properties>
                <jdbc.username>mif_jason</jdbc.username>
                <jdbc.password>mif_jason</jdbc.password>
                <jdbc.schema>MIF_JASON</jdbc.schema>
            </properties>
        </profile>
    </profiles>
    
</settings>

My project looks like:

pom.xml
merchant/pom.xml
merchant/core/pom.xml
merchant/services/pom.xml

If i put profiles.xml as a peer to pom.xml and run mvn clean install -Denv=release from the top-level, I get errors because the properties are not propagated to the merchant/core/pom.xml module.

If I put profiles.xml as a peer to merchant/core/pom.xml and run mvn clean install -Denv=release, then it works as expected... properties are set as they are defined in profiles.xml.

But, this is not manageable, as I need to set some properties for all of the modules in a multi-module build... But I don't want to use those properties for all Maven2 projects, so I can not really put it into ~/.m2/settings.xml

I had expected that a top-level profiles.xml would work, but it does not. Is this by design, is there another recommend way to provide per-top-level multi-module project configuration on a local user basis (ie. no pom.xml modifications)?

Issue Links

This issue is duplicated by:
MNG-2982 Profile of a pom doesn't execute when running a reactor build of a child pom Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Emanuel Bulic added a comment -

I am seeing a similar problem, related to this, but slightly different. My project looks like this:

app/pom.xml – root pom
app/profiles.xml
app/java/pom.xml - also a pom
app/java/project1/pom.xml – a jar project
app/java/project2/pom.xml – also jar

If I build from app, the properties are defined. They are also defined when I build from project1 or project2, however, if I decide to build from java, the profiles are not loaded. I had to move my profiles into ~/.m2/settings.xml; I don't believe they belong there, since they are project scoped variables, and are not applicable to my plugins project, for example. We also build our app project from multiple branches, each branch requires it's own profiles. We define various paths that are different between branches.

Show
Emanuel Bulic added a comment - I am seeing a similar problem, related to this, but slightly different. My project looks like this: app/pom.xml – root pom app/profiles.xml app/java/pom.xml - also a pom app/java/project1/pom.xml – a jar project app/java/project2/pom.xml – also jar If I build from app, the properties are defined. They are also defined when I build from project1 or project2, however, if I decide to build from java, the profiles are not loaded. I had to move my profiles into ~/.m2/settings.xml; I don't believe they belong there, since they are project scoped variables, and are not applicable to my plugins project, for example. We also build our app project from multiple branches, each branch requires it's own profiles. We define various paths that are different between branches.
Hide
Permalink
Laurent Dauvilaire added a comment -

I have the same problem with version 2.0.4
The properties defined into the top level profiles.xml are not propagated to the child sub-modules.
When maven is started from the child sub-modules directory, then the properties are correctly retrieved.
I seems the problem is into the descending inheritance but not into the ascending inheritance.

Show
Laurent Dauvilaire added a comment - I have the same problem with version 2.0.4 The properties defined into the top level profiles.xml are not propagated to the child sub-modules. When maven is started from the child sub-modules directory, then the properties are correctly retrieved. I seems the problem is into the descending inheritance but not into the ascending inheritance.
Hide
Permalink
Tim Morrow added a comment -

I experienced the same problem. But I worked around the problem by putting my profiles definitions in the parent pom.xml. Thus they are inherited by all sub-projects. Yes, it clutters up the pom.xml, but avoids settings.xml.

Show
Tim Morrow added a comment - I experienced the same problem. But I worked around the problem by putting my profiles definitions in the parent pom.xml. Thus they are inherited by all sub-projects. Yes, it clutters up the pom.xml, but avoids settings.xml.
Hide
Permalink
Carsten Karkola added a comment -

We have encountered the same problem. putting some profile values in the pom.xml is ok for values shared by all developers. But we have profile variables with individual values for the different developers. If somebody wants to change a variable for himself, he has to check out the pom.xml (what I'd like to avoid, especially in branches/parallel releases). Is there any fix available for this profile.xml issue?

Show
Carsten Karkola added a comment - We have encountered the same problem. putting some profile values in the pom.xml is ok for values shared by all developers. But we have profile variables with individual values for the different developers. If somebody wants to change a variable for himself, he has to check out the pom.xml (what I'd like to avoid, especially in branches/parallel releases). Is there any fix available for this profile.xml issue?
Hide
Permalink
Magnus Heino added a comment -

Properties seems to propagate to child modules if they have the same groupId.

Show
Magnus Heino added a comment - Properties seems to propagate to child modules if they have the same groupId.
Hide
Permalink
Dimo Velev added a comment -

Are you planning on ever fixing this issue? It has been around for over 3 years...

Show
Dimo Velev added a comment - Are you planning on ever fixing this issue? It has been around for over 3 years...
Hide
Permalink
Paul Benedict added a comment -

Since profiles.xml is not supported in Maven 3, I do not think this issue will make further progress.

Show
Paul Benedict added a comment - Since profiles.xml is not supported in Maven 3, I do not think this issue will make further progress.
Hide
Permalink
Abhishekh Padmanbhan added a comment - - edited

I think I might have a workaround/solution to this problem using a profiles.xml (MAVEN 2.1.0) in the root project that holds the project current version as a property. This property then can be used as a value to the version in the parent tag definition in all its sub modules.

Find below the workaround that I use to propagate the project version variable as a property to all of the project submodule. By doing this I avoid having to redefine the project parent pom version in all its submodules.

PROJECT STRUCTURE (all caps are modules)

ROOT

  • pom.xml
  • profiles.xml
  • WAR
    • pom.xml
  • EJB
    • pom.xml

ROOT/profiles.xml

<profilesXml>
<profiles>
    <profile>
      <id>projectProfile</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
         <currentVersion>1.0.1</currentVersion>
      </properties>
    </profile>
</profiles>
</profilesXml>

ROOT/pom.xml

<project>
  <groupId>projGrp</groupId>
  <artifactId>rootProjName</artifactId>
  <version>${currentVersion}</version>
</project>

ROOT/EJB/pom.xml

<project>
  <artifactId>ejbProjName</artifactId>
  <packaging>ejb</packaging>
  <parent>
	<groupId>projGrp</groupId>
	<artifactId>rootProjName</artifactId>
	<version>${currentVersion}</version>
  </parent>
</project>

I think this way the project version is a property just in one file profiles.xml in the ROOT project and will be the only file that changes when the version changes.

I have not tested this exhaustively but seems to work in principle.

Show
Abhishekh Padmanbhan added a comment - - edited I think I might have a workaround/solution to this problem using a profiles.xml (MAVEN 2.1.0) in the root project that holds the project current version as a property. This property then can be used as a value to the version in the parent tag definition in all its sub modules. Find below the workaround that I use to propagate the project version variable as a property to all of the project submodule. By doing this I avoid having to redefine the project parent pom version in all its submodules. PROJECT STRUCTURE (all caps are modules) ROOT
  • pom.xml
  • profiles.xml
  • WAR
    • pom.xml
  • EJB
    • pom.xml
ROOT/profiles.xml 
<profilesXml>
<profiles>
    <profile>
      <id>projectProfile</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
         <currentVersion>1.0.1</currentVersion>
      </properties>
    </profile>
</profiles>
</profilesXml>
ROOT/pom.xml 
<project>
  <groupId>projGrp</groupId>
  <artifactId>rootProjName</artifactId>
  <version>${currentVersion}</version>
</project>
ROOT/EJB/pom.xml 
<project>
  <artifactId>ejbProjName</artifactId>
  <packaging>ejb</packaging>
  <parent>
	<groupId>projGrp</groupId>
	<artifactId>rootProjName</artifactId>
	<version>${currentVersion}</version>
  </parent>
</project>
I think this way the project version is a property just in one file profiles.xml in the ROOT project and will be the only file that changes when the version changes. I have not tested this exhaustively but seems to work in principle.
Hide
Permalink
Dimo Velev added a comment -

Hi Abshishek,

thank you for comment.

Actually, my question was not whether it is possible or not - the parent profile does definitely NOT get picked up when you build one of the child modules. So in your case if you run mvn package in e.g. the EJB module maven is not going to read the profiles.xml of your parent project. Unfortunately, the maven developers seem not to want to implement it this way for their reasons.

Best regards
Dimo

Show
Dimo Velev added a comment - Hi Abshishek, thank you for comment. Actually, my question was not whether it is possible or not - the parent profile does definitely NOT get picked up when you build one of the child modules. So in your case if you run mvn package in e.g. the EJB module maven is not going to read the profiles.xml of your parent project. Unfortunately, the maven developers seem not to want to implement it this way for their reasons. Best regards Dimo

People

Vote (20)
Watch (21)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.