[
https://jira.codehaus.org/browse/MANTRUN-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315687#comment-315687
]
Darryl L. Miles edited comment on MANTRUN-177 at 12/14/12 3:50 AM:
-------------------------------------------------------------------
A quick look from my point of view you are setting the property:
<property name="filters.file" value="../filters/filters.pc.properties"/>
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as <build><filters><filter> I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering. You
have only configured the property at a lower (more nested) scope than the place
where it is being used. Each plugin has its own scope the <property ... /> is
used by antrun/ANT not by maven.
Why don't you setup a pom.xml section:
<project>
<properties>
<filter.file>../filters/filters.pc.properties</filter.file>
</properties>
</project>
and remove the <property ..../> element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on <properties> sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.abc.efg.filter.file'
was (Author: dlmiles):
A quick look from my point of view you are setting the property:
<property name="filters.file" value="../filters/filters.pc.properties"/>
For the execution of the maven-antrun-plugin only. But you have it configured
in the pom.xml as <build><filters><filter> I am sure this behavior was not
supported even in Maven 2.x it happened to work by chance not engineering.
Why don't you setup a pom.xml section:
<project>
<properties>
<filter.file>../filters/filters.pc.properties</filter.file>
</properties>
</project>
and remove the <property ..../> element from the antrun configuration
completely ? what would be wrong with that ? the path being used is setup is
still configured in the same pom.xml file.
The only side-effect I can think up is that any children pom's would inherit
the value, but maybe there is a way to inhibit that? check maven documentation
on <properties> sections. Or simply use a name that will never clash change
'filter.file' for 'local.project.abc.efg.filter.file'
> Ant properties not passed to maven 3.0.4
> ----------------------------------------
>
> Key: MANTRUN-177
> URL: https://jira.codehaus.org/browse/MANTRUN-177
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
> Affects Versions: 1.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 01:44:56-0700)
> Java version: 1.6.0_34, vendor: Sun Microsystems Inc.
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Reporter: Paul Gazda
> Attachments: build.log, pom.xml_test
>
>
> I have a pom.xml that uses maven-antrun-plugin v 1.7 in phase "validate"
> to detect the run environment, and based on that set the appropriate
> filters file path as property "filters.file". exportAntProperties is set to
> true. The filters.file property is supposed to be used in the filters tag
> like this:
> <build>
> <filters>
> <filter>${filters.file}</filter>
> </filters>
> .
> .
> .
> This worked when I was using maven 2.2.1, but since I upgraded to maven
> 3.0.4, the value for filters.file is no longer being passed to the <filter>
> tag.
> I have attached a test pom.xml I created to demonstrate the problem. If "mvn
> install" is run with maven 2.2.1, the value for ${filters.file} is passed to
> maven (the install will fail after this because it is a dummy test, but it is
> clear that the ${filters.file} value has been passed correctly). If I run it
> with maven 3.0.4, the value for ${filters.file} is not passed to maven. I
> have attached and the maven build log from the failed 3.0.4 "mvn install".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
