ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Problems with <import>
Date Sat, 20 Jul 2002 14:57:31 GMT
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 ? 

> > 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?

As I repeted several times, all I'm doing at the moment will 
work with 1.5 if you install ant-sax2.jar in lib. 

I'll be proposed for ant1.6 and the main branch - but I want
to be able to use it and to get feedback from  users - 
and not many people are using the main branch.

BTW, your 'destroy' and 'init' will be reasonably easy to 
add ( as 'special' tasks like import, implementing TaskContainer
and using a hook to detect the end ).

> > 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.

I did - in XSL the 'main' class, doing the import/include, 
has priority.

If you have multiple imports you can call the overriden targets - but
calling them super.super.super with the number of super depending on
how many imports were made before is inpractical.

> >>But the imported file can import and override the same target from a
> >>third file...
> >
> > And you can import 2 files defining the same target.
> >
> > Which will be 'super' in this case ?
> The firt one, as per XSL spec on imports.

And what about the second import, or the one imported from the first
import ? Which one will be 'super.super' ?

Using XSLT as guide, it'll be the one imported from the first import,
and the second import from main will be 'super.super.super'.

If the first imported build will change and no longer has an import - then
the second import from main will become super.super.

Doesn't seem very clean.

My proposal was IMHO simpler: use the project name to qualify.
> > Mixing 'import' with 'extend' is very dangerous.
> ?
> XSL spec, that's what I follow.

That doesn't mention 'super' and is not using and 'extend' semantic.
It's the 'super.super' naming I have a problem with.

> Say I have a master buildfile, that does all I need, *except* that I
> want to add a task at the end of a target it uses.
> I need "extend", or rewrite all targets that call the imported ones,
> which is a PITA.

What I'm proposing is allowing you do do that, except that instead
of using super. constructs you need to call the target using the
name of the master buildfile . target.


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

View raw message