override

[Conor MacNeill <co...@cortexebusiness.com.au>]

I'd like to take a slightly different angle on the <import> issue by getting 
some thoughts on this little experimental task I wrote. I haven't cleaned it 
up at all (lots of unused imports, inner classes etc). Anyway it lets you 
override any target in the build. e.g. This build file

<project name="override" default="test">

  <taskdef name="override" 
classname="org.apache.tools.ant.taskdefs.Override"/>
  <taskdef name="super" 
classname="org.apache.tools.ant.taskdefs.Override$Super"/>

  <override target="test">
    <echo message="pre"/>
    <super/>
    <echo message="post"/>
  </override>

  <override target="test">
    <echo message="pre2"/>
    <super/>
    <echo message="post2"/>
  </override>

  <target name="test">
    <echo message="test"/>
  </target>

</project>

produces the following output
Buildfile: build.xml

test:
     [echo] pre2
     [echo] pre
     [echo] test
     [echo] post
     [echo] post2

BUILD SUCCESSFUL

:-)

I think with a renaming <import> task this would let you override any part of 
the build easily.

BTW, note that simple renaming of targets is not enough. Any use of a target 
name needs to be updated too (e.g. <antcall>). Can be done (at time of use) 
but may require tasks knowing their import prefix. The import task will need 
this to do cascade renaming.

Anyway, just thought I'd throw it out there. Override might even be useful in 
an entity includes approach.

Comments?

Conor

Re: override

[Nicola Ken Barozzi <ni...@apache.org>]

Conor MacNeill wrote, On 31/07/2003 15.44:

> On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
> 
>>The only thing that comes to mind is that I cannot use super ion
>>dependencies, which is a nifty feature :-(
> 
> Not sure why this would be needed. Just add <super/> as the first contained 
> task. All of the other dependencies will have been run by then (i.e. the 
> dependent targets of the original target, represented by <super/>).

I mean, if I need to run super before *other target dependencies*, I 
should do:

   <target name="test">
     <super/>
     <antcall target="anotherone">
   </target>

While it's more resource efficient to have:

   <target name="test" depends="super,anotherone"/>

Of course, unless we introduce this (which is nice too):

   <target name="test">
     <super/>
     <depends target="anotherone">
   </target>


>>>BTW, note that simple renaming of targets is not enough. Any use of a
>>>target name needs to be updated too (e.g. <antcall>). Can be done (at
>>>time of use) but may require tasks knowing their import prefix. The
>>>import task will need this to do cascade renaming.
>>
>>Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk
>>thing I outlined?
>>
>>Could you please expand on this, I'm interested.
> 
> Sure. Consider this change to my previous example. It represents rather poor 
> practice but can happen
> 
>   <target name="test">
>     <property name="tricky" value="critical"/>
>     <antcall target="${tricky}"/>
>     <echo message="b.test"/>
>   </target>
> 
> So the target that <antcall> has to really call is not known until the antcall 
> is actually executed. Antcall has to evaluate the property, get the value 
> "critical", look at its own import prefix "b" and decide to therefore call 
> "b.critical". Some smarts may be possible there if, for example, b.critical 
> does not exist.

Now I get it.

But this is about scoping calls, not only renaming tasks. IIUC the 
xslt-like scenario described in the other thread does not need this 
renaming.

Again IIUC, this renaming would effectively make the 
multiple-inheritance without import-line crosstalk that I talked about, 
but that in the other thread seemed to bring problems.

Aaarg @-|

I'm still confused...

> Similarly when imports are processed. Consider if a.xml imports b.xml with 
> prefix "b" and b.xml imports c.xml with prefix "c" then c's targets actually 
> need to be renamed to b.c.test in the final project To do tjhis the imprt 
> task needs to concatenate its own import prefix with given prefix. Of course 
> prefixes would be optional and then target name collisions would cause an 
> error, I think.

So this is what happens when we try to rename also the dependencies...

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: override

[Conor MacNeill <co...@cortexebusiness.com.au>]

On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:

> The only thing that comes to mind is that I cannot use super ion
> dependencies, which is a nifty feature :-(

Not sure why this would be needed. Just add <super/> as the first contained 
task. All of the other dependencies will have been run by then (i.e. the 
dependent targets of the original target, represented by <super/>).

>
> > BTW, note that simple renaming of targets is not enough. Any use of a
> > target name needs to be updated too (e.g. <antcall>). Can be done (at
> > time of use) but may require tasks knowing their import prefix. The
> > import task will need this to do cascade renaming.
>
> Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk
> thing I outlined?
>
> Could you please expand on this, I'm interested.

Sure. Consider this change to my previous example. It represents rather poor 
practice but can happen

  <target name="test">
    <property name="tricky" value="critical"/>
    <antcall target="${tricky}"/>
    <echo message="b.test"/>
  </target>

So the target that <antcall> has to really call is not known until the antcall 
is actually executed. Antcall has to evaluate the property, get the value 
"critical", look at its own import prefix "b" and decide to therefore call 
"b.critical". Some smarts may be possible there if, for example, b.critical 
does not exist.

Similarly when imports are processed. Consider if a.xml imports b.xml with 
prefix "b" and b.xml imports c.xml with prefix "c" then c's targets actually 
need to be renamed to b.c.test in the final project To do tjhis the imprt 
task needs to concatenate its own import prefix with given prefix. Of course 
prefixes would be optional and then target name collisions would cause an 
error, I think.

Conor


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: override

[Nicola Ken Barozzi <ni...@apache.org>]

Conor MacNeill wrote, On 31/07/2003 14.07:

...
> I think with a renaming <import> task this would let you override any part of 
> the build easily.

Very cool indeed :-)

[I'd like to thank all the ones that are discussing on import. Very nice 
posts and constructive stuff, I love you guys :-)]

It seems that we can then make these tasks:

  <include>   :like entity includes
  <override>  :like your example
  <import>    :both of the above (do we want it at all?)
                                 (would i tdo other things?)

Separating converns makes both more simple both to understand and reuse. 
Not though about the implications much, but I really like it.

The only thing that comes to mind is that I cannot use super ion 
dependencies, which is a nifty feature :-(

> BTW, note that simple renaming of targets is not enough. Any use of a target 
> name needs to be updated too (e.g. <antcall>). Can be done (at time of use) 
> but may require tasks knowing their import prefix. The import task will need 
> this to do cascade renaming.

Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk 
thing I outlined?

Could you please expand on this, I'm interested.

> Anyway, just thought I'd throw it out there. Override might even be useful in 
> an entity includes approach.

Very interesting.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: override

[Antoine Levy-Lambert <an...@antbuild.com>]

Looks interesting.
Cheers,
Antoine

----- Original Message -----
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
To: <de...@ant.apache.org>
Sent: Thursday, July 31, 2003 2:07 PM
Subject: override


> I'd like to take a slightly different angle on the <import> issue by
getting
> some thoughts on this little experimental task I wrote. I haven't cleaned
it
> up at all (lots of unused imports, inner classes etc). Anyway it lets you
> override any target in the build. e.g. This build file
>
> <project name="override" default="test">
>
>   <taskdef name="override"
> classname="org.apache.tools.ant.taskdefs.Override"/>
>   <taskdef name="super"
> classname="org.apache.tools.ant.taskdefs.Override$Super"/>
>
>   <override target="test">
>     <echo message="pre"/>
>     <super/>
>     <echo message="post"/>
>   </override>
>
>   <override target="test">
>     <echo message="pre2"/>
>     <super/>
>     <echo message="post2"/>
>   </override>
>
>   <target name="test">
>     <echo message="test"/>
>   </target>
>
> </project>
>
> produces the following output
> Buildfile: build.xml
>
> test:
>      [echo] pre2
>      [echo] pre
>      [echo] test
>      [echo] post
>      [echo] post2
>
> BUILD SUCCESSFUL
>
> :-)
>
> I think with a renaming <import> task this would let you override any part
of
> the build easily.
>
> BTW, note that simple renaming of targets is not enough. Any use of a
target
> name needs to be updated too (e.g. <antcall>). Can be done (at time of
use)
> but may require tasks knowing their import prefix. The import task will
need
> this to do cascade renaming.
>
> Anyway, just thought I'd throw it out there. Override might even be useful
in
> an entity includes approach.
>
> Comments?
>
> Conor
>


----------------------------------------------------------------------------
----


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org