> What if you want to build only the production classes ?
If you only want the non-test .class files, then use "ant dist" in my build scripts. That'll give you a jar of the production classes only, although it will compile everything.
It's not clear to me why one would want to compile the production classes but not the *unit* test classes, (checking that the unit tests compile and run on most builds is part of the point of unit tests) but it would be straightforward to add an ant target that does that.
> Maybe we should put the user documentations and
> examples in that directory too - that may encourage
> people to write more documentations :-)
Not only would I encougage you to put *unit* documentation in the same directory as the source, I'd encourage you to put in in the same file. It's called JavaDoc. ;-)
This is my point exactly. We place *unit* documentation in the source files themselves. Why? Because it's easier to keep them synchronized that way, it's easier to find them that way, it's easier to see what's covered and what's not that way, etc. I'm suggesting the same is true for the *unit* tests--tests of individual methods and classes.
> a) Creates a dependency on JUnit ( or whatever testing
> framework is used for that tests
This is absolutely valid, I guess that bothers me less than it does you.
> b) It's hard to compile the code without the
> test cases
Yes. By design this "encourages" you to compile the test cases when you compile anything else. I see that as a feature, but I understand where you might not.
> ( I understand you want to build them togheter,
> but you can't force everyone to do what you
> think is right ).
Well, if I put them all in the same source tree, I guess I *can* force everyone to do what I think is right. (I'm joking, mostly.)
> c) What happen if people use different testing
> framework and tools (please don't tell me JUnit is the
> only "real" thing ) ? Do we place all the test code in
> the same dir ?
Yes, I suppose that is what I'm suggesting: In general all *unit* tests, regardless of the framework, go into the same directory as the source it is testing. I think it is unlikely that a single component will use two distinct unit testing frameworks at the same time, but I don't see it as a major problem if it did. It's one more dependency, but at least I know all my tests work.
As a said before, I'm not sure it matters much. As long as I can run "ant test" (or something like that) to run all of the unit tests, I don't care a whole lot where they're located.
