You're post is too long to answer in detail and I don't have the time
these days to go back and forth with you, but I'll still make a few
observations.
First, your hierarchy seems wrong. Putting the build.xml, classes
output dir, etc... in the source tree feels wrong. It's much better to
stick to the tried and true layout of a top level build.xml, with
src/java, src/cpp. I use a single build/ output dir myself, with
build/classes, build/resources, build/${os}/libs, etc...
A top level build doesn't mean you don't have other builds. I build
native code in separate auxiliary builds I <subant> into. But I almost
never call on these directly, and go thru the top level. C++ compile
are fast enough with CppTasks, since triggered only when necessary.
Enforcing proper package dependency is a good thing, I agree, but
unless your project is huge (in which case it should be broken up),
it's better to use a single compile target, from the top level build.
You can enforce the proper dependencies by doing the compile in stage
with sourcepath="" and outputting each component (set of packages that
work as a unit) to a different classes dir. That's basically what
<compilewithwalls> does, but it's easy to do yourselve. That way, you
can compile everything very easily, and still enforce dependencies.
To be able to restrict testing to a subset of the whole tree, I simply
use properties to include/exclude some tests in <batchtest>, and
sometimes custom file selectors as well.
It's probably not what you wanted to hear, sorry. I think you and your
team are making it harder that it needs to be. Switch gears to a
single top-level build. That's a model the Ant-enabled IDE support
well too, as opposed to the Makefile-smelling build.xml in several
places in the source tree.
Like I said, I'm afraid I won't have much time to participate much
more to this thread. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
