maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jones (JIRA)" <j...@codehaus.org>
Subject [jira] (MSHARED-283) Multiple level filtering not behaving as expected and not consistant behaviour between ${} replacement and @@ replacement
Date Mon, 08 Apr 2013 12:00:52 GMT

    [ 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

Mime
View raw message