At 01:01 12/1/01 -0500, Rosen, Alex wrote: >OK, switching over to ant-dev... > >> perhaps - but we already have "methods" via ant-call and they were >> generally found to be lacking. A few days ago [EMAIL PROTECTED] posted >> something to ant-dev titled "The RIGHT Direction for ANT" which pretty much >> reverted me to thinking that static templating is way to go. He also >> advocated separation between rules/templates and data operated on. If you >> think it is backward you should pop onto ant-dev and respond to this >> message ;) > >Unfortunately I don't feel I have the knowledge to comment on that message, >since I have no experience with very large projects, or dependency generators. >If we really think that any moderately complex project will need to be built >via a dependency generator, and the Ant file itself will never be seen by >humans, then my point is irrelevent. I'm not convinced of this, however. There >are still LOTS of complex projects that use hand-written Make files, and I >suspect that will always be the case with Ant, too, whether that's the right >way to go or not. > >> ant-call is your friend. It is here and now ;) Thou it may >> not be in the future - who can tell ;) > >(1) <ant> and <antcall> are currently lacking, but is that because they don't >belong, or because they just need improvement? Or the Ant system could be >friendlier to this style of usage?
Essentially because Ant1.x "grew" rather than being designed from the start and consequently each ant-call will completely reparse the whole build file which bites. If thats what you mean by lacking then - yes this will go away - if you mean something else then explain ;) These will probably still remain in some form because users would scream for blood if we took it out ;) For Ant2.0 there has been a number of proposals that allow segragation of builds across multiple build files. There has also been the XSLT for templating so in a sense the usefulness of ant-call/ant will decrease as it now only useful for dynamic templating. "dynamic" templating being those templates that are determined by runtime setting of properties. I am not sure if "dynamic" templating is necessary or even useful thou so ... ;) >(2) I'm arguing more about Ant 2.0 than now, so this discussion is very much >relevent. kewl ;) >> essentially. All procedural-ness is hidden in tasks and tasks >> should NOT >> interact with each other. > >I understand what you mean, but that's clearly not the case in one sense. When >I execute a <javac> task and then a <jar> task, these tasks do "interact" in >some sense, in that the <jar> task wouldn't do anything useful if it were not >preceeded by the <javac> task. If I switch the order of these XML elements, it >breaks. right - there will be indirect interaction but I was more thinking that <if condition="foo"> <task1 .../> <task2 .../> </if> where if interacts with task1/2 should not be encouraged. >I agree that there's a continuum from declarative to procedural. But some >things are more over toward one side or the other. Anything where order matters >is clearly more procedural than declarative, and that's clearly true of <javac> >and <jar>. The minute you have both of these tasks in the same file, you're >making an inherently procedural statement - first do this, then do that. >There's really nothing declarative about it, and that seems like a useful >distinction to make. And, it shows that "all procedural-ness is hidden in >tasks" is not completely true. right ;) >Here's a radical idea (though I wouldn't be surprised if it's been thought of >before and rejected). What if *all* procedural-ness had to be written in Java, >but that Java could go in the same file as the declarative statements? Then >your earlier example might become something like: eek :) If we were going to go this path there would no longer need be a distinction been targets and tasks because targets are essentially sequences of tasks. Besides - do you know how much hell that would be to program Ant - and maintain the build files ;) A large proportion of our target audience doesn't know java, may not know any prorgamming language and just uses ant to do platform independent building of websites etc. >This idea is more of a thought experiment than an actual proposal. But I think >it does actually make things cleaner - the declarative code is in XML, and the >procedural is in Java. (JavaScript could be supported too.) You've got all the >scripting features you want (functions, looping, etc), without sullying the >dependency information. Right - we used to actually recommend the script task for precisely these reasons but it seems to have gone out of vogue at the moment ;) Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
