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
-~----------~----~----~----~------~----~------~--~---
