harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@kc.rr.com>
Subject RE: [classlib] build file stuff
Date Mon, 03 Jul 2006 04:00:59 GMT
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 <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


Mime
View raw message