ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Problems with <import>
Date Sat, 20 Jul 2002 09:10:00 GMT wrote:
> On Sat, 20 Jul 2002, Nicola Ken Barozzi wrote:
>>>That's a bit orthogonal - whatever is at top level has allways been
>>>executed before anything else. 
>>>If we add explicit init/destroy - different issue.
>>I mean that it's sensible to deprecate IMHO amy top-level task being 
>>run, and have them in <init>.
> What do you mean "it's sensible to deprecate top-level tasks" ???
> It cetainly isn't - this is how many people like to use ant, this is how 
> ant allways worked - and if you don't want to use top-level, just don't. 
> It is very insensitive to deprecate things that other like just because
> you don't ( or think others are stupid and you know the 'right way' ).
> Especially when you can do things your way, and deprecating won't 
> allow the other people to do things their way. 

I said "deprecate", not "remove".

>>Which completely hides the semantics, since "destroy" is not 
>>conceptually what we want to run.
> I see no problem with adding a 'destroy' tag - as new functionality.

Good :-)

> For 'init' - there is already a way to do what you want.

In 1.5? I can run *any* top-level task?

> (I wouldn't use 'destroy' name for many reasons - especially in 
> a build file )

np, I really can't find the right word, I don't like "destroy" either, 
suggestions welcome :-)

>>>In your sample build.xml, mb2 depends on super.mb2. What does it
>>>means ??? 
>>in java:
>>class mybuild extends mybuild2
> I'm more confused here - extend and import are very different
> things. I don't mind an 'extend' ( especially if you can extend
> only one class ), but for 'import' you may have multiple
> imports - and most people would be confused if import would
> behave as extend ( I am ).

Well, XSL works like this.
With import, you don't extend a project, but override targets/templates.
In Java you cannot without extending the class, please look at the XSL 
spec for <include> and <import> to understand what I mean.

>>>Finding the right hooks is the only problem, I don't want to 
>>>expose too much SAX.
>>In which sense it may be a problem?
> Well, tasks like 'import' or 'depend' ( or others - antlib 
> may need that, etc)  that operate on  the project structure shouldn't 
> 'see' SAX. The current model of adding code to ProjectHelperImpl is 
> not very good IMHO - ant should work without any XML involved 
> ( embeded for example ). I don't want to hook Import using SAX.

Ah, ok. +1

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message