[
https://jira.codehaus.org/browse/MSHARED-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323361#comment-323361
]
David Jones commented on MSHARED-283:
-------------------------------------
After debugging through the code I found the source of the problem.
The problem is caused by the fact that PropertyUtils.loadPropertyFile() already
does some *pre*-filtering.
For each loaded property it calls PropertyUtils.getPropertyValue().
This method resolves properties in the format $\{\*\}.
This is done irrespective of whether or not $\{\*\} is being used as a
delimiter or not, and this is being done *before* loading the other property
file(s) which *may* overwrite some of those properties.
Properties in the format @\*@ are not being replaced at this time (and neither
are any other properties with custom delimiters which the user may define).
I commented out the following lines from PropertyUtils to remove this
pre-filtering during property file loading:
{code:borderStyle=solid}
// for ( Iterator iter = fileProps.keySet().iterator(); iter.hasNext(); )
// {
// final String k = (String) iter.next();
// final String propValue = getPropertyValue( k, combinedProps );
// fileProps.setProperty( k, propValue );
// }
{code}
After doing this my test passed.
I do not know what the original intention of having this pre-filtering in
PropertyUtils was. However it seems suspect to me that this class is performing
pre-filtering before all properties are loaded and without taking the
configured delimiters into account and without taking overwritten properties
into account.
By removing the lines above I broke 4 other tests cases, 3 in PropertyUtilsTest
as well as testMultiFilterFileInheritance in DefaultMavenFileFilterTest.
However I believe these tests are in themselves unit testing logic which should
not be there and which should be done by done by DefaultMavenResourcesFiltering
after the properties have been loaded
> Multiple level filtering not behaving as expected and not consistant
> behaviour between ${} replacement and @@ replacement
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: MSHARED-283
> URL: https://jira.codehaus.org/browse/MSHARED-283
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-filtering
> Affects Versions: maven-filtering-1.1
> Reporter: David Jones
> Attachments: maven-filtering-test-case.diff
>
>
> Filter (defined in a property file) can be composed of other properties as
> shown in myproperty1 and myproperty2 below:
> part1=part1
> part2=part2
> myproperty1=${part1}-${part2}
> myproperty2=@part1@-@part2@
> It is possible to define a second filter file to overwrite some properties:
> part1=part1OVERWRITE
> When filtering using the two filter files the resulting value of myproperty1
> and myproperty2 should be as follows:
> myproperty1=part1OVERWRITE-part2
> myproperty2=part1OVERWRITE-part2
> It is expected that the composite property should take the overwritten part1
> from the second property file while part2 should be taken from the first
> property file.
> In addition the choice of delimeter @@ vs ${*} should not have any effect on
> the behaviour.
> However tests have shown that myproperty2 is being replaced correctly while
> myproperty1 is NOT.
> MRESOURCES-157 also demonstrates this with a maven project which tests the
> same thing.
> The attached patch file (maven-filtering-test-case.diff) adds a new test
> (which currently fails) which demonstrates the issue described
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
