[
https://jira.codehaus.org/browse/MSHARED-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MSHARED-283:
-----------------------------------
Description:
Filter (defined in a property file) can be composed of other properties as
shown in myproperty1 and myproperty2 below:
{noformat}
part1=part1
part2=part2
myproperty1=${part1}-${part2}
myproperty2=@part1@-@part2@
{noformat}
It is possible to define a second filter file to overwrite some properties:
{noformat}
part1=part1OVERWRITE
{noformat}
When filtering using the two filter files the resulting value of myproperty1
and myproperty2 should be as follows:
{noformat}
myproperty1=part1OVERWRITE-part2
myproperty2=part1OVERWRITE-part2
{noformat}
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
was:
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
> 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, MSHARED-283.patch,
> MSHARED-283-v2.patch
>
>
> Filter (defined in a property file) can be composed of other properties as
> shown in myproperty1 and myproperty2 below:
> {noformat}
> part1=part1
> part2=part2
> myproperty1=${part1}-${part2}
> myproperty2=@part1@-@part2@
> {noformat}
> It is possible to define a second filter file to overwrite some properties:
> {noformat}
> part1=part1OVERWRITE
> {noformat}
> When filtering using the two filter files the resulting value of myproperty1
> and myproperty2 should be as follows:
> {noformat}
> myproperty1=part1OVERWRITE-part2
> myproperty2=part1OVERWRITE-part2
> {noformat}
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)
