You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/30 11:26:09 UTC
Re: [classlib] build file stuff
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 <gu...@yahoo.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
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
Re: [classlib] build file stuff
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Just checking :)
I'm sitting here on a work holiday trying to catch up...
geir
Tim Ellison wrote:
> (He's only teasing you, don't take the bait!)
>
> Geir Magnusson Jr wrote:
>> Why?
>>
>> Nathan Beyer wrote:
>>> Ah ha...I already do that, so all is well. It seems my lack of Ant knowledge
>>> is showing. Are we ready to move to Maven 2 yet? :)
>>>
>>>> -----Original Message-----
>>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>>> Sent: Monday, July 03, 2006 4:14 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib] build file stuff
>>>>
>>>> Nathan Beyer wrote:
>>>>> Cool, I'll use that instead. Is there any way to eliminate the junit
>>>> library
>>>>> dependency from the command-line?
>>>> Put the JUnit library into your Ant installation's 'lib' directory.
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>>>> -----Original Message-----
>>>>>> From: George Harley [mailto:george.c.harley@googlemail.com]
>>>>>> Sent: Saturday, July 01, 2006 10:26 AM
>>>>>> To: harmony-dev@incubator.apache.org
>>>>>> Subject: Re: [classlib] build file stuff
>>>>>>
>>>>>> Nathan Beyer wrote:
>>>>>>> Occasionally I use make/build-tests.xml to access the 'gen-reports'
>>>>>> target.
>>>>>>> I only do this when I run a test from within a single module, instead
>>>> of
>>>>>> a
>>>>>>> full test run. Maybe there is a better or easier way.
>>>>>>>
>>>>>>> -Nathan
>>>>>>>
>>>>>>>
>>>>>> Hi Nathan,
>>>>>>
>>>>>> Maybe this isn't exactly what you mean, but running tests for a single
>>>>>> module from the "top level" build.xml file (the one in
>>>>>> enhanced/classlib) and setting the "build.module" property always runs
>>>>>> the "gen-report" target at the end.
>>>>>>
>>>>>> e.g. to run just the nio tests and get an HTML report while working in
>>>>>> enhanced/classlib directory ...
>>>>>>
>>>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
>>>>>>
>>>>>>
>>>>>> ... and to build the nio jar and then run just the nio tests with an
>>>>>> HTML report generated at the end ...
>>>>>>
>>>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
>>>>>> test
>>>>>>
>>>>>>
>>>>>> The build.module property means that I rarely have to venture out of
>>>> the
>>>>>> enhanced/classlib folder.
>>>>>>
>>>>>> Best regards,
>>>>>> George
>>>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
---------------------------------------------------------------------
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
Re: [classlib] build file stuff
Posted by Tim Ellison <t....@gmail.com>.
(He's only teasing you, don't take the bait!)
Geir Magnusson Jr wrote:
> Why?
>
> Nathan Beyer wrote:
>> Ah ha...I already do that, so all is well. It seems my lack of Ant knowledge
>> is showing. Are we ready to move to Maven 2 yet? :)
>>
>>> -----Original Message-----
>>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>>> Sent: Monday, July 03, 2006 4:14 AM
>>> To: harmony-dev@incubator.apache.org
>>> Subject: Re: [classlib] build file stuff
>>>
>>> Nathan Beyer wrote:
>>>> Cool, I'll use that instead. Is there any way to eliminate the junit
>>> library
>>>> dependency from the command-line?
>>> Put the JUnit library into your Ant installation's 'lib' directory.
>>>
>>> Regards,
>>> Tim
>>>
>>>>> -----Original Message-----
>>>>> From: George Harley [mailto:george.c.harley@googlemail.com]
>>>>> Sent: Saturday, July 01, 2006 10:26 AM
>>>>> To: harmony-dev@incubator.apache.org
>>>>> Subject: Re: [classlib] build file stuff
>>>>>
>>>>> Nathan Beyer wrote:
>>>>>> Occasionally I use make/build-tests.xml to access the 'gen-reports'
>>>>> target.
>>>>>> I only do this when I run a test from within a single module, instead
>>> of
>>>>> a
>>>>>> full test run. Maybe there is a better or easier way.
>>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>>
>>>>> Hi Nathan,
>>>>>
>>>>> Maybe this isn't exactly what you mean, but running tests for a single
>>>>> module from the "top level" build.xml file (the one in
>>>>> enhanced/classlib) and setting the "build.module" property always runs
>>>>> the "gen-report" target at the end.
>>>>>
>>>>> e.g. to run just the nio tests and get an HTML report while working in
>>>>> enhanced/classlib directory ...
>>>>>
>>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
>>>>>
>>>>>
>>>>> ... and to build the nio jar and then run just the nio tests with an
>>>>> HTML report generated at the end ...
>>>>>
>>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
>>>>> test
>>>>>
>>>>>
>>>>> The build.module property means that I rarely have to venture out of
>>> the
>>>>> enhanced/classlib folder.
>>>>>
>>>>> Best regards,
>>>>> George
>>>>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
Re: [classlib] build file stuff
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Why?
Nathan Beyer wrote:
> Ah ha...I already do that, so all is well. It seems my lack of Ant knowledge
> is showing. Are we ready to move to Maven 2 yet? :)
>
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>> Sent: Monday, July 03, 2006 4:14 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] build file stuff
>>
>> Nathan Beyer wrote:
>>> Cool, I'll use that instead. Is there any way to eliminate the junit
>> library
>>> dependency from the command-line?
>> Put the JUnit library into your Ant installation's 'lib' directory.
>>
>> Regards,
>> Tim
>>
>>>> -----Original Message-----
>>>> From: George Harley [mailto:george.c.harley@googlemail.com]
>>>> Sent: Saturday, July 01, 2006 10:26 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib] build file stuff
>>>>
>>>> Nathan Beyer wrote:
>>>>> Occasionally I use make/build-tests.xml to access the 'gen-reports'
>>>> target.
>>>>> I only do this when I run a test from within a single module, instead
>> of
>>>> a
>>>>> full test run. Maybe there is a better or easier way.
>>>>>
>>>>> -Nathan
>>>>>
>>>>>
>>>> Hi Nathan,
>>>>
>>>> Maybe this isn't exactly what you mean, but running tests for a single
>>>> module from the "top level" build.xml file (the one in
>>>> enhanced/classlib) and setting the "build.module" property always runs
>>>> the "gen-report" target at the end.
>>>>
>>>> e.g. to run just the nio tests and get an HTML report while working in
>>>> enhanced/classlib directory ...
>>>>
>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
>>>>
>>>>
>>>> ... and to build the nio jar and then run just the nio tests with an
>>>> HTML report generated at the end ...
>>>>
>>>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
>>>> test
>>>>
>>>>
>>>> The build.module property means that I rarely have to venture out of
>> the
>>>> enhanced/classlib folder.
>>>>
>>>> Best regards,
>>>> George
>>>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
---------------------------------------------------------------------
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
RE: [classlib] build file stuff
Posted by Nathan Beyer <nb...@kc.rr.com>.
Ah ha...I already do that, so all is well. It seems my lack of Ant knowledge
is showing. Are we ready to move to Maven 2 yet? :)
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Monday, July 03, 2006 4:14 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] build file stuff
>
> Nathan Beyer wrote:
> > Cool, I'll use that instead. Is there any way to eliminate the junit
> library
> > dependency from the command-line?
>
> Put the JUnit library into your Ant installation's 'lib' directory.
>
> Regards,
> Tim
>
> >> -----Original Message-----
> >> From: George Harley [mailto:george.c.harley@googlemail.com]
> >> Sent: Saturday, July 01, 2006 10:26 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [classlib] build file stuff
> >>
> >> Nathan Beyer wrote:
> >>> Occasionally I use make/build-tests.xml to access the 'gen-reports'
> >> target.
> >>> I only do this when I run a test from within a single module, instead
> of
> >> a
> >>> full test run. Maybe there is a better or easier way.
> >>>
> >>> -Nathan
> >>>
> >>>
> >> Hi Nathan,
> >>
> >> Maybe this isn't exactly what you mean, but running tests for a single
> >> module from the "top level" build.xml file (the one in
> >> enhanced/classlib) and setting the "build.module" property always runs
> >> the "gen-report" target at the end.
> >>
> >> e.g. to run just the nio tests and get an HTML report while working in
> >> enhanced/classlib directory ...
> >>
> >> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
> >>
> >>
> >> ... and to build the nio jar and then run just the nio tests with an
> >> HTML report generated at the end ...
> >>
> >> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
> >> test
> >>
> >>
> >> The build.module property means that I rarely have to venture out of
> the
> >> enhanced/classlib folder.
> >>
> >> Best regards,
> >> George
> >>
---------------------------------------------------------------------
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
Re: [classlib] build file stuff
Posted by Tim Ellison <t....@gmail.com>.
Nathan Beyer wrote:
> Cool, I'll use that instead. Is there any way to eliminate the junit library
> dependency from the command-line?
Put the JUnit library into your Ant installation's 'lib' directory.
Regards,
Tim
>> -----Original Message-----
>> From: George Harley [mailto:george.c.harley@googlemail.com]
>> Sent: Saturday, July 01, 2006 10:26 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] build file stuff
>>
>> Nathan Beyer wrote:
>>> Occasionally I use make/build-tests.xml to access the 'gen-reports'
>> target.
>>> I only do this when I run a test from within a single module, instead of
>> a
>>> full test run. Maybe there is a better or easier way.
>>>
>>> -Nathan
>>>
>>>
>> Hi Nathan,
>>
>> Maybe this isn't exactly what you mean, but running tests for a single
>> module from the "top level" build.xml file (the one in
>> enhanced/classlib) and setting the "build.module" property always runs
>> the "gen-report" target at the end.
>>
>> e.g. to run just the nio tests and get an HTML report while working in
>> enhanced/classlib directory ...
>>
>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
>>
>>
>> ... and to build the nio jar and then run just the nio tests with an
>> HTML report generated at the end ...
>>
>> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
>> test
>>
>>
>> The build.module property means that I rarely have to venture out of the
>> enhanced/classlib folder.
>>
>> Best regards,
>> George
>>
>>
>>>> -----Original Message-----
>>>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>>>> Sent: Friday, June 30, 2006 4:26 AM
>>>> To: harmony-dev@incubator.apache.org
>>>> Subject: Re: [classlib] build file stuff
>>>>
>>>>
>>>> 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 <gu...@yahoo.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
RE: [classlib] build file stuff
Posted by Nathan Beyer <nb...@kc.rr.com>.
Cool, I'll use that instead. Is there any way to eliminate the junit library
dependency from the command-line?
> -----Original Message-----
> From: George Harley [mailto:george.c.harley@googlemail.com]
> Sent: Saturday, July 01, 2006 10:26 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] build file stuff
>
> Nathan Beyer wrote:
> > Occasionally I use make/build-tests.xml to access the 'gen-reports'
> target.
> > I only do this when I run a test from within a single module, instead of
> a
> > full test run. Maybe there is a better or easier way.
> >
> > -Nathan
> >
> >
>
> Hi Nathan,
>
> Maybe this isn't exactly what you mean, but running tests for a single
> module from the "top level" build.xml file (the one in
> enhanced/classlib) and setting the "build.module" property always runs
> the "gen-report" target at the end.
>
> e.g. to run just the nio tests and get an HTML report while working in
> enhanced/classlib directory ...
>
> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
>
>
> ... and to build the nio jar and then run just the nio tests with an
> HTML report generated at the end ...
>
> > ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
> test
>
>
> The build.module property means that I rarely have to venture out of the
> enhanced/classlib folder.
>
> Best regards,
> George
>
>
> >> -----Original Message-----
> >> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> >> Sent: Friday, June 30, 2006 4:26 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [classlib] build file stuff
> >>
> >>
> >> 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 <gu...@yahoo.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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
Re: [classlib] build file stuff
Posted by George Harley <ge...@googlemail.com>.
Nathan Beyer wrote:
> Occasionally I use make/build-tests.xml to access the 'gen-reports' target.
> I only do this when I run a test from within a single module, instead of a
> full test run. Maybe there is a better or easier way.
>
> -Nathan
>
>
Hi Nathan,
Maybe this isn't exactly what you mean, but running tests for a single
module from the "top level" build.xml file (the one in
enhanced/classlib) and setting the "build.module" property always runs
the "gen-report" target at the end.
e.g. to run just the nio tests and get an HTML report while working in
enhanced/classlib directory ...
> ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio test
... and to build the nio jar and then run just the nio tests with an
HTML report generated at the end ...
> ant -lib depends\jars\junit_3.8.2\junit.jar -Dbuild.module=nio build
test
The build.module property means that I rarely have to venture out of the
enhanced/classlib folder.
Best regards,
George
>> -----Original Message-----
>> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
>> Sent: Friday, June 30, 2006 4:26 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [classlib] build file stuff
>>
>>
>> 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 <gu...@yahoo.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
---------------------------------------------------------------------
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
RE: [classlib] build file stuff
Posted by Nathan Beyer <nb...@kc.rr.com>.
Occasionally I use make/build-tests.xml to access the 'gen-reports' target.
I only do this when I run a test from within a single module, instead of a
full test run. Maybe there is a better or easier way.
-Nathan
> -----Original Message-----
> From: Mark Hindess [mailto:mark.hindess@googlemail.com]
> Sent: Friday, June 30, 2006 4:26 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib] build file stuff
>
>
> 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 <gu...@yahoo.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
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
Re: [classlib] build file stuff
Posted by Matt Benson <gu...@yahoo.com>.
--- Mark Hindess <ma...@googlemail.com> wrote:
>
> 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.
>
If these could be changed to imports, yes, that would
be better than <ant> invocations, for similar reasons
as to why macros are better than <antcall>s.
-Matt
> 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
> <gu...@yahoo.com> 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.
[SNIP]
__________________________________________________
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