Jose Alberto Fernandez wrote:
--- Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote on
07/11/2002 05:48:41 PM: >
[EMAIL PROTECTED] 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.
the first version viasuper. is a special prefix. If I redefine mycooltarget two times I can call
super.mycooltarget .super.super.mycooltarget , and the second version
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
