ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: Adding magic properties for targets?
Date Mon, 02 Jun 2008 19:35:54 GMT
My problem with magic properties is that they pollute the namespace of 
allowed property names. Since properties are immutable, it can be 
confusing for someone to try to define a property for the first time in 
their build file and have it come back with an error about redefinition.

Having said that, I am in favour of this patch. I think we need to be 
cautious about adding magic properties because they have a slight 
negative implication, but where they have a clear benefit we should 
adopt them because the benefit outweighs the risk.

There are other solutions to the namespace problem, anyway. We could 
have a reserved prefix like "__ant." that wasn't allowed for 
user-defined properties. Or we could have a special character that was 
illegal in user-defined properties and used in all system-defined ones.

Your example about "dynamic" properties is interesting. I've always been 
in favoring of making properties immutable not by value but by meaning. 
When the changes were being made in the code to make properties 
immutable, I got as far as convincing people to keep the DSTAMP, TSTAMP, 
and TODAY properties "dynamic", so that they always represented the time 
when the <tstamp /> task was run, even if it was run many times during a 
build.

As another example, consider how we test for a file existing that could 
be created in several places throughout the build. We might have to use 
a separate property to test for existence in each section of the build: 
"file.exists", "file.exists.now", "file.exists.how.about.now", and then 
create complex conditions that combine all three properties into a 
single property. Much easier would be if we could assign the property 
directly to the existence of the file, and have it change over the 
lifetime of the build.

Dominique Devienne wrote:
> I'd add that those properties, if made available, should probably be
> prefixed with ant., to make it clear they are "built-in". Perhaps:
>
> ant.default-target
> ant.targets-invoked
>
> I'm +0 on adding these "static" properties.
>
> Since we're at it, we may also want to expose ant.current-target and
> ant.invoked-target properties, but these are "dynamic" since changing
> during the course of the build, so more problematic given the property
> immutability rules. Exposing them via a PropertyHelper to made it
> clear they are dynamic perhaps? ${dynamic:ant.current-target}...
>
> --DD
>
> On Fri, May 30, 2008 at 4:21 AM,  <Jan.Materne@rzf.fin-nrw.de> wrote:
>   
>>> Colm's patch in
>>> <https://issues.apache.org/bugzilla/show_bug.cgi?id=44980> adds two
>>> new magic properties, one for the build's default target and one for
>>> the targets specified on the command line (or via <*ant*>).
>>>
>>> IIRC such properties have been suggested many moons ago and rejected,
>>> but now the dev community is a different one and maybe we do see some
>>> things differently today.  I know that I do, i.e. I'd probably add
>>> them today.
>>>
>>> Before I start to discuss gritty details of a really trivial patch,
>>> let's have a quick poll so we know whether such a feature would be
>>> acceptable.  If anybody out there would reject either property, could
>>> you please raise your hand?
>>>       
>> ${defaultTarget}:
>>   +1 : I am not sure if there is need, but I dont see any reason of
>> hiding that information
>>        as it currently available via project instance.
>>
>> ${calledTargets}:
>>   +1 : Also, we dont have to hide anything. The value should be a list
>> of targets
>>        as specified while invocation without any dependency-resolution.
>>
>> These properties should be set while parsing/project-initialization, so
>> IDEs/programs,
>> which dont use the Launcher, have these properties too.
>>
>>
>> Jan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message