You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by James Bucanek <su...@gloaming.com> on 2001/01/08 18:04:06 UTC
Property substitutions, Contributed Tasks, & New features
Greetings,
Does anyone know where I can find:
(a) A place to find or post contributed Ant Tasks?
(b) A place to find out what new features are being added, or
considered, for the next version of Ant?
I ask because I've been somewhat annoyed that Project.getProperty()
doesn't perform substitutions ("bla bla ${prop}"). It's up to the
code that sets the property to make the substitution before setting
the value.
This makes it impossible to make forward references in property
values because the property substitution has to be preformed prior to
setting the value. Nor can the substitution value be modified at
run-time.
To resolve this in the short term, I wrote a ResolveProperties Task
that rattles through the Project's properties and fixed up all of the
references. So, coming back to (a), it would seem likely that
someone else might want something like this and I'd like to made that
available to the Ant community in general.
On a side note, my code also resolves substitutions in the property's
name as well. This lets me get around the limitation of the 'if='
clause of targets that only test to see if a property has been
defined, not it's value (true or false). I can now create two
properties:
needsManifest=true
needsManifest-${needsManifest}=whatever
When ResolveProperties is finished, I'll have two properties defined:
needsManifest=true and needsManifest-true=whatever. Now I can
happily write <target name="buildManifest" if="needsManifest-true">...
Getting back to (b), I would strongly suggest that
Project.getProperty() (or Project.getResolvedProperty(...)) be
modified to perform the property value substitution on the fly.
About the only thing you'd need to do is put a cap on the iteration
depth to catch circular substitutions.
So, how does one go about suggesting such a change? And, more
importantly, how do you find out if a such a change has already been
proposed or implemented?
Thanks,
James
__________________________________
James Bucanek
<ma...@gloaming.com>
Re: Property substitutions, Contributed Tasks, & New features
Posted by James Duncan Davidson <du...@x180.net>.
On 1/11/01 10:38 PM, "Peter Donald" <do...@apache.org> wrote:
> At 10:26 11/1/01 -0800, James Duncan Davidson wrote:
>> I disagree that we need a way to say that a property is immutable.
>
> I am not sure you handle things like commandline overides, other static
> defines (like compiler) etc.
\
See other mail.
>> Also, with breaking things into workspace/module as the current docs that
>> I've put up suggest, the properties are scoped well enough not to have the
>> inheritance problem.
>
> The workspace/module is only two levels. this may be satisfactory for small
> to medium projects but definetly doesn't cover all cases and thus I believe
> we still need inheritance.
I'd rather see some preprocessor that could handle the bigger more
specialized cases.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Property substitutions, Contributed Tasks, & New features
Posted by Peter Donald <do...@apache.org>.
At 10:26 11/1/01 -0800, James Duncan Davidson wrote:
>I disagree that we need a way to say that a property is immutable.
I am not sure you handle things like commandline overides, other static
defines (like compiler) etc.
>Also, with breaking things into workspace/module as the current docs that
>I've put up suggest, the properties are scoped well enough not to have the
>inheritance problem.
The workspace/module is only two levels. this may be satisfactory for small
to medium projects but definetly doesn't cover all cases and thus I believe
we still need inheritance.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Property substitutions, Contributed Tasks, & New features
Posted by Jason Rosenberg <ja...@squaretrade.com>.
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Tuesday, January 09, 2001 3:05 AM
Subject: Re: Property substitutions, Contributed Tasks, & New features
> Jason Rosenberg <ja...@squaretrade.com> wrote:
>
> > 2. run-time evaluated, resettable.
> > This is the current 'userProperty', which is not accessible via
> > the Ant XML build file,
>
> Sure? There is a setXXX method that corresponds to an xxx attribute ...
>
Is there some sort of way to do this from the XML build file?
Are you saying there is a task type called setXXX?
Jason
Re: Property substitutions, Contributed Tasks, & New features
Posted by James Duncan Davidson <du...@x180.net>.
On 1/12/01 4:11 AM, "Conor MacNeill" <co...@cognet.com.au> wrote:
> I don't find the analogy too compelling. but I assume you mean <property>
> would not override a command line value, but <setproperty> would?
Something like that... More accurately would be to say that properties set
on the command line would override the <property> tags. Since <setproperty>
would be something happening as a Task, then it can reset whatever it wants.
The problem with having mutable vs immutable properties is that they are
really two different data stores. Or, a a single data store with a set
beside them that indicates immutable props.. Of course, when those props
were attempted to be tweaked, then a NoChangePossibleException would have to
be thrown (and expected by the setter).
> When I am doing a build, I want to be able to control certain properties
> and not have the build file just ignore them. As the build runner I want
> priority over the build writer. The build.compiler flag would be a good
> example, but even build specific properties should be controllable from the
> command line. To have to edit the build file to change one of those values
> would be a chore.
Seems to me that there is an uneasy balance between build runners and build
writers. At the end of they day they have to cooperate to some degree.
> The same issue comes up with sub-builds. Which build controls the values,
> parent or child?
If we go Workspace/Module -- then this issue is factored out. But then we
also get into the problem of how to scope build flags such as build.compiler
properties.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Property substitutions, Contributed Tasks, & New features
Posted by Conor MacNeill <co...@cognet.com.au>.
> For example, I can say:
>
> java -Dmysysprop=foo net.x180.foo.Bar
>
> And my code could override that property. It's ok. Works fine.
>
I don't find the analogy too compelling. but I assume you mean <property>
would not override a command line value, but <setproperty> would?
When I am doing a build, I want to be able to control certain properties
and not have the build file just ignore them. As the build runner I want
priority over the build writer. The build.compiler flag would be a good
example, but even build specific properties should be controllable from the
command line. To have to edit the build file to change one of those values
would be a chore.
The same issue comes up with sub-builds. Which build controls the values,
parent or child?
> --
> James Duncan Davidson
duncan@x180.net
> !try;
do()
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>
Re: Property substitutions, Contributed Tasks, & New features
Posted by James Duncan Davidson <du...@x180.net>.
On 1/11/01 10:30 PM, "Conor MacNeill" <co...@ebinteractive.com.au> wrote:
>> -----Original Message-----
>> From: James Duncan Davidson [mailto:duncan@x180.net]
>>
>> I disagree that we need a way to say that a property is immutable.
>>
>
> What about command line overrides. That is where the whole immutable thing
> came from and we need to consider how we handle that use case.
That's one of the reasons why I've been, maybe to subtlely, making a
distinction between
<property> being something that is set on a module
And
<target>
<setproperty> being a task that sets a property.
...
The reason for this is that properties defined on the command line could
supercede the properties defined by a module. However, this still doesn't
mean that they are immutable. Granted, scripts and such shouldn't change
properties willy-nilly, but the point is that the command line start sets an
entry point condition.
For example, I can say:
java -Dmysysprop=foo net.x180.foo.Bar
And my code could override that property. It's ok. Works fine.
--
James Duncan Davidson duncan@x180.net
!try; do()
RE: Property substitutions, Contributed Tasks, & New features
Posted by Conor MacNeill <co...@ebinteractive.com.au>.
> -----Original Message-----
> From: James Duncan Davidson [mailto:duncan@x180.net]
>
> I disagree that we need a way to say that a property is immutable.
>
What about command line overrides. That is where the whole immutable thing
came from and we need to consider how we handle that use case.
Conor
Re: Property substitutions, Contributed Tasks, & New features
Posted by James Duncan Davidson <du...@x180.net>.
On 1/9/01 12:05 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> I think (though I may be wrong) that we more or less agree that
> properties should be run-time evaluated, resettable and dynamically
> resolved by default in Ant2. One would need a way to say, this
> property may not be reassigned (an attribute would suffice) and we
> have not yet resolved which properties will be inherited by
> subprojects (as the notion of subprojects might change radically
> anyway).
I disagree that we need a way to say that a property is immutable.
Also, with breaking things into workspace/module as the current docs that
I've put up suggest, the properties are scoped well enough not to have the
inheritance problem.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Property substitutions, Contributed Tasks, & New features
Posted by Stefan Bodewig <bo...@apache.org>.
Jason Rosenberg <ja...@squaretrade.com> wrote:
> 2. run-time evaluated, resettable.
> This is the current 'userProperty', which is not accessible via
> the Ant XML build file,
Sure? There is a setXXX method that corresponds to an xxx attribute ...
> 3. parse-time evaluated, not-resettable.
More or less the behavior of Ant 1.1.
> 4. In any case, need the ability to allow a property to be
> dynamically resolved, in the event it contains "bla_bla_${prop}".
The proposals for Ant2 cover this.
I think (though I may be wrong) that we more or less agree that
properties should be run-time evaluated, resettable and dynamically
resolved by default in Ant2. One would need a way to say, this
property may not be reassigned (an attribute would suffice) and we
have not yet resolved which properties will be inherited by
subprojects (as the notion of subprojects might change radically
anyway).
Stefan
Re: Property substitutions, Contributed Tasks, & New features
Posted by Jason Rosenberg <ja...@squaretrade.com>.
----- Original Message -----
From: "James Duncan Davidson" <du...@x180.net>
To: <an...@jakarta.apache.org>
Sent: Friday, January 12, 2001 1:10 AM
Subject: Re: Property substitutions, Contributed Tasks, & New features
> On 1/8/01 11:33 AM, "Jason Rosenberg" <ja...@squaretrade.com> wrote:
>
> > I think, in general, we need to be explicit about the
> > several different kinds of property semantics, and perhaps
> > they all should be allowed and supported, but specified
> > with different syntax or attributes.
> >
> > The property types:
> >
> > 1. run-time evaluated, not-resettable.
> > This is the current <property> behavior in Ant 1.2. Once set, it cannot be
> > changed.
>
> Not good. If full scripting semantics are to be exported, this is bad.
>
I agree, I was just thinking that since this is how it is in 1.2, there must have
been a reason and desire for it, so perhaps there are those who would argue
that it is necessary....
> > 2. run-time evaluated, resettable.
>
> This is the way that properties were meant to be.
>
amen
> > 3. parse-time evaluated, not-resettable.
> > These would be defined at parse time, and remain immutable at run-time.
> > Could use a <constant-property> task to set it, or load it from a file, etc.
>
> Why make things more complex by introducing more and more layers of stuff?
>
This would satisfy the proponents of the strict declarative approach. I agree,
probably not essential. It would allow you to not have to worry about the
ordering of certain "global init" properties, but, not essential, I agree.
> > 4. In any case, need the ability to allow a property to be dynamically
> > resolved,
> > in the event it contains "bla_bla_${prop}". Could have a task to do this:
> > <resolve-property>. Of course, this could only be done on resettable
> > properties, i.e. properties defined with <user-property>.
>
> Or, as the case is in the documents that I've worked on to date, all
> property sub strings (strings of form ${propname}) are evaluated right at
> Task execution time as they are being reflected into the TaskAction.
>
> It's clean, simple, straightforward. It's all we need.
>
amen, again....
Re: Property substitutions, Contributed Tasks, & New features
Posted by James Duncan Davidson <du...@x180.net>.
On 1/8/01 11:33 AM, "Jason Rosenberg" <ja...@squaretrade.com> wrote:
> I think, in general, we need to be explicit about the
> several different kinds of property semantics, and perhaps
> they all should be allowed and supported, but specified
> with different syntax or attributes.
>
> The property types:
>
> 1. run-time evaluated, not-resettable.
> This is the current <property> behavior in Ant 1.2. Once set, it cannot be
> changed.
Not good. If full scripting semantics are to be exported, this is bad.
> 2. run-time evaluated, resettable.
This is the way that properties were meant to be.
> 3. parse-time evaluated, not-resettable.
> These would be defined at parse time, and remain immutable at run-time.
> Could use a <constant-property> task to set it, or load it from a file, etc.
Why make things more complex by introducing more and more layers of stuff?
> 4. In any case, need the ability to allow a property to be dynamically
> resolved,
> in the event it contains "bla_bla_${prop}". Could have a task to do this:
> <resolve-property>. Of course, this could only be done on resettable
> properties, i.e. properties defined with <user-property>.
Or, as the case is in the documents that I've worked on to date, all
property sub strings (strings of form ${propname}) are evaluated right at
Task execution time as they are being reflected into the TaskAction.
It's clean, simple, straightforward. It's all we need.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Property substitutions, Contributed Tasks, & New features
Posted by Jason Rosenberg <ja...@squaretrade.com>.
I think, in general, we need to be explicit about the
several different kinds of property semantics, and perhaps
they all should be allowed and supported, but specified
with different syntax or attributes.
The property types:
1. run-time evaluated, not-resettable.
This is the current <property> behavior in Ant 1.2. Once set, it cannot be changed.
2. run-time evaluated, resettable.
This is the current 'userProperty', which is not accessible via the Ant XML build file,
but which is accessible via scripting: currProject.setUserProperty("test.prop","test.value");
It seems to me this should be allowed in the XML syntax. Why not allow it to be set
with a <user-property> task, possibly overwriting a previously set value, etc.?
3. parse-time evaluated, not-resettable.
These would be defined at parse time, and remain immutable at run-time.
Could use a <constant-property> task to set it, or load it from a file, etc.
4. In any case, need the ability to allow a property to be dynamically resolved,
in the event it contains "bla_bla_${prop}". Could have a task to do this:
<resolve-property>. Of course, this could only be done on resettable
properties, i.e. properties defined with <user-property>.
Jason
----- Original Message -----
From: "James Bucanek" <su...@gloaming.com>
To: <an...@jakarta.apache.org>
Sent: Monday, January 08, 2001 12:04 PM
Subject: Property substitutions, Contributed Tasks, & New features
> Greetings,
>
> Does anyone know where I can find:
>
> (a) A place to find or post contributed Ant Tasks?
>
> (b) A place to find out what new features are being added, or
> considered, for the next version of Ant?
>
> I ask because I've been somewhat annoyed that Project.getProperty()
> doesn't perform substitutions ("bla bla ${prop}"). It's up to the
> code that sets the property to make the substitution before setting
> the value.
>
> This makes it impossible to make forward references in property
> values because the property substitution has to be preformed prior to
> setting the value. Nor can the substitution value be modified at
> run-time.
>
> To resolve this in the short term, I wrote a ResolveProperties Task
> that rattles through the Project's properties and fixed up all of the
> references. So, coming back to (a), it would seem likely that
> someone else might want something like this and I'd like to made that
> available to the Ant community in general.
>
> On a side note, my code also resolves substitutions in the property's
> name as well. This lets me get around the limitation of the 'if='
> clause of targets that only test to see if a property has been
> defined, not it's value (true or false). I can now create two
> properties:
>
> needsManifest=true
> needsManifest-${needsManifest}=whatever
>
> When ResolveProperties is finished, I'll have two properties defined:
> needsManifest=true and needsManifest-true=whatever. Now I can
> happily write <target name="buildManifest" if="needsManifest-true">...
>
> Getting back to (b), I would strongly suggest that
> Project.getProperty() (or Project.getResolvedProperty(...)) be
> modified to perform the property value substitution on the fly.
> About the only thing you'd need to do is put a cap on the iteration
> depth to catch circular substitutions.
>
> So, how does one go about suggesting such a change? And, more
> importantly, how do you find out if a such a change has already been
> proposed or implemented?
>
> Thanks,
>
> James
> __________________________________
> James Bucanek
> <ma...@gloaming.com>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
>