Matt Benson wrote: > Now that I've (finally, thanks Gregory!) got the > classlib built I'd like to start playing with the Ant > buildfiles to apply some of the practices encouraged > with modern Ant versions, but possibly lesser-known to > old-school (aka "learned Ant 1.5.x or earlier") users.
That would be great. I'm definitely in that old school. I've learned enough to get by / cause trouble but definitely interested in learning more. > The first thing I plan to do is remove <antcall>s > wherever possible (which should be everywhere). <ant> > and <subant> run builds against other buildfiles; this > is sensible and the utility of it is obvious. > <antcall> calls targets from a local (or imported) > buildfile, creating a new Project instance in the > process, a time- and memory-intensive process. In Ant > < 1.6 <antcall>s could often be avoided by arranging > targets such that Ant's management of target depends > would take care of target interdependencies (the "Ant > way"); <antcall> remained useful for when some > parameterizable set of tasks was needed. Ant 1.6 saw > the advent of <macrodef> which accomplished the > purpose of <antcall> in (damn it) a cooler fashion, > without creating a new Project context. I joined Ant > right after the release of 1.6, and was myself daunted > by macros; I put off learning them until such time as > I couldn't claim I had anything else to do... but the > transition from antcalls to macros was painless. The > "rightness" of this feature has never been challenged; > macros have become a new and shiny facet of the "Ant > way" IMHO. Then show me the way so I can impress my friends ;-) > That may have turned a little religious, but I took > the time to write it, so it stands. :) Anyway, my > point is that antcalls are evil and that a combination > of target restructuring and macros can remove all but > the very stubbornest of them (I can't even remember > offhand what kind of situation leaves no alternative). > Here are the (IMO minimal) tradeoffs, for the sake of > allowing folk to voice any concerns: > > -When you are calling a target with an <antcall>, but > you also want it to be available as an atomic target What do you mean by 'atomic target' ? > of its own, that suggests the antcall should be > accomplished with target restructuring. To some this > might make the build seem more complex. In this > example: > > <target name="foo"> > <echo>foo</echo> > <antcall target="bar" /> > </target> > <target name="bar"><echo>bar</echo></target> > > the "foo" target would become: > > <target name="foo" depends="-foo,bar" /> > <target name="-foo"><echo>foo</echo></target> > > Now, I consider this "complication" of the buildfile > minimal, but I'm used to looking at such things. Still with you so far (but I guess it gets more complicated). > aside: the minus target naming, as some users may > know, is an old Ant trick that prevents a target from > being called from the command line due to the fact > that it is interpreted as a switch by Ant main. This > is of lesser value as Eclipse, as a handy IDE example, > does allow a user to directly run what is--by > convention only--considered an inner or private > target. I could have named it "innerfoo" for example. > Before we completely abandon the concept of inner > targets, let me mention that it might be a good idea > to always set descriptions on those targets intended > for user consumption, as in native-src/build.xml . > This causes Ant's -p/-projecthelp to display only > these targets, hopefully making the task of using a > new buildfile less onerous for a newcomer. In > contrast, classlib's top-level build.xml does not make > use of target descriptions. That is ignorance/laziness/oversight rather than deliberate, speaking for myself at least. > When you are simply using a target as a container for > a group of tasks, and the target itself is not meant > for public consumption, that suggests the target would > be better defined as a macrodef. And to be quite > honest, I'm having a hard time thinking of anything > negative to say about macrodefs. They really don't > make your buildfile any more complicated or anything > else.... ! Oh, well! :) How is that different from the 'inner targets' you were talking about before? > If anyone is still with me after this tome, my purpose > has been to elicit comment of any qualms anyone has, > particularly with regard to target/dependency > restructuring, before I start submitting JIRA issues > to remove <antcall>s. Go for it, that's the best way for us to learn. And thank you! Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]