On Sat, 20 Jul 2002, Nicola Ken Barozzi wrote:
I said "deprecate", not "remove".
And why do you think 'deprecating' something that many people like and use is ok ?
Eh? I'm not aware that any top-level task can be run in Ant 1.5.
There are few ( property, taskdef ). And it is proposed and it seems many agree on allowing all of them ( just like it was in ant 1.0 ).
The current version of ProjectHelperImpl2 does allow them ( based on Stefan's patch on the main branch ), and so you can use top-level tasks now in 1.5, just like import :-)
I like having top-level tasks, I find it more convenient and clean - and since it doesn't inhibit your use case or preference I don't understand the oposition.
And I don't understand yours.
Having these tasks top-level or having them in an init tag... what's the problem?
With an init tag you are more consistent with the init-finally pair, and don't have the understandment problems I already talked you about.
We are going in circles, you keep saying that top level tasks are already here, I say they are not.
And they confuse users.
What users lament is that if they "extend" a buildfile they don't want to write
ant extendedbuild:compile
but just
ant compile If you do compulsory rewriting of the names this is what happens...
No - I do rewriting only for the duplicated targets.
The one in the 'main' build file will keep the name. All other
overriden targets will get a name based on the project name.
Which is confusing to users.
If you accept the removal of super.super, then it would be
trivial to take the first overriden target and name it 'super.' instead of using the name - but I feel it's much cleaner to use
the name of the project ( i.e. what you use in <project name='' >),
it's more explicit.
For tasks that are not overriden - the original name remains.
Too confusing.
You are automatically overriding a method and can refer to other imported versions with buildfile:target...
<include file="..."> includes one buildfile in another as-is, like xml entities.
Using XSL semantics ( that duplicated targets in included files will be ignored ).
+1
It should be able to rewrite names to prefix-targetname is specified as <include prefix="prefix-" file="...">
I don't think it's needed - let's make small steps and see how people use it and not add complexity until we are sure it is needed.
It's already needed.
If we make libraries out of imported stuff, there will be massive name clashes if we don't do this.
<project name="" extends="buildfietoextend"> ... </project>
Same comment here - I think 'extend' on a document is very confusing. I've seen a lot of ugliness and complexity even in java, with overuse of extend creating nightmares.
XSLT just defines import and include - why would ant need more ?
Because you hinted it ;-)
" We can have an '<extend>' task - and require that each build extends at most one file, then what you say makes sense. I think 'extend' would be very tricky and I doubt its usefullness, but if you really need it, it can be added - at least as an external task. "
You correctly said that multiple imports of the same target is confusing, so I proposed that overriding can be done only from targets of one buildfile, for cleanness.
BAsically it's like making only one import possible and many includes.
As I said, I think we must be open - if you really need this we can
add hooks to allow this to be implemented using 'meta tasks'. I will vote -0 on it, at least for 1.6.
Why? It's based on your hints.
What do you think? Does this make sense?
I don't think I'll use this, but if you really need it - I'm -0 :-)
I would do it as a task ( <extend> ) - and the hooks that are needed.
No, you don't get what I mean.
Ok, let's try again :-|
<include> includes like xml entities. sometimes there are name clashes but you still want to reuse the buildfile. So you import adding prefixes to the properties-targets.
This is to make it possible to call targets, but it makes it cumbersome to hook into a predefined build dependency tree.
To do it, you need to override targets.
For this, you <import> a buildfile, and have included the new targets and overridden the already present ones.
You can access the importes target via <target name="imported.thetarget"> (was super.thetarget or file:target)
What happens when you import more files? It's a mess, like in XSLT and in multiple inheritance.
So we make only one import available.
If you need more, you can include different buildfiles in one, and import that.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
