Bug 46117 - Append property prefix to entries in property file values
Summary: Append property prefix to entries in property file values
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.1
Hardware: PC Windows XP
: P2 enhancement (vote)
Target Milestone: 1.8.2
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-29 01:57 UTC by Remie Bolte
Modified: 2010-08-21 03:57 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Remie Bolte 2008-10-29 01:57:29 UTC
This enhancement request is based on the use case of depending products and re-using property files.

Picture a scenario in which you have product A and product B. Both have property files (A.properties and B.properties):

[A.properties]
product.name=Product A
product.version=1.0.0
product.publish.dir=c:\publish\${product.name}\${product.version}
product.publish.file=${product.publish.dir}/${product.name}.${product.version}.zip

[B.properties]
product.name=Product B
product.version=1.0.1
product.publish.dir=c:\publish\${product.name}\${product.version}
product.publish.file=${product.publish.dir}/${product.name}.${product.version}.zip

Now let's say product B has a dependency on product A. It needs to consume files that are placed in the publish directory of product A.

So we include the property file of product A and prefix it with "A". This means we can have access to the product.publish.dir value using: ${A.product.publish.dir}

The problem is that ${A.product.publish.dir} uses the ${product.name} and ${product.version}. So in the following scenario:

<property file="B.properties" />
<property file="A.properties" prefix="A" />

The value of ${A.product.publish.dir} is actually

c:\publish\Product B\1.0.1\

It would be nice if it is possible to also prefix all properties that are used within the property file. This would make the use of the prefix attribute more compelling.

Of course there are workarounds to this situation:
A) have the prefix by design
B) copy and manipulate the property file using replace.

Therefore it should be considered as an enhancement.
Comment 1 Stefan Bodewig 2008-10-29 04:32:31 UTC
just offering another workaround: use loadproperties instead of the property task and implement your manipulations as a filter(chain).
Comment 2 Matt Benson 2008-10-29 07:53:02 UTC
Personally this seems to violate the principle of least surprise.  I would think one would expect "internal" substitutions to work properly independently of prefix decoration.  At the same time, when we get this fixed I would expect the change to fall into the "possibly breaking changes" section of WHATSNEW.
Comment 3 Remie Bolte 2008-10-29 08:01:11 UTC
I agree that there is a conceptual problem with replacing nested properties. I would see it as an added feature instead of default behavior. 

The suggested workaround of loadproperties with a filterchain would actually work for me. I'm fine with having a default "property" task with the least surprise and a more advanced "loadproperties" that allows manipulation.

However, the workaround of using the loadproperties with a filterchain / replacetokens currently doesn't seem to work for me. The prefixlines works fine, but the replace either doesn't take place, or it takes place after the properties have been resolved and registered (either way not working).

I'm using ant 1.7.0 to test the loadproperties workaround, I will try it with 1.7.1 tomorrow.




Comment 4 Owen Nichols 2010-08-20 12:34:02 UTC
it looks like this has been fixed in ant 1.8.2 by the introduction of the prefixValues attributes
Comment 5 Stefan Bodewig 2010-08-21 03:57:47 UTC
Yes, Owen, you are correct.