On Wed, 24 Jul 2002, J.Pietschmann wrote:
> [EMAIL PROTECTED] wrote:
> > This choice has a big impact on <import> or any other
> > task that is going to affect the project structure.
>
> Again, *why* has <import> to be a top level *task*?
> Why couldn't it just import taskdefs, properties,
> targets, whatever?
The problem is that <import> may reference previous properties
or other things. It has nothing to do with how import
is implemented.
With top-level tasks the properties are evaluated after
the whole file is read.
Previously ( i.e. what Nicola had in his patch ) you could
do <import file="${myfile}" >, but that no longer works.
I didn't find any easy way to make <import> work with
the current main branch - if you eval it too early all
the properties will be uninitialized, if you eval it after
properties - the dependencies have been resoved already.
> I recommend reading the spec of xsl:import. Even better,
> press Nicola to write down a formal spec of ant:import.
The only issue is what to do about import when you have
multiple targets with the same name.
The choices are:
- report error
- use the first, ignore all other ( but which one is first
depends on the implementation of the top-level, in the
original patch the import was processed before the rest
of the main targets )
- rewrite the name of the target to include the
project name ( what I'm doing in the PH2 impl )
- rewrite the name of the target to use 'super'
instead of the project name ( trivial to change,
but I don't necesarily agree with this - I think
this should be voted as is more a matter of taste ).
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
