harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] build file stuff
Date Mon, 03 Jul 2006 10:13:53 GMT
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 <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
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message