On Mon, Jun 1, 2009 at 10:48 AM, Rajeev Dayal <[email protected]> wrote:
> If it is the case that a subsequent "ant build" after running "ant build" > is zero work provided that there are no code changes, then I am okay with > having "ant test" depend on "ant build". However, if running "ant build" in > a zero-work case takes a non-trivial amount of time, then we should > re-consider having "ant test" depend on "ant build". > It will be the case that the second of two back-to-back "ant build" commands will be zero work. (I think I have that part already, though I've gotten interrupted into FF 3.5b4 issues.) > I'd also recommend that running "ant test" rebuild the test classes > themselves, and the build step for test code should be zero-work if "ant > test" is run back-to-back with no test code changes in-between. > I think that's allready the structure; I'll double-check the zero-work bit. > A nice-to-have (i.e. less important than all of the other things you > mentioned) would be the ability to specify specific tests via the > command-line (maybe via a system property?). > That actually exists already, mostly, in that the little-known ant property gwt.junit.testcase.includes is an ant-style glob of tests to run. Its default value is **/*Suite.class, but you can override that to a narrower value if you like. What's missing, however, is the ability to anything fancier than a glob, like say a comma-separated lists. So you can easily restrict to a directory's suites, to to a specific suite, but it's harder to run say the RPC and I18N suites at once. > Rajeev > > > > On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott <[email protected]>wrote: > >> So, I'm looking at our ant files, and trying to unwind several problems... >> but I figure I'll ask what other people have as pet peeves, to see if there >> are other games I should play, too. >> >> Here's what's on my mind right now: >> >> - If you run "ant clean build; ant build", the second build should be >> zero work. It's not, and in particular it painfully builds samples twice. >> It shouldn't. >> - Right now, tests require a staging directory, which implies >> requiring a full distro kit including samples. That's unnecessary; tests >> should require build, but not much more. >> - Related to that, too much depends on the semi-recursive -do, >> which is actually a no-op that depends on dist, which pulls too much >> in for >> simple cases. >> - Largely orthogonal, we have checked in files with $ in their names, >> which are supposed to also be usable wtih _ instead. I've got a system >> which is badly allergic to the $'s, which is why this causes me pain, but >> generally it seems this "should" be addressed with alternate classpath >> roots >> anyway, so we can test both the two cases easily. >> >> Does anyone have other pain points to add? >> >> >> What I was thinking of doing is: >> >> - Shoot the top-level -do target, in favor of having subtargets >> directly invoke what they need from subprojects, via <antcall>, and >> setting >> "target" as is done today... so e.g. target "test" can depend target >> "build" >> or "buildonly" and then <antcall> the "test" targets of dev, user, etc. >> explicitly. Since -do would no longer exist, it wouldn't depend on "dist" >> to get the fan-out effects, and fan-out can be more selectively >> controlled. >> - Untangle whatever our double-build is caused by; at first blush, it >> seems to think my directories are out of date relative to the existing jar >> (not the files in them, but the directories themselves). >> - Change the default target to "dist," for back compatibility, since >> that's what build today really does (build depends on -do which depends on >> dist which depends on build in all the subprojects). >> - Twiddle the semantics of "build" to be just building. I haven't >> decided whether that would include building samples (probably; buildonly >> exists to skip that), but it wouldn't assemble the distro archive and then >> unpack it as dist does. >> - Introduce user/test_dollar and user/test_underbar as java-root >> directories with the obvious subset of files from today's user/test, and >> an >> adjustment to the test target one or the other is on classpath, >> controlled I >> think by a system property. >> >> Thoughts on that? >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
