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