Mostly, I think I need the SolrTestCaseJ4 (and thus the Lucene test case, Solr change is coming soon) as it is really useful for writing down stream tests that test applications that use Lucene/Solr, but if it's too big of a problem, I'm fine with reverting this and Drew and I can just publish our own Jar file.
except its called from 'ant package', so I will see 'BUILD FAILED' if i refactor something that breaks this (lets say I split up LuceneTestCase, etc).
While agree with the "Build Failed" notion in general, I often think that it's a bit short sighted in that we make something marginally less annoying for us the committers (really, is it that hard to fix?) and much harder for our users b/c they have to go re-invent the wheel. Not everyone is an expert. We have to balance those two. I think instead of putting up roadblocks on principal to these kinds of things, we need to figure out ways to automate them and validate them so that it is hard to break.
I see a different tradeoff: 'maybe' breaking an unsupporte .jar to 'always' fetching a 7MB useless file ...
As for the 7mb file, really, that's an issue these days? OK, well if it is useless than maybe, but... At any rate, what, does that take like 30 seconds to download, tops? I downloaded the Freebase dataset last night (1.6GB) for fun!
Committed revision 1064066 (3x).
Committed revision 1064068 (trunk) - added more files to testfiles that exist only in trunk.
How about some common courtesy here? Making a decision in the middle of the night (for me) to commit something I was working on without getting my input is pretty rude. Is the issue really that urgent that it couldn't wait a few hours? I mean were you all of a sudden forced to download a 7mb file?