We currently don't generally use jars as the actual classpath for testing though
understood, #1 is just an argument i've seen as to why it would be better to do so – otherwise we never actually know when testing that our jars are useful – someone could accidentally put "excludes="*.class" on a jar task and you'd never notice because all the tests would still pass.
by never creating a jar in the first place your #2 doesn't happen at all really.
note step #a ... the point is if someone does whatever officially blessed step there is to build the jars ("ant", "ant jar", "ant whatever") and then decides they want to change the behavior of those jars – they may never run "ant clean" and it may not occur to then to re-run whatever that official way to build jars is and they may not notice that the jar's aren't rebuilt when they do "ant test" – because they can already see the new code was "compiled" and running based on the test output.
Also, if we were to go with your logic, really we should be rebuilding the solr.war everytime
correct, a war is just a jar with a special structure
(I'm just pointing out why i think its infeasible). ... I think we need to keep this stuff fast so that compile-test-debug lifecycle is as fast as possible
agreed ... like i said, i don't have a strong opinion about it, but since we're discussing it i just wanted to point out the arguments i've heard over and over when having this discussion in the past on other projects.
I think in an ideal world, devs could run fast tests against ../*/classes/ directories, but jenkins would run all those same tests against fully build jars to ensure they aren't missing anything ... but that would probably be an anoying build.xml to maintain