Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of george.c.harley@googlemail.com
 designates 64.233.162.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=KsJ2RjFnu6aDxB3fd3CG9iKIl0k3hh9qFaNeVKKscunUlzYv8Aik2BhAavr7dJU4t/v8Et58pSGjUOvvdvicXEKaqM0YqAwYcHHWP2M9izMcniluiUEC9gZUF5Gk45ytKXGoEGBggz79H1cF/vfv7zeEQBtaJyRH0g7TB0QhjGk=
Message-ID: <44A693FE.9060409@googlemail.com>
Date: Sat, 01 Jul 2006 16:25:50 +0100
From: George Harley <george.c.harley@googlemail.com>
Reply-To: harmony-dev@incubator.apache.org
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] build file stuff
References: <002a01c69c93$4fe9b640$0b01a8c0@LITTLEGUY>
In-Reply-To: <002a01c69c93$4fe9b640$0b01a8c0@LITTLEGUY>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <gudnabrsam@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