Return-Path: 
 <harmony-dev-return-9535-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 57370 invoked from network); 29 Jun 2006 20:04:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 29 Jun 2006 20:04:53 -0000
Received: (qmail 75444 invoked by uid 500); 29 Jun 2006 20:04:50 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 75404 invoked by uid 500); 29 Jun 2006 20:04:50 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 75385 invoked by uid 99); 29 Jun 2006 20:04:50 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 13:04:50 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Received: from [206.190.58.159] (HELO web55110.mail.re4.yahoo.com)
 (206.190.58.159)
    by apache.org (qpsmtpd/0.29) with SMTP; Thu, 29 Jun 2006 13:04:49 -0700
Received: (qmail 94101 invoked by uid 60001); 29 Jun 2006 20:04:27 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=pM9RKY97/vxSyrTviIoK/wq6FFxnKQSSl7uydSBS1c2y/np9tcfXLHzBleeK8JZu4KY5sB0eoDrtWk93JNUghJEml1VKNwwsBwQTZVlJ0O5/G3IonP8HVFHmfUEUNxh0Fr6ygss9SC3Pjg1velB0rj8H3wZAGlmenjE7SVBFDIs=
  ;
Message-ID: <20060629200427.94099.qmail@web55110.mail.re4.yahoo.com>
Received: from [66.10.233.130] by web55110.mail.re4.yahoo.com via HTTP;
 Thu, 29 Jun 2006 13:04:27 PDT
Date: Thu, 29 Jun 2006 13:04:27 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: Re: [classlib] build file stuff
To: harmony-dev@incubator.apache.org
In-Reply-To: <44A42776.9050609@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

--- Tim Ellison <t.p.ellison@gmail.com> 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 (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
> 
>
---------------------------------------------------------------------
> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> 
> 


__________________________________________________
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org