Maven 2 & 3

parent resolution is done first before property interpolation

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 3.0, 2.2.x (to be reviewed)
  • Fix Version/s: None
  • Component/s: Inheritance and Interpolation
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

Possible problems

  • using properties in the parent tag
  • using proeprties in the repositories tag with the parent being unknown except to that repo

Attach is a sample project whose child project does not get built.

Issue Links

This issue duplicates:
MNG-2569 Expressions not evaluated inside <parent> Minor Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jan Palmquist added a comment -

I have a somewhat similar problem, however I guess that the attached example is a bit missleading since the properties supplied in the child pom might not have been examined at the time of <parent>-block evaluation...

Either way, I'm also VERY interested in having properties expanded while evaluating the <parent>-block contents. Even if only properties defined in settings.xml or supplied by -D to the mvn-command will affect the evaluation.

I'm currently working in a project with many active developers. The project is therefore brached into several development tracks - each track being developed 'independently' of the other over a limited period of time. Regularily, the branches are merged back together in order to keep the project aligned over time. This stragegy is necessary in order keep the environment within each branch stable enough for CI to work and developers productive writing code and not struggling with problems that other branches might introduce...

Anyway, keeping the pom-hierarchy (and individual poms) configurable with respect to (in my case) groupIds configurable using parameters would make the recurring merging activities a lot easier...

The current workaround is to let each branch have its own repository and have all developers remember to delete their local repository when they change development track...

Show
Jan Palmquist added a comment - I have a somewhat similar problem, however I guess that the attached example is a bit missleading since the properties supplied in the child pom might not have been examined at the time of <parent>-block evaluation... Either way, I'm also VERY interested in having properties expanded while evaluating the <parent>-block contents. Even if only properties defined in settings.xml or supplied by -D to the mvn-command will affect the evaluation. I'm currently working in a project with many active developers. The project is therefore brached into several development tracks - each track being developed 'independently' of the other over a limited period of time. Regularily, the branches are merged back together in order to keep the project aligned over time. This stragegy is necessary in order keep the environment within each branch stable enough for CI to work and developers productive writing code and not struggling with problems that other branches might introduce... Anyway, keeping the pom-hierarchy (and individual poms) configurable with respect to (in my case) groupIds configurable using parameters would make the recurring merging activities a lot easier... The current workaround is to let each branch have its own repository and have all developers remember to delete their local repository when they change development track...
Hide
Permalink
Marco Lessard added a comment -

Using maven 2.0.8, we still have the problem with the <parent> tag.
<parent>
<groupId>com.mycompany.odp</groupId>
<artifactId>ocs-core</artifactId>
<version>${ocs.release.version}</version>
</parent>

Properties in "project.parent.version" do NOT get substituted but properties in "project.version" do.
We are on the process of migrating our 900 artifacts project to maven. Most of those artifacts will share the same release version and inherit from the same parent, so it is out of question to do a "search and replace".

Looks like a substitution bug to me.
For the moment, it is a show stopper for us that blocks the migration of our 900 artifacts.

Show
Marco Lessard added a comment - Using maven 2.0.8, we still have the problem with the <parent> tag. <parent> <groupId>com.mycompany.odp</groupId> <artifactId>ocs-core</artifactId> <version>${ocs.release.version}</version> </parent> Properties in "project.parent.version" do NOT get substituted but properties in "project.version" do. We are on the process of migrating our 900 artifacts project to maven. Most of those artifacts will share the same release version and inherit from the same parent, so it is out of question to do a "search and replace". Looks like a substitution bug to me. For the moment, it is a show stopper for us that blocks the migration of our 900 artifacts.
Hide
Permalink
Brett Porter added a comment -

see MNG-624

Show
Brett Porter added a comment - see MNG-624

People

Vote (11)
Watch (9)

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.