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 2000/12/13 09:36:09 UTC
Expanding ${} constructs for all attributes
Hi,
there have been numerous people on ant-user bitten by the fact that
Ant currently doesn't expand ${} in any attribute of <project> and
<target>.
Does anybody object against expanding them in these attributes as
well? I.e. Ant would expand ${} in all attributes, making it more
consistent.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by "Rousseau, John" <JR...@silverstream.com>.
On Dec 13, 2000, Stefan Bodewig wrote:
> there have been numerous people on ant-user bitten by the fact that
> Ant currently doesn't expand ${} in any attribute of <project> and
> <target>.
>
> Does anybody object against expanding them in these attributes as
> well? I.e. Ant would expand ${} in all attributes, making it more
> consistent.
+1
...but then again, you knew that. :-)
-John
----------------------------------------------------------------
John Rousseau jrr@silverstream.com
SilverStream Software Phone: +1 978 262 3564
2 Federal Street Fax: +1 978 262 3499
Billerica, MA 01821 http://www.silverstream.com
----------------------------------------------------------------
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
Jason Rosenberg <ja...@squaretrade.com> wrote:
> But, I am not clear on what I should look into exactly
> based on your suggestions there. Is this something
> I alternately configure with respect to the sax parser
> jars I am using?
No.
Entities are things like HTML's ä which will be interpreted as รค
by your browser - the parser of the browser is doing this.
Likewise if you embed " into a build file, the XML parser will
translate it into " before the text is passed to Ant. Ant doesn't
parse the build file itself, it uses an external parser (JAXP
reference implementation from Sun or Xerces depending on your setup -
probably Sun's). All Ant sees is the ", it doesn't even know there has
been an entity before.
When you define
<!ENTITY shared SYSTEM "someurl">
the parser - not Ant - will read the content of someurl and wherever
it finds &shared; insert the content. Again, Ant doesn't even know
there has been an entity, it just sees the result.
Ant communicates with the parser via SAX (Simple Api for Xml) - see
<http://www.megginson.com/SAX/SAX1/index.html>. This API allows
applications using an XML parser to help the parser interpreting what
"someurl" means - this is the job of an EntityResolver.
The EntityResolver's primary use would be for custom URL schemes, say
you've invented a sql protocol that reads documents from a database
and "someurl" was "sql://host/database;query=SELECT content FROM
Documents WHERE id='foo'" than EntityResolver would magically retrieve
the content from the database and hand it (or a Reader/Stream to that
content) back to the parser.
Ant hands an EntityResolver of its own to the parser to handle URLs
starting with "file:" and referencing relative file names - because
the default behavior of the parser is not what Ant's users
expected. This EntityResolver is implemented in
ProjectHelper.RootHandler.
> Where is the ProjectHelper.RootHandler code located,
It's the inner class RootHandler in org.apache.tools.ant.ProjectHelper
which is located in src/main/...
> and are you suggesting that this would be code that I
> should modify? Are you talking about modifying Ant
> itself, or are you talking about modifying my use of Ant
> on a configuration level?
Neither nor. My first response was something along the lines of:
Technically it wouldn't be a big problem to expand properties in the
systemIds (the "someurl" from above) of entities. Ant already
implements an EntityResolver and this would be the place to plug in
property substitution.
To rephrase, Ant already gets notified on all external entities and
massages the systemIds - plugging in property expansion there wouldn't
be too difficult.
I think, I also said that I wouldn't like to do that, which means I
was not talking about modifying Ant 8-).
If you want to see this happen, you have to modify the code in
ProjectHelper, there is nothing you could do from the outside to
achieve what you want - apart from preprocessing your build file and
the preprocessor does the property expansion.
What you need to do if you want to modify Ant's behavior is (1)
sending a patch that does what you want and (2) lobby for it so that
it gets applied.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by Jason Rosenberg <ja...@squaretrade.com>.
Forgive me. Perhaps at this point I am not yet ready to
participate on ant-dev, and should limit myself to ant-user...
But, I am not clear on what I should look into exactly
based on your suggestions there. Is this something
I alternately configure with respect to the sax parser
jars I am using?
Where is the ProjectHelper.RootHandler code located,
and are you suggesting that this would be code that I
should modify? Are you talking about modifying Ant
itself, or are you talking about modifying my use of Ant
on a configuration level?
Jason
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, December 13, 2000 7:31 AM
Subject: Re: Expanding ${} constructs for all attributes
> Jason Rosenberg <ja...@squaretrade.com> wrote:
>
> > Can you describe this EntityResolver. At the very least,
> > I'd like to know if this is something I can use....
>
> An EntityResolver is responsible for finding an external entity based
> on the public or system ID the user has specified - see the SAX API.
>
> ProjectHelper.RootHandler implements an EntityResolver that resolves
> relative file:// URLs as being relative to the project's basedir
> instead of the current working directory of the JVM (which is the
> parser's default).
>
> One could plug property expansion in there, basically by invoking
> replaceProperties on the systemId before using it.
>
> > In general, it would be good if the entity would just be
> > inserted as CDATA, and then it would parse the inserted
> > data as if it were there initially.
>
> This is what the parser does, all Ant does is pointing the parser to
> the right file. Ant doesn't know the difference between XML data from
> the original document and data coming from an external entity.
>
> Stefan
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
Jason Rosenberg <ja...@squaretrade.com> wrote:
> Can you describe this EntityResolver. At the very least,
> I'd like to know if this is something I can use....
An EntityResolver is responsible for finding an external entity based
on the public or system ID the user has specified - see the SAX API.
ProjectHelper.RootHandler implements an EntityResolver that resolves
relative file:// URLs as being relative to the project's basedir
instead of the current working directory of the JVM (which is the
parser's default).
One could plug property expansion in there, basically by invoking
replaceProperties on the systemId before using it.
> In general, it would be good if the entity would just be
> inserted as CDATA, and then it would parse the inserted
> data as if it were there initially.
This is what the parser does, all Ant does is pointing the parser to
the right file. Ant doesn't know the difference between XML data from
the original document and data coming from an external entity.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by Jason Rosenberg <ja...@squaretrade.com>.
Can you describe this EntityResolver. At the very least,
I'd like to know if this is something I can use....
In general, it would be good if the entity would just be
inserted as CDATA, and then it would parse the inserted
data as if it were there initially. Would that be so hard?
Jason
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, December 13, 2000 4:07 AM
Subject: Re: Expanding ${} constructs for all attributes
> Jason Rosenberg <ja...@squaretrade.com> wrote:
>
> > I'd like to see this in the expanded in <!ENTITY> expansions as
> > well:
> >
> > I realize this may be a limitation with XML parsing....
>
> No a real technical problem, we already implement an EntityResolver of
> our own. But note that entities get resolved before any tags have been
> parsed, this means we'd be restricted to system properties and
> properties defined on the command line.
>
> I'm not sure I'd want to resolve ${} in entity declarations as this
> would result in Ant using a specialized variant of XML. And once
> XInclude is there (and supported by parsers) I'd love to get rid of
> entities completely.
>
> Stefan
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
Jason Rosenberg <ja...@squaretrade.com> wrote:
> I'd like to see this in the expanded in <!ENTITY> expansions as
> well:
>
> I realize this may be a limitation with XML parsing....
No a real technical problem, we already implement an EntityResolver of
our own. But note that entities get resolved before any tags have been
parsed, this means we'd be restricted to system properties and
properties defined on the command line.
I'm not sure I'd want to resolve ${} in entity declarations as this
would result in Ant using a specialized variant of XML. And once
XInclude is there (and supported by parsers) I'd love to get rid of
entities completely.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by Jason Rosenberg <ja...@squaretrade.com>.
I'd like to see this in the expanded in <!ENTITY> expansions as well:
<!ENTITY testEntity "${variableToExpand}">
<project .....
<property name="variableToExpand" value="fred"/>
<property name="test" value="&testEntity;"/>
</project>
I realize this may be a limitation with XML parsing....But we need a way
to make up for the lack of a proper include mechanism for creating a
library of build templates, etc.
Jason
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, December 13, 2000 3:36 AM
Subject: Expanding ${} constructs for all attributes
> Hi,
>
> there have been numerous people on ant-user bitten by the fact that
> Ant currently doesn't expand ${} in any attribute of <project> and
> <target>.
>
> Does anybody object against expanding them in these attributes as
> well? I.e. Ant would expand ${} in all attributes, making it more
> consistent.
>
> Stefan
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
James Duncan Davidson <du...@x180.net> wrote:
> I didn't think that ${}'s reflected system.properties. Or at least
> they did when I wrote it, then it was pulled. Was that put back in?
They do - and I can't remeber a time when they didn't. But I came here
when Ant had already undergone several changes 8-)
Stefan
Re: Expanding ${} constructs for all attributes
Posted by James Duncan Davidson <du...@x180.net>.
On 12/13/00 2:00 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> Not really. I do see valid use cases for setting project's basedir
> based on user.home for example.
I didn't think that ${}'s reflected system.properties. Or at least they did
when I wrote it, then it was pulled. Was that put back in?
>> I see much much danger in evaluating depends attributes.
>
> If we were going to expand them at runtime that is, right. Actually I
> was proposing to expand them at parser time - should have been
> clearer.
If expanded at parser time, then I'd be for this. But since in AntEater,
it's all deferred so that scripts and what not can modify them, then I'm
against.
>> Besides the fact that has been asked for can you think of any good
>> reasons to include it?
>
> Consistency.
But at the expense of other consistency.
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Expanding ${} constructs for all attributes
Posted by Peter Donald <do...@apache.org>.
At 09:04 13/12/00 -0500, Rousseau, John wrote:
>We have a bunch of stand-alone commands we create around our main
>product. Not all of these commands are built/supported on all
>platforms (it's native code). What I want to do is have a
>targets.xml file with build rules for all targets. I then want a
>master build.xml file for each platform that sets ${build.targets}
>appropriately for that platform, and calls <ant> on the targets
>file. The targets file main <target> then depends on
>${build.targets}. This is a serious lack of functionality when
>compared to make.
nope you can do that fine in vanilla ant now. ie add this into file
<target name="do-targets" depends="target1, target2 target 3" />
<target name="target1" if="do-target1" />
<target name="target2" if="do-target2" />
<target name="target3" if="do-target3" />
then call that file either setting or not setting the respective properties
do-target1, do-target2, do-target3. Much easier to comprehend IMHO and
easier to read/maintain.
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: Expanding ${} constructs for all attributes
Posted by "Rousseau, John" <JR...@silverstream.com>.
On Dec 13, 2000, Stefan Bodewig wrote:
> Peter Donald <do...@apache.org> wrote:
>
> > At 11:00 13/12/00 +0100, Stefan Bodewig wrote:
> >>Peter Donald <do...@apache.org> wrote:
> >>> I see much much danger in evaluating depends attributes.
> >>
> >>If we were going to expand them at runtime that is, right. Actually
> >>I was proposing to expand them at parser time - should have been
> >>clearer.
>
> When it comes to <project>, parser time and runtime are the same. We
> need to know the basedir of a project when setting the dir attribute
> of a <fileset> for example.
>
> Evaluating the depends attribute at runtime would be a real pain as
> you could not calculate the dependency graph up front and might realize
> there is a cycle when you are half way through the build.
>
> If we evaluate them at parser time, the problem would go away, but
> that might make it less useful to those who want to expand properties
> in the depends attribute, not sure.
Evaluation at parser time would be just fine for me.
We have a bunch of stand-alone commands we create around our main
product. Not all of these commands are built/supported on all
platforms (it's native code). What I want to do is have a
targets.xml file with build rules for all targets. I then want a
master build.xml file for each platform that sets ${build.targets}
appropriately for that platform, and calls <ant> on the targets
file. The targets file main <target> then depends on
${build.targets}. This is a serious lack of functionality when
compared to make.
Without veriable expansion here, I need to duplicate quite a bit of
XML to get the functionality I want.
I agree that runtime expansion would be problematic, and should be
avoided.
Thanks
-John
----------------------------------------------------------------
John Rousseau jrr@silverstream.com
SilverStream Software Phone: +1 978 262 3564
2 Federal Street Fax: +1 978 262 3499
Billerica, MA 01821 http://www.silverstream.com
----------------------------------------------------------------
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
James Duncan Davidson <du...@x180.net> wrote:
> On 12/13/00 2:50 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
>
>> Actually what you suggest (setting basedir on the command line)
>> works right now, this is what I recommend on ant-user as well. If
>> you do so you must not specify a basedir attribute for project at
>> all. The docs say all attributes of project would be required, but
>> Ant doesn't really enforce this - quite the opposite.
>
> Basedir set on the command line should *override* a basedir set in
> the file -- not require that its not set.
I was talking about what you need to do right now, not what it should
be like. Sure it'd be quite easy to give a basedir property - if set -
priority over the attribute of the project element.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by James Duncan Davidson <du...@x180.net>.
On 12/13/00 2:50 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> Actually what you suggest (setting basedir on the command line) works
> right now, this is what I recommend on ant-user as well. If you do so
> you must not specify a basedir attribute for project at all. The docs
> say all attributes of project would be required, but Ant doesn't
> really enforce this - quite the opposite.
Basedir set on the command line should *override* a basedir set in the file
-- not require that its not set.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> At 11:00 13/12/00 +0100, Stefan Bodewig wrote:
>>Peter Donald <do...@apache.org> wrote:
>>
>>> While I won't block such a move I think it is possibly an example
>>> of flexability syndrome mentioned a few days ago. Can you think of
>>> any *good* use case for changing the value of either name or
>>> default attributes of project or name attribute of target?
>>
>>Not really. I do see valid use cases for setting project's basedir
>>based on user.home for example.
>
> Could you expand on this and give an example of when it would be
> useful. ie When would the current mechanisms fail and how would this
> solve it. Also could it be solved by making basedir a special
> property. ie place "-Dbasedir=foo/" on command line.
Actually what you suggest (setting basedir on the command line) works
right now, this is what I recommend on ant-user as well. If you do so
you must not specify a basedir attribute for project at all. The docs
say all attributes of project would be required, but Ant doesn't
really enforce this - quite the opposite.
It boils down to convenience, user.home has already been set by the
JVM, probably based on $HOME, so why should I have to specify it on
the command line again.
>
>>> I see much much danger in evaluating depends attributes.
>>
>>If we were going to expand them at runtime that is, right. Actually
>>I was proposing to expand them at parser time - should have been
>>clearer.
When it comes to <project>, parser time and runtime are the same. We
need to know the basedir of a project when setting the dir attribute
of a <fileset> for example.
Evaluating the depends attribute at runtime would be a real pain as
you could not calculate the dependency graph up front and might realize
there is a cycle when you are half way through the build.
If we evaluate them at parser time, the problem would go away, but
that might make it less useful to those who want to expand properties
in the depends attribute, not sure.
>>> Besides the fact that has been asked for can you think of any good
>>> reasons to include it?
>>
>>Consistency.
>
> good point. If we are going to make if/unless evaluated then it
> definetly becomes an issue - however they are evaluated at interpret
> time. Not sure thou.
You are right. Expanding the if/unless attributes at parser time
doesn't make much sense to those who ask for that feature.
Almost looks as if the only consistent way was to keep the current
behavior but change the documentation of project to better reflect the
truth.
Thank you for making me rethink the whole issue
Stefan
Re: Expanding ${} constructs for all attributes
Posted by Peter Donald <do...@apache.org>.
At 11:00 13/12/00 +0100, Stefan Bodewig wrote:
>Peter Donald <do...@apache.org> wrote:
>
>> While I won't block such a move I think it is possibly an example of
>> flexability syndrome mentioned a few days ago. Can you think of any
>> *good* use case for changing the value of either name or default
>> attributes of project or name attribute of target?
>
>Not really. I do see valid use cases for setting project's basedir
>based on user.home for example.
Could you expand on this and give an example of when it would be useful. ie
When would the current mechanisms fail and how would this solve it. Also
could it be solved by making basedir a special property. ie place
"-Dbasedir=foo/" on command line.
>> I see much much danger in evaluating depends attributes.
>
>If we were going to expand them at runtime that is, right. Actually I
>was proposing to expand them at parser time - should have been
>clearer.
could you expand on this aswell.
>> Besides the fact that has been asked for can you think of any good
>> reasons to include it?
>
>Consistency.
good point. If we are going to make if/unless evaluated then it definetly
becomes an issue - however they are evaluated at interpret time. Not sure
thou.
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: Expanding ${} constructs for all attributes
Posted by Stefan Bodewig <bo...@apache.org>.
Peter Donald <do...@apache.org> wrote:
> While I won't block such a move I think it is possibly an example of
> flexability syndrome mentioned a few days ago. Can you think of any
> *good* use case for changing the value of either name or default
> attributes of project or name attribute of target?
Not really. I do see valid use cases for setting project's basedir
based on user.home for example.
> I see much much danger in evaluating depends attributes.
If we were going to expand them at runtime that is, right. Actually I
was proposing to expand them at parser time - should have been
clearer.
> Besides the fact that has been asked for can you think of any good
> reasons to include it?
Consistency.
Stefan
Re: Expanding ${} constructs for all attributes
Posted by Peter Donald <do...@apache.org>.
At 09:36 13/12/00 +0100, Stefan Bodewig wrote:
>Hi,
>
>there have been numerous people on ant-user bitten by the fact that
>Ant currently doesn't expand ${} in any attribute of <project> and
><target>.
While I won't block such a move I think it is possibly an example of
flexability syndrome mentioned a few days ago. Can you think of any *good*
use case for changing the value of either name or default attributes of
project or name attribute of target? I can see *some* use for evaluation of
if/unless attributes (thou those uses would be better served with a XML +
XSLT -> build.xml). I see much much danger in evaluating depends
attributes. The evaluation order of targets becomes non-trivial and there
is all sorts of hidden dependency ordering.
Besides the fact that has been asked for can you think of any good reasons
to include it? (Remembering that a lot of people have also asked for
if/switch/select/when statements so asking is not something that is
necessarily good ;])
>
>Does anybody object against expanding them in these attributes as
>well? I.e. Ant would expand ${} in all attributes, making it more
>consistent.
>
>Stefan
>
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: Expanding ${} constructs for all attributes
Posted by James Duncan Davidson <du...@x180.net>.
On 12/13/00 12:36 AM, "Stefan Bodewig" <bo...@apache.org> wrote:
> there have been numerous people on ant-user bitten by the fact that
> Ant currently doesn't expand ${} in any attribute of <project> and
> <target>.
>
> Does anybody object against expanding them in these attributes as
> well? I.e. Ant would expand ${} in all attributes, making it more
> consistent.
Actually, if defined as things that get resolved until needed (task
execution time), then they don't make since in projets or targets. As well,
in order to have a sane parse, you'd have to make sure all properties were
loaded before construction projects/targets began. This either means that
all properties are defined before targets -- or a multi pass of the build
file gets made.
So, currently I'd object.
--
James Duncan Davidson duncan@x180.net
!try; do()