--- Tim Ellison <[EMAIL PROTECTED]> wrote: > Matt Benson wrote: [SNIP] > > -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' ? >
The particular example I was thinking of was in the top-level build.xml, the awt-swing stuff is conditionally built using its own target "build-awt-swing" which is <antcall>ed from the "build" target. In this case my assumption is that this target exists only to provide the conditional functionality via the target's if attribute (correct me if I'm wrong Mark), but the concept remains: the command line 'ant build-awt-swing' will execute just that target. Perhaps "atomic" was a bad description; I was only trying to communicate the idea of a target that we want to be able to build by itself as opposed to a target that has only been added for convenience. Now, in the case of "build-awt-swing", again I am inclined to believe it is actually the latter, but whether "build-awt-swing" needs to be a separate target from "build" would influence the decision of what approach to take when eliminating the antcall. > > 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). > It should be in direct proportion to the number of antcalls currently taking place in a given target. [SNIP] > > 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? This may be more clear after my having (attempted to, anyway) explained the "atomic-or-whatever-term-fits-better target" concept. A macro is not a target in its own right; it is more like a (in this case) locally defined task--a task that happens to contain multiple other tasks. Contrast preset which allows on-the-fly definition of a single task with some (or all, but usually some) of its attributes and child elements "preset". These are complementary Ant 1.6 tools with which whole libraries of custom tasks can be (and indeed have been) built. If a given target is only ever called as an antcall, it is most likely a macro masquerading as a target. > > > 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! > Thanks for the support. -Matt > 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] > > __________________________________________________ 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]
