maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@codehaus.org>
Subject [jira] (MSHARED-283) Multiple level filtering not behaving as expected and not consistant behaviour between ${} replacement and @@ replacement
Date Sun, 09 Feb 2014 21:51:57 GMT

     [ 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)

Mime
View raw message