In message: <[EMAIL PROTECTED]> Mark Howard <[EMAIL PROTECTED]> writes:
[on creating custom tasks for ant] >When you say frequently, how often do you mean. I personally have never >had to extend ant (and so never needed the api). It really depends on what you're doing. If all you use ant for is compiling standard stuff for deployment in an app server, then you almost certainly won't need to extend ant. If you're writing a compiler, then you almost certainly will need to extend ant (as-is, it doesn't cope all that well with multiple ways to generate .class files (some from a java compiler, some as output from a template tool, and some of it handcrafted (and just copied))). Ant also does not cope well with having to do multiple compilation passes (one java source getting compiled, then the resultant class image being used to create constants in another machine-generated java source file, which then gets compiled). Perhaps my applications are unusually baroque, but I find I have to create custom tasks whenever I try to use ant. As a result, I've largely stopped trying to use ant, and instead use make with some custom dependency analysis tools to identify and atomicize circular references. (If I ever get enough free time, I'll complete my own build marshalling tool... I've already got it 90% designed, it just needs implementation.) >Do you disagree that it would be worthwhile to split the package into >one containing the core manual and an additional one with the api docs >and any advanced manual? It would not be worthwhile for me, because I'd have to install both whenever I actually had need of the manual. (If I'm just installing ant because it's a build-depend for something else, then I don't need any of the manuals.) Other people may have other usage patterns, and thus may find the separation worthwhile. - Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
