You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2010/06/17 17:10:29 UTC
what to expand?
Hi,
when we have a file x.properties file like
x=x
y=${x}
and
<property name="x" value="y"/>
<property file="x.properties"/>
the ${y} will end up being "y", which is fine - properties are
immutable.
If you use
<property file="x.properties" prefix="foo"/>
instead, Ant 1.8.0 will set ${foo.y} to "y" as well as it doesn't apply
the prefix when expanding ${x}. Ant 1.8.1 uses the prefix when
expanding ${x} inside the file and thus expands ${foo.y} to "x" which
makes sense in that it makes the property file self-contained.
There is an open bug report against 1.8.1 that wants the old behavior
back <https://issues.apache.org/bugzilla/show_bug.cgi?id=49373>.
Locally I have a version of trunk that reinstates 1.8.0's behavior, but
that same version breaks the AntUnit tests for <loadproperties> with a
prefix attribute because the 1.8.1 way is explicitly expected here.
We don't have any documentation either way.
I see the following choices:
(1) embrace <loadproperties prefix="..."/> way for <property file> as
well and document it as a breaking change that already occured in
1.8.1
(2) make <loadproperties> prefix useless, remove it again, make
<loadproperties> match <property file> of Ant 1.8.0 and earlier.
(3) allow different behavior of the tasks and document it.
I can't say I'd like either of the three choices too much, maybe anybody
sees a different option. (1) looks most attractive to me but there
doesn't seem to be a workaround if you want the old behavior back.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-21, Dominique Devienne wrote:
> On Mon, Jun 21, 2010 at 2:18 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> loadproperties already can.
>> [...]
>> <loadproperties>
>> <filterchain>
>> <prefixlines prefix="foo."/>
>> </filterchain>
>> </loadproperties>
>> you get
>> foo.y=${x}
> Well <filterchain> likely applies on the property file "text", not its
> "infoset", so will prefix comments and continuation lines as well,
> leading to an possibly incorrect file or changed property values.
Of course.
> My propsed ${.:x} allows the property-file-writer to be in control,
> and if we separated the prefix attribute for property writes and
> property reads, providing a read "search resolution path" to allow
> either read local unprefixed first, then local prefixed, then global,
> the build-file-writer is in control, and the various permutations of
> those 3, that should cover all possible situations.
You are correct. The question what the default should be still remains,
though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Dominique Devienne <dd...@gmail.com>.
On Mon, Jun 21, 2010 at 2:18 AM, Stefan Bodewig <bo...@apache.org> wrote:
> loadproperties already can.
> [...]
> <loadproperties>
> <filterchain>
> <prefixlines prefix="foo."/>
> </filterchain>
> </loadproperties>
>
> you get
> foo.y=${x}
Well <filterchain> likely applies on the property file "text", not its
"infoset", so will prefix comments and continuation lines as well,
leading to an possibly incorrect file or changed property values. So
it's not quite a general solution. My propsed ${.:x} allows the
property-file-writer to be in control, and if we separated the prefix
attribute for property writes and property reads, providing a read
"search resolution path" to allow either read local unprefixed first,
then local prefixed, then global, the build-file-writer is in control,
and the various permutations of those 3, that should cover all
possible situations. I'm not sure this is that high priority though.
Just my $0.02. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-18, Bruce Atherton wrote:
> I would argue for the opposite (although I don't know how practical it
> is). Would it be possible for loadproperties to not only prefix the
> properties that are defined, but also the properties to be expanded?
> So "y=${x}" becomes "foo.y=${foo.x}"?
loadproperties already can.
With
y=${x}
and
<loadproperties ... prefix="foo"/>
you get
foo.y=${foo.x}
and with
<loadproperties>
<filterchain>
<prefixlines prefix="foo."/>
</filterchain>
</loadproperties>
you get
foo.y=${x}
It is <property>'s behavior that doesn't provide the same control and
where we have had changes between the past three Ant releases.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Bruce Atherton <br...@callenish.com>.
On 18/06/2010 7:48 AM, Dominique Devienne wrote:
> On Fri, Jun 18, 2010 at 2:47 AM, Stefan Bodewig<bo...@apache.org> wrote:
>
>> On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
>> Assume
>>
>> x=x
>> y=${x}
>>
>> and that there is no property x defined prior to
>>
>> <property file="..."/>
>>
>> then ${y} will be "x". Using
>>
>> <property file="..." prefix="foo"/>
>>
>> ${foo.y} in Ant 1.8.0 is ${x} while it is "x" in 1.8.1 - the properties
>> file was able to refer to its own properties without knowledge of the
>> prefix.
>>
> This feels "natural" to me, and ${foo.y}'s value being "${x}" surprising indeed.
>
I agree.
> But conversely, if property x is already defined, I'd expect that
> value to prevail, according to classic immutability rules.
>
I'm not sure I agree with this. If foo.x was previously defined I'd
expect its value to prevail, but x? That doesn't make sense to me, since
foo.y is really being set to foo.x as far as the build file is concerned.
> Can't property expansion in a property file be done "entirely" before
> the prefix is applied?
>
I would argue for the opposite (although I don't know how practical it
is). Would it be possible for loadproperties to not only prefix the
properties that are defined, but also the properties to be expanded? So
"y=${x}" becomes "foo.y=${foo.x}"?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-18, Dominique Devienne wrote:
> On Fri, Jun 18, 2010 at 2:47 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
>> Assume
>> x=x
>> y=${x}
>> and that there is no property x defined prior to
>> <property file="..."/>
>> then ${y} will be "x". Using
>> <property file="..." prefix="foo"/>
>> ${foo.y} in Ant 1.8.0 is ${x} while it is "x" in 1.8.1 - the properties
>> file was able to refer to its own properties without knowledge of the
>> prefix.
> This feels "natural" to me, and ${foo.y}'s value being "${x}"
> surprising indeed. But conversely, if property x is already defined,
> I'd expect that value to prevail, according to classic immutability
> rules. Yet as you point out we can't have both behaviors at the same
> time if I understand correctly.
${x} wins over ${foo.x} is the behavior we used to have - and what the
bugzilla report wants back. It's not what loadproperties does, though.
The question is whether we want the tasks to be consistent and if so,
what we want them to do.
It comes down to what the writer of the property file intended. If I
want my property file to be self-contained, then I want Ant to rewrite
the references. As soon as Ant does that I either lose access to
properties defined outside the file (the canonical ${build.dir} example)
or we get a more complex logic of "is the property defined outside the
file, use the outside value, otherwise use the one inside - which I have
working locally.
<loadproperties> makes that choice explicit right now. If I want my
file to be self-contained, I use the prefix attribute and all expansions
will be rewritten by Ant. If I don't want this to happen, I don't use
the prefix attribute but a a prefixlines filter to my filterchain which
just adds the prefix to each newly defined property.
Not that this effect was documented anywhere 8-)
> Can't property expansion in a property file be done "entirely" before
> the prefix is applied?
Not without breaking property immutability in specific cases.
> Another impractical idea quite likely, but what about a ${.:x}
> notation, to force the expansion of propery x to point to the "local"
> context, taking the prefix into account?
Could work.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Dominique Devienne <dd...@gmail.com>.
On Fri, Jun 18, 2010 at 2:47 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
> Assume
>
> x=x
> y=${x}
>
> and that there is no property x defined prior to
>
> <property file="..."/>
>
> then ${y} will be "x". Using
>
> <property file="..." prefix="foo"/>
>
> ${foo.y} in Ant 1.8.0 is ${x} while it is "x" in 1.8.1 - the properties
> file was able to refer to its own properties without knowledge of the
> prefix.
This feels "natural" to me, and ${foo.y}'s value being "${x}" surprising indeed.
But conversely, if property x is already defined, I'd expect that
value to prevail, according to classic immutability rules.
Yet as you point out we can't have both behaviors at the same time if
I understand correctly.
Can't property expansion in a property file be done "entirely" before
the prefix is applied?
It seems that this way both cases would work, and the prefix attribute
could be documented to be applied a-posteriori on the newly created
properties?
Hmmm, a caveat of this approach is that assigning to an already
defined property would have no effect, unless its name was already
prefixed... I think I've cornered myself in :)
>> but breaking the established behavior of the widely used <property>
>> task seems a bad idea.
>
> I tend to agree, but we are really talking about some sort of bordercase.
Another impractical idea quite likely, but what about a ${.:x}
notation, to force the expansion of propery x to point to the "local"
context, taking the prefix into account? It gives a way about of this
conundrum maybe, if it can be implemented that is, which I haven't
checked out course. Just throwing the idea around. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-06-17, Jesse Glick wrote:
> On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
>> Ant 1.8.1 uses the prefix when expanding ${x} inside the file and
>> thus expands ${foo.y} to "x" which makes sense in that it makes the
>> property file self-contained.
> When is this an advantage?
If you want to write a properties file that references properties
defined inside the same file and the use a prefix when loading the file,
you'd have to know the prefix when writing the properties file.
Assume
x=x
y=${x}
and that there is no property x defined prior to
<property file="..."/>
then ${y} will be "x". Using
<property file="..." prefix="foo"/>
${foo.y} in Ant 1.8.0 is ${x} while it is "x" in 1.8.1 - the properties
file was able to refer to its own properties without knowledge of the
prefix.
>> (3) allow different behavior of the tasks and document it.
> Probably recommend this. Don't know much about <loadproperties>
We advertize <loadproperties> as <property file> plus filterchains (and
the task fails if the file is not there). You get
<property file="" prefix=""> behavior in <loadproperties> with a
prefixlines filter. There is an additional prefix attribute on the task
that makes it prefix property resoltion as well.
> but breaking the established behavior of the widely used <property>
> task seems a bad idea.
I tend to agree, but we are really talking about some sort of
bordercase.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Jesse Glick <je...@oracle.com>.
On 06/17/2010 11:10 AM, Stefan Bodewig wrote:
> Ant 1.8.1 uses the prefix when
> expanding ${x} inside the file and thus expands ${foo.y} to "x" which
> makes sense in that it makes the property file self-contained.
When is this an advantage?
> There is an open bug report against 1.8.1 that wants the old behavior
> back <https://issues.apache.org/bugzilla/show_bug.cgi?id=49373>.
Indeed, the 1.8.1 behavior looks like a bug to me.
> (3) allow different behavior of the tasks and document it.
Probably recommend this. Don't know much about <loadproperties> but breaking the established behavior of the widely used <property> task seems a bad idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: what to expand?
Posted by Stefan Bodewig <bo...@apache.org>.
I've added a few AntUnit tests to show some <property file> changes
between 1.7.1, 1.8.0 and 1.8.1 respectively in revision 955633.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org