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:[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] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
