You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Costin Manolache <cm...@yahoo.com> on 2002/11/26 23:13:44 UTC
PROPOSAL: top level execution order
I think this is the crucial issue for embed.
We agreed on allowing top-level tasks. There are 2
implementations - one made by Stefan on the main branch
and one in embed.
In both cases a dummy target is created and
all top-level stuff is placed in this target.
The difference is on the execution:
- in the main branch, the top-level target is added
as a dependency to all other targets. The dependency
resolver will compute the execution graph and make it
the first. This happen in execute(), after the XML
processing is completed.
- in [embed], the top-level target is executed _before_
resolving dependencies, as part of the XML processing
The main consequence is that in [embed] we can have top-level
tasks that operate on the build tree and affect the dependencies.
Import ( and any similar task that will operate on the
tree level ) needs that.
The downside is that if tasks like <echo> or <javac> are used at top level,
they will be executed when -projecthelp is called.
Unfortunately it is not possible to implement -projecthelp
and also allow <javac> _and_ allow import in a clean way.
The only solution is to document this and explain the
behavior - IMO javac at top level is a bad idea in the first place.
Opinions ?
I need a closure on this before anything else - if we keep
the current behavior then <import> and a lot of other stuff
will need to be rewritten ( so far I don't know any clean way
to do it ).
Stefan - can you live with the top-level processing in embed ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> Conor MacNeill wrote:
>
>
>>Nicola Ken Barozzi wrote:
>>
>>>The downside is that Centipede will no longer work :-(
>>>
>>>We use this [embed] feature so that we can transform a template and
>>>import the result, all in one swoop, as has already been described here
>>>and it seemed to be a useful feature.
>
>>Let me just repeat what I said in an earlier mail. If you rely on an
>>unreleased feature then you do so at a risk that the feature may morph or
>>disappear. This is a risk you have chosen to accept and not the Ant
>
> That's true for almost any software project, and not only unreleased
> features :-)
I know, I know, can't someone lobby in peace? ;-P
> In case the top-level order proposal is not accepted or if <import>
> will not be accepted or accepted with different behavior - Nicola can
> still use the embed proposal or a fork of it ( I plan to have it match
> the behavior of what gets accepted in ant16 ).
There is a need for an import system or equivalent, so I'm confident
that a similar feature will eventually make his way in Ant.
If/when it happens we will switch to that, and use the embed proposal in
the meantime; if not I'm quite sure that we can keep our import version
as is being done now with the embed proposal.
> I think the real important thing is to find the best solution - if that
> would break Centipede or will be different than what embed does is
> less important ( as long as it is a better solution ).
Yes :-)
As long as I'm enabled to do what I need in Centipede, I don't care how
it's done.
Anyway it goes, if anyone can show me a better solution I'd be very
happy :-)
If not, I'm happy still :-)
Ant RULES! :-) And Centipede is not bad either, eh? ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Costin Manolache <cm...@yahoo.com>.
Conor MacNeill wrote:
> Nicola Ken Barozzi wrote:
>>
>> The downside is that Centipede will no longer work :-(
>>
>> We use this [embed] feature so that we can transform a template and
>> import the result, all in one swoop, as has already been described here
>> and it seemed to be a useful feature.
> Let me just repeat what I said in an earlier mail. If you rely on an
> unreleased feature then you do so at a risk that the feature may morph or
> disappear. This is a risk you have chosen to accept and not the Ant
That's true for almost any software project, and not only unreleased
features :-)
In case the top-level order proposal is not accepted or if <import>
will not be accepted or accepted with different behavior - Nicola can
still use the embed proposal or a fork of it ( I plan to have it match
the behavior of what gets accepted in ant16 ).
I think the real important thing is to find the best solution - if that
would break Centipede or will be different than what embed does is
less important ( as long as it is a better solution ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Nicola Ken Barozzi wrote:
>
> The downside is that Centipede will no longer work :-(
>
> We use this [embed] feature so that we can transform a template and
> import the result, all in one swoop, as has already been described here
> and it seemed to be a useful feature.
>
Nicola Ken,
Let me just repeat what I said in an earlier mail. If you rely on an
unreleased feature then you do so at a risk that the feature may morph or
disappear. This is a risk you have chosen to accept and not the Ant project.
IMHO, you should make your users aware of this fact.
I'm not saying you can't lobby for a feature but the fact that you depend on
it already would not be a justification.
Conor
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 27 Nov 2002, Nicola Ken Barozzi <ni...@apache.org> wrote:
> The downside is that Centipede will no longer work :-(
Sorry, if you use a proposal of something, you always run the risk
that this proposal might not be accepted.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Costin Manolache wrote:
> I think this is the crucial issue for embed.
>
> We agreed on allowing top-level tasks. There are 2
> implementations - one made by Stefan on the main branch
> and one in embed.
>
> In both cases a dummy target is created and
> all top-level stuff is placed in this target.
>
> The difference is on the execution:
>
> - in the main branch, the top-level target is added
> as a dependency to all other targets. The dependency
> resolver will compute the execution graph and make it
> the first. This happen in execute(), after the XML
> processing is completed.
>
> - in [embed], the top-level target is executed _before_
> resolving dependencies, as part of the XML processing
>
>
> The main consequence is that in [embed] we can have top-level
> tasks that operate on the build tree and affect the dependencies.
> Import ( and any similar task that will operate on the
> tree level ) needs that.
>
> The downside is that if tasks like <echo> or <javac> are used at top level,
> they will be executed when -projecthelp is called.
The downside is that Centipede will no longer work :-(
We use this [embed] feature so that we can transform a template and
import the result, all in one swoop, as has already been described here
and it seemed to be a useful feature.
> Unfortunately it is not possible to implement -projecthelp
> and also allow <javac> _and_ allow import in a clean way.
> The only solution is to document this and explain the
> behavior - IMO javac at top level is a bad idea in the first place.
>
> Opinions ?
>
> I need a closure on this before anything else - if we keep
> the current behavior then <import> and a lot of other stuff
> will need to be rewritten ( so far I don't know any clean way
> to do it ).
>
> Stefan - can you live with the top-level processing in embed ?
pleeeeeease
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 02 Dec 2002, Costin Manolache <cm...@yahoo.com> wrote:
> Ok, are we all in agreement on delayed construction of tasks ?
I am - if it works 8-)
> I would try 2 first, and keep 3 as a backup.
I can live with that.
> Another option would be to support both 2 and 3 - i.e. have tasks
> that execute on read and tasks that execute normally. Since we don't
> want to instantiate the task until execution time - marker
> interfaces or special methods won't work, but we can use a
> properties file with the list of 'exec-on-load' tasks.
Uhm, no thanks. That way the result of a build file can not be
gathered from the build file alone, you also need to know which
additional property file has been read in.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
>> 1. Top-level gets executed _after_ xml processing, as part of
>> resolving dependencies. That's the current HEAD
>>
>> 2. Top-level gets executed as part of xml processing and _before_
>> resolving dependencies. ( the current EMBED ).
>>
>> 3. Same as 2, but each top-level element gets executed immediately
>> after it is read.
>>
>> In 1 and 2 - we agree that delayed construction of tasks is required
>> in order to support redefinition of core tasks.
>
> Right. And it would be in 3 as well to work for <taskdef>s inside of
> <target>s.
Good point. The current solution is to replace the tasks ( at least
from what I understand in the code ), and it would be much cleaner to
use delayed construction of the task.
Ok, are we all in agreement on delayed construction of tasks ? Anyone
against ? If we agree, that should be the first thing to do.
> So the problem of replacing built-in tasks is not related to the top
> level execution order at all 8-)
+1
>
>> A side effect is cleaner and more consistent code in the xml
>> processor
>
> Exactly. I think we all agree upon that, the only problem that may
> arise are some difficult to track backwards incompatibilities we must
> guard against.
>
> If we switch to delayed construction (or lazy evaluation or whatever
> you want to call it) and the testcase RhinoScriptTest passes - we are
> pretty save, I guess. This test just reproduces the examples from
> <script>'s documentation that have been there since Ant 1.2 - we
> better don't break them 8-)
Ok, I'll try the Rhino test case with embed ( where delayed construction
is already implemented ), and let you know the result. If I can get it
to work then we can do it in the main branch.
> Oh, back to the subject, I'm leaning toward Option 3 from your list,
> but can live with 2 as well.
I would try 2 first, and keep 3 as a backup.
The pros and cons:
- with 2, the parser is just constructing a tree. The code is much simpler,
it is easier to remove SAX from the picture ( if someone wants to
have ant operate on a DOM tree or have an application construct the tree
directly ).
- also 2 is more consistent with what happens in targets, i.e. top level
is less "special".
On the other side:
- 3 is a closer to what we had before, so it's less danger on breaking
backward compat ( that's why I would try 2 first, and if anything wrong
happens fallback to 3 ).
- 3 may be better for <import> - the import may happen immediately which is
cleaner ( with 2 the import will happen after the tree is constructed -
and is more difficult to make the imported file replace the <import> ).
However the opposite is true - import and similar tasks may work better
if they have access to the whole tree.
Another option would be to support both 2 and 3 - i.e. have tasks that
execute on read and tasks that execute normally. Since we don't want to
instantiate the task until execution time - marker interfaces or special
methods won't work, but we can use a properties file with the list of
'exec-on-load' tasks.
I would keep 2+3 as the last option.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 28 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
> Ok. Let me summarize the options:
>
> 1. Top-level gets executed _after_ xml processing, as part of
> resolving dependencies. That's the current HEAD
>
> 2. Top-level gets executed as part of xml processing and _before_
> resolving dependencies. ( the current EMBED ).
>
> 3. Same as 2, but each top-level element gets executed imediately
> after it is read.
>
> In 1 and 2 - we agree that delayed construction of tasks is required
> in order to support redefinition of core tasks.
Right. And it would be in 3 as well to work for <taskdef>s inside of
<target>s.
So the problem of replacing built-in tasks is not related to the top
level execution order at all 8-)
> A side effect is cleaner and more consistent code in the xml
> processor
Exactly. I think we all agree upon that, the only problem that may
arise are some difficult to track backwards incompatibilities we must
guard against.
If we switch to delayed construction (or lazy evaluation or whatever
you want to call it) and the testcase RhinoScriptTest passes - we are
pretty save, I guess. This test just reproduces the examples from
<script>'s documentation that have been there since Ant 1.2 - we
better don't break them 8-)
Stefan
Oh, back to the subject, I'm leaning towards Option 3 from your list,
but can live with 2 as well.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
> Not so if we find a different solution (like not instantiating tasks
> at parser time is).
>
> But "replacement of built-in tasks" in Ant 1.2 until Ant 1.5.x relies
> on the fact that top-level taskdefs get executed immediately.
Ok. Let me summarize the options:
1. Top-level gets executed _after_ xml processing, as part of resolving
dependencies. That's the current HEAD
2. Top-level gets executed as part of xml processing and _before_ resolving
dependencies. ( the current EMBED ).
3. Same as 2, but each top-level element gets executed imediately after it
is read.
In 1 and 2 - we agree that delayed construction of tasks is required in
order to support redefinition of core tasks. A side effect is cleaner and
more consistent code in the xml processor ( a lot of the special cases go
away ). Another benefit is that "meta-tasks" ( things that operate on the
build tree, like import ) will have a lot more power.
I can live with 2 and 3, I preffer 2 because it is cleaner and more
consistent. Another benefit of 2 is that it keeps the xml reading very
simple and is easier to allows embedding applications to do ant without any
xml involved ( by creating the tree ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 27 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
> AFAIK the <echo> example would work with the current embed - all
> tasks are created in a consistent way ( allways lazy ).
Yes, I think so.
>>> If something relies on taskdef beeing executed imediately, then
>>> it's a bug
>>
>> good bye replacement of built-in tasks ...
>
> Not so.
Not so if we find a different solution (like not instantiating tasks
at parser time is).
But "replacement of built-in tasks" in Ant 1.2 until Ant 1.5.x relies
on the fact that top-level taskdefs get executed immediately.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
> On Wed, 27 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
>> Stefan Bodewig wrote:
>>
>>> Another downside of the HEAD version: As I pointed out last week,
>>> the way CVS HEAD works breaks backwards compatibilty in a subtle
>>> way because <taskdef>s will no longer be executed before the task
>>> definitions are encountered by the parser right now.
>>
>> That's an upside IMO :-)
>>
>> It will lead to more consistent behavior ( especially if combined
>> with the generalised lazy eval ).
>
> Quite the opposite - see Conor's example of replacing echo with jar.
> It works in 1.5.1 and doesn't in CVS HEAD. If you put the taskdef
> into a target, only the first <echo> is going to work, but not the
> second (in both Ants).
I think we're talking about different things.
AFAIK the <echo> example would work with the current embed - all
tasks are created in a consistent way ( allways lazy ). The real
problem was that echo was instantiated before the taskdef was executed
( in MAIN and also in embed, before making all tasks lazy ).
> So yes, CVS HEAD is more consistent that it breaks in both situations,
> but it shouldn't break at all (or at least be consistent in not
> allowing the no-child version of echo either).
I'll try it with embed, but I'm relatively sure it will work.
>
>> If something relies on taskdef beeing executed imediately, then it's
>> a bug
>
> good bye replacement of built-in tasks ...
Not so. Relying on taskdef beeing executed _before_ the task is reasonable
and can be supported.
Even in ant1.5, taskdefs at target level are not executed imediately
but are executed _before_ the task.
In embed takdefs are allways executed before the task - but never imediately
( for top level and target level - same behavior ).
>> since we have no guarantee on that
>
> "It's always been that way since <taskdef> has been introduced"
> doesn't count?
I think both ant1.4 and ant1.5 will not execute taskdefs in targets.
And I'm not sure what's the exect change in behavior - as long as taskdef
is executed before instantiating the task.
>>> And when the parser detects an error after some of the tasks have
>>> been run ...
>>
>> Parser ( XML ) errors will be detected in the same way in the main
>> build file.
>
> I was talking about the project file parser, not the XML parser.
> Things like <target> nested into <target>.
I don't think this is a major issue - in ant1.5 there are a lot
of errors that are detected at runtime, after some of the build file
has been executed.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 27 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
> Stefan Bodewig wrote:
>
>> Another downside of the HEAD version: As I pointed out last week,
>> the way CVS HEAD works breaks backwards compatibilty in a subtle
>> way because <taskdef>s will no longer be executed before the task
>> definitions are encountered by the parser right now.
>
> That's an upside IMO :-)
>
> It will lead to more consistent behavior ( especially if combined
> with the generalised lazy eval ).
Quite the opposite - see Conor's example of replacing echo with jar.
It works in 1.5.1 and doesn't in CVS HEAD. If you put the taskdef
into a target, only the first <echo> is going to work, but not the
second (in both Ants).
So yes, CVS HEAD is more consistent that it breaks in both situations,
but it shouldn't break at all (or at least be consistent in not
allowing the no-child version of echo either).
> If something relies on taskdef beeing executed imediately, then it's
> a bug
good bye replacement of built-in tasks ...
> since we have no guarantee on that
"It's always been that way since <taskdef> has been introduced"
doesn't count?
>> And when the parser detects an error after some of the tasks have
>> been run ...
>
> Parser ( XML ) errors will be detected in the same way in the main
> build file.
I was talking about the project file parser, not the XML parser.
Things like <target> nested into <target>.
> I agree - we'll introduce many new ways for users to hurt themself,
> but they never lacked that ability.
8-)
>> * marker interface for tasks to be run at parser time.
>
> That's a possible solution - however the biggest limitation (IMO) is
> that users may _need_ to execute all kind of stuff ( url get, etc ?
> ).
I know - I said I wouldn't like it. ;-)
> Every opinion is important.
This is what I wanted to say.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Costin Manolache <cm...@yahoo.com>.
Stefan Bodewig wrote:
> Another downside of the HEAD version: As I pointed out last week, the
> way CVS HEAD works breaks backwards compatibilty in a subtle way
> because <taskdef>s will no longer be executed before the task
> definitions are encountered by the parser right now.
That's an upside IMO :-)
It will lead to more consistent behavior ( especially if combined
with the generalised lazy eval ). If something relies on taskdef beeing
executed imediately, then it's a bug since we have no guarantee on
that ( the taskdef at top level will execute the same as a taskdef in a
target ). That's if we're talking about the same thing :-)
> On Tue, 26 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
>
>> The downside is that if tasks like <echo> or <javac> are used at top
>> level, they will be executed when -projecthelp is called.
>
> And when the parser detects an error after some of the tasks have been
> run ...
Parser ( XML ) errors will be detected in the same way in the main build
file. Parser errors in imported files - yes, but the same would happen
if <ant> task is used. Non-XML errors and validation - yes, but that's
exactly what can happen today in many cases.
I agree - we'll introduce many new ways for users to hurt themself,
but they never lacked that ability.
>> Unfortunately it is not possible to implement -projecthelp
>> and also allow <javac> _and_ allow import in a clean way.
>
> Not that I'd like any of the solutions too much:
>
> * marker interface for tasks to be run at parser time.
That's a possible solution - however the biggest limitation (IMO)
is that users may _need_ to execute all kind of stuff ( url get, etc ? ).
> * implement <import> by something that is not a task.
The reasons for import as a task:
- simpler project helper ( it avoids complexity in a very tricky area)
- cleaner implementation (IMO)
Import is just one particular case - a whole class of tasks that operate
on the project tree will be possible.
>> The only solution is to document this and explain the
>> behavior
>
> Third option, and probably the one I like most. But I still want to
> wait a few days to see whether anybody finds yet another solution to
> make that a fully supported +1.
>
>> Stefan - can you live with the top-level processing in embed ?
>
> My opinion is not that important, just one of a whole bunch of
> committers.
Every opinion is important.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Stefan Bodewig <bo...@apache.org>.
Another downside of the HEAD version: As I pointed out last week, the
way CVS HEAD works breaks backwards compatibilty in a subtle way
because <taskdef>s will no longer be executed before the task
definitions are encountered by the parser right now.
On Tue, 26 Nov 2002, Costin Manolache <cm...@yahoo.com> wrote:
> The downside is that if tasks like <echo> or <javac> are used at top
> level, they will be executed when -projecthelp is called.
And when the parser detects an error after some of the tasks have been
run ...
> Unfortunately it is not possible to implement -projecthelp
> and also allow <javac> _and_ allow import in a clean way.
Not that I'd like any of the solutions too much:
* marker interface for tasks to be run at parser time.
* implement <import> by something that is not a task.
> The only solution is to document this and explain the
> behavior
Third option, and probably the one I like most. But I still want to
wait a few days to see whether anybody finds yet another solution to
make that a fully supported +1.
> Stefan - can you live with the top-level processing in embed ?
My opinion is not that important, just one of a whole bunch of
committers.
Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: PROPOSAL: top level execution order
Posted by Magesh Umasankar <um...@apache.org>.
----- Original Message -----
From: "Costin Manolache" <cm...@yahoo.com>
> - in [embed], the top-level target is executed _before_
> resolving dependencies, as part of the XML processing
>
>
> The main consequence is that in [embed] we can have top-level
> tasks that operate on the build tree and affect the dependencies.
> Import ( and any similar task that will operate on the
> tree level ) needs that.
+1
>
> Costin
Cheers,
Magesh
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>