Targets are not functions :)
But they are... aren't they... sort of...? I guess its the programmer in me wanting to fit ANT into my programming mentality.
Here is what I am trying to do (one example): We support several app servers with our EJB product. We have a target defined for generating the EJB stubs for each one. So if I want to test out code with the Borland server, I can "ant borland", or for WebLogic, "ant weblogic".
Now I want a another target that builds all our app-server specific code, "ant all". So the ALL target is defined like:
<target name="all" depends="init, compile">
... do some prep work here...
<antcall target="borland"/>
<antcall target="weblogic"/>
...
</target>I cannot just list "borland, weblogic" in the depends= property because I have to do some processing (specific to the ALL target) before those targets are run.
Is there another way to structure this to avoid the use of ANTCALL?
Targets may not have been intended as 'subroutines', but they seem like a natural way to setup an easy-to-maintain build file. IF I could just keep the dependencies from being re-evaluated.
-Mark
At 01:20 AM 12/18/01, you wrote:
From: Mark McMillan [mailto:[EMAIL PROTECTED]
> The problem (to me) is that ANT's target dependency > processing (talking > about "depends=" on targets here) is too simplistic.
> I then > build more complex targets that combine some tasks with > ANTCALLs to the simpler targets.
Without seeing specifics it sounds like you are over(ab)using antcall.
Are you sure you need to be using <antcall> so much? Targets are not functions :)
NOTICE
This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
