Maven 2.x Antrun Plugin

Properties defined in pom <properties> do not propagate to the antrun environment

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 1.4
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Properties defined in pom <properties> do not propagate to the antrun environment.

For example:

<properties>
    <my.property>foo</my.property>
</properties>

Does not get propagate to Ant. While properties defined within the pom will resolve, the properties are not available as an Ant property. So from antrun:

<ant antfile="${pom.basedir}/src/ant/build.xml" dir="${pom.basedir}" inheritAll="true" inheritRefs="true" target="foo"/>

And then the Ant build.xml:

<project>
    <target name="foo">
        <echo>${my.property}</echo>
    </target>
<project>

The output will be:

[echo] ${my.property}

Instead of what it should be:

[echo] foo

The workaround is to delegate to a build.xml file with the ant task and redefine each property that is needed:

<ant antfile="${pom.basedir}/src/ant/build.xml" dir="${pom.basedir}" inheritAll="true" inheritRefs="true" target="foo">
    <property name="my.property" value="${my.property}"/>
</ant>

Issue Links

This issue is duplicated by:
MANTRUN-87 Improve propagation of properties Major Closed
MANTRUN-64 Pass properties through Major Closed
This issue is related to:
MANTRUN-88 Profile properties not handled correctly Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Carlos Sanchez added a comment -

I don't think this was never intended so it's a new feature, not a bug

Show
Carlos Sanchez added a comment - I don't think this was never intended so it's a new feature, not a bug
Hide
Permalink
Jason Dillon added a comment -

A brief chat w/jvl yesterday sounded like there was already a fix somewhere...

But... bug/imporvement/task... I just need it fixed

Show
Jason Dillon added a comment - A brief chat w/jvl yesterday sounded like there was already a fix somewhere... But... bug/imporvement/task... I just need it fixed
Hide
Permalink
Jason Dillon added a comment -

If no fix shows up I can create a patch for it, but was hoping this issue would shed some light on the fix that jason mentioned.

Show
Jason Dillon added a comment - If no fix shows up I can create a patch for it, but was hoping this issue would shed some light on the fix that jason mentioned.
Hide
Permalink
Kenney Westerhof added a comment -

It's impossible to propagate all properties to the called ant buildfile, since only listed properties
are propagated. Most properties are calculated runtime using reflection.

We could make an exception for the <properties> tag for called buildfiles and iterate over
them, but that doesn't solve it ${project.*} properties.

However, <properties> do work for ant tasks embedded in the pom, so the title
of this issue is not correct.

A nice workaround might be to override the ant task, or to ask the ant folks to fix
their Ant task so the PropertyHelper linked to the project is also propagated to
the new project instantiated by the Ant task, when inheritAll="true". It should inherit
ALL properties, wheter they're calculated or not - the script doesn't know that..

Show
Kenney Westerhof added a comment - It's impossible to propagate all properties to the called ant buildfile, since only listed properties are propagated. Most properties are calculated runtime using reflection. We could make an exception for the <properties> tag for called buildfiles and iterate over them, but that doesn't solve it ${project.*} properties. However, <properties> do work for ant tasks embedded in the pom, so the title of this issue is not correct. A nice workaround might be to override the ant task, or to ask the ant folks to fix their Ant task so the PropertyHelper linked to the project is also propagated to the new project instantiated by the Ant task, when inheritAll="true". It should inherit ALL properties, wheter they're calculated or not - the script doesn't know that..
Hide
Permalink
Brett Porter added a comment -

what about if the plugin depended on the maven-artifact-ant antlib (the thin jar + transitive deps, not the fat one), and registered that antlib with the project being used (if possible), and the project's pom with the antlib (which is possible)? This would mean they can use those tasks from the script.

Show
Brett Porter added a comment - what about if the plugin depended on the maven-artifact-ant antlib (the thin jar + transitive deps, not the fat one), and registered that antlib with the project being used (if possible), and the project's pom with the antlib (which is possible)? This would mean they can use those tasks from the script.
Hide
Permalink
Jason Dillon added a comment -

Sorry Kenny, but properties do not actually make it into the ant's execution environment. Properties are only resolved in the pom (tasks embedded in the pom as you noted). BUT, if one of those tasks needs to access a property that was not explicitly passed to it, like what is done with <ant><property name="" .../> which would then use the pom's property resolution mechanism, then that task will not see the value of the property. So the title of the issue is correct.

Show
Jason Dillon added a comment - Sorry Kenny, but properties do not actually make it into the ant's execution environment. Properties are only resolved in the pom (tasks embedded in the pom as you noted). BUT, if one of those tasks needs to access a property that was not explicitly passed to it, like what is done with <ant><property name="" .../> which would then use the pom's property resolution mechanism, then that task will not see the value of the property. So the title of the issue is correct.
Hide
Permalink
Stephane Nicoll added a comment -

I second Jason D. on that. It took me a while to figure out what was happening.

Show
Stephane Nicoll added a comment - I second Jason D. on that. It took me a while to figure out what was happening.
Hide
Permalink
Daniel Takai added a comment -

An easy solution would be to pass only the "important" properties to the ant environment. This would keep you from digging into the wrong code and solve 99% of all problems.

See http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide

Show
Daniel Takai added a comment - An easy solution would be to pass only the "important" properties to the ant environment. This would keep you from digging into the wrong code and solve 99% of all problems. See http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
Hide
Permalink
Gennadij Polikarpov added a comment -

What's about:

pom.xml
<ant target="foo" />
build.xml
<project>
    <target name="foo">
        <echo>${user.home}</echo>
    </target>
<project>
output
[echo] ${user.home}
Show
Gennadij Polikarpov added a comment - What's about:
pom.xml
<ant target="foo" />
build.xml
<project>
    <target name="foo">
        <echo>${user.home}</echo>
    </target>
<project>
output
[echo] ${user.home}
Hide
Permalink
Paul Gier added a comment -

Fixed in r789987

Show
Paul Gier added a comment - Fixed in r789987
Hide
Permalink
Ashish Kumar added a comment -

I am waiting for this fix. This issue has been fixed in trunk long back. But version 1.4 is not released yet. This last release of version 1.3 happened on Oct 11, 2008. So, even after a year wait, new release didn't happen.

Any Idea, when are we going to release v1.4 officially ?

Show
Ashish Kumar added a comment - I am waiting for this fix. This issue has been fixed in trunk long back. But version 1.4 is not released yet. This last release of version 1.3 happened on Oct 11, 2008. So, even after a year wait, new release didn't happen. Any Idea, when are we going to release v1.4 officially ?

People

Vote (18)
Watch (18)

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.