ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: <import> enhancement, it's done, but do you like how it works?
Date Thu, 11 Jul 2002 14:25:43 GMT

Jose Alberto Fernandez wrote:
>  --- Nicola Ken Barozzi <nicolaken@apache.org> wrote:
> 
>>dion@multitask.com.au wrote:
>>
>>>Nicola Ken Barozzi <nicolaken@apache.org> wrote on
>>
>>07/11/2002 05:48:41 PM:
>> >
>>
>>>>dion@multitask.com.au wrote:
>>>
>> >>
>>
>>>>>Is super.mytarget a 'special' keyword? Given that
>>>>>you're 'redefining' that 
>>>>>target (mytarget), what does antcalling it do?
>>>>>This is confusing IMHO for an end user.
>>>>
>>>>Hmmm...
>>>>It works like in java.
>>>
>>>Well java methods don't have dependencies..... and
>>>this will break 
>>>compatibility with all targets that are defined as
>>>'super.XXXX'.
>>
>>Hmmm...
> 
> I see no reason why you need to consider "super" as
> special, from the point of view of the ANT engine. The
> implementation just needs to do a syntactic rewrite.
> 
> You ask about backward compatibility. I see no
> compatibility issue at all. If you have targets called
> "supper.XXXXX" they are just there.
> 
> If you have "super.XXXX" and "XXXX" there is no issue
> either.
> 
> If you import such a buildfile into another AND
> redefine "XXXX", then the rewriting rule will renamed
> the original "XXXX" to "super.XXXX" which should cause
> a parsing error since you have two targets with the
> same name (just as it complains today). 
> 
> Is this a backward compatibility issue? NO. In this
> situation you are modifying the build, directly or
> indirectly. Backward compatibility only means that old
> buildfiles have to keep on running as intended.
> It does not mean that I can start using anything new
> and not have to change something.
> 
> Actually declaring targets "XXXX" and "super.XXXX" on
> the same file could be considered a hacky way to
> forbid overiding of "XXXX" on any imports.
> 
> 
>>>>super.  is a special prefix.
>>>>If I redefine mycooltarget two times I can call
>>>
>>the first version via 
>>
>>>>super.super.mycooltarget , and the second version
>>>
>>super.mycooltarget .
> 
> This actually I do not like. I do not mind that it is
> an unintended consequence, but I do not think it
> should be promoted.

Currently it's not doing it.
It does have a loop to write super. n times, but n is now fixed to 1.

I don't see it as particularly needed, but not as a liability either.

>>>>Any suggestions on how it can be made better?
>>>
>>>Don't use antcall and target..... add a new tag to
>>>call the overidden 
>>>one.....lots of other possibilities...??
>>
>>Ok then how about:
>>
> 
> All the alternatives below require not only providing
> a new project-helper but also modifying ANTs engine.

Not AFAIK.

> Which means it cannot be used as an add-on to ANT1.5
> and most probably would only work as part of ANT2.
> 
> I still think there is room for doing it syntacticly
> (i.e., in ProjectHelper). It may not be as perfect as
> it could, but I think it can be done.

The below things can all be done within projecthelper, and maybe we 
would need to add a new Task, but it still can be used in 1.5.

> See ideas below.
> 
> 
>>(a)
>>
>>  <target name="mytarget" >
>>    <dostuff1/>
>>    <antcall target="mytarget" super="1"/>
>>    <dostuff2/>
>>  </target>
>>
>>(b)
>>
>>  <target name="mytarget" >
>>    <dostuff1/>
>>    <super level="1"/> <!-- level is optional -->
>>    <dostuff2/>
>>  </target>
>>
>>(c)
>>
>>  <target name="mytarget" allowoverride="true" >
>>    <dostuff1/>
>>    <super target="mytarget"/>
>>    <dostuff2/>
>>  </target>
>>
>>(d)
>>
>>  <target name="mytarget" >
>>    <dostuff1/>
>>    <antcall target="mytarget"
>>select="this|super|super.super|..."/>
>>    <dostuff2/>
>>  </target>
>>
>>(e)
>>
>>   combinations of the above.
>>
> 
> 
> One pattern you guys forgot is:
> 
>   <target name="mytarget" depends="super.mytarget">
>     <dostuff1/>
>   </target>
> 
> which adds more things to do on the target. And:
> 
>   <target name="mytarget" 
>           depends="mytarget-local,super.mytarget"/>
> 
>   <target name="mytarget-local">
>     <dostuff1/>
>   </target>
> 
> which executes super after. Both will mix the
> dependency trees. This I think uses more of the power
> of ANT than just limiting ourselves to <antcall/>
> of course <antcall/> should be supported.

Ah ok, cool :-)

> With respect to the syntax of "super" what I would
> probably do instead of denoting it just as the string
> "super.XXXX" I would use some different notation,
> for example:
> 
>   <target name="mytarget" 
>      depends="${ant::super(mytarget)}">
>     <dostuff1/>
>   </target>

For Java writers super. is more easy to see, and less intimidating than 
:: ...

Hey, but it's a property... hmmm...

> now, I doubt anybody has a property called like that.
> So I think the backward compatibility issue is
> negligeable. The advantage I see with this notation is
> that it allows ProjectHelper to do more powerfull
> rewriting. In the following situation, for example:
> 
> File: ${basedir}/includes/A.xml
>   <target name="mytarget" depends="a,b,c">
>     <dostuff/>
>   </target>
> 
> File: ${basedir}/build.xml
>   <import file="includes/A.xml"/>
>   <target name="mytarget" 
>      depends="${ant::super(mytarget)}">
>     <dostuff1/>
>   </target>
> 
> The rewriting done by ProjectHelper will look like:
> 
>   <target name="include/A.xml::mytarget" 
>           depends="a,b,c">
>     <dostuff/>
>   </target>
> 
>   <target name="mytarget" 
>      depends="include/A.xml::mytarget">
>     <dostuff1/>
>   </target>
> 
> Notice that all the rewriting can be computed
> statically, so there is no issue here.
> 
> This particular mangling rule for the overriden
> targets has the advantage that when we see the
> execution of the build we will be able to identify
> which version of the target is under execution at any
> time. Notice that everthing stays syntactic with no
> changes on any of the tasks, in principle.
> 
> And as with my comments above, if after rewriting
> something clash, then the files are not upward
> compatible, which is OK.
> 
> comments,

Well, it's basically what the patch does (or should do ;-), but IMHO 
what the patch does is simpler.

I don't understand what using a property versus super.taskname brings 
you, could you explain?

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


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


Mime
View raw message