Matt, this sounds great to me. Thanks! I look forward to the JIRAs. I had a couple of things I was still thinking I'd change (descriptions in the top-level and module build.xml files was one of them). I was also wondering if it was better to use imports for the make/build-*.xml files since these are not supposed to be called directly any more.
Aside: Does anyone still call these [make/build-*.xml] directly? If so, perhaps we need more top-level targets. I'm quite busy anyway so I'll hold off on my changes until you've had a good look at them. Regards, Mark. On 29 June 2006 at 8:56, Matt Benson <[EMAIL PROTECTED]> 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. > 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. > > 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 > 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. > > 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. > > 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! :) > > 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. > > -Matt > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
