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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
