1) Why run from source ?
Its a simple way to ensure that people using bigtop smoke tests :
- don't need to run mvn install or anything else ( i realize this can be abstacted into yet another wrapper, but for my response to that, see (2) below) .
- can modify Itest if they want, for some debugging/hacking and see results easily w/o getting confused why their changes arent absorbed.
- always have the latest fixes. Last updates to itest (
BIGTOP-1524) broke the smoke-tests and made running latest itest a requirement for mapreduce smoke tests.
So, where in test-artifacts, we say "install maven, then build these jars, then you can run bigtop tests, oh and if you want to modify them - clean rebuild everything, and start over" in smoke-tests we say "clone bigtop - then you can run these tests. modifications? go for it. no change to your workflow.". Which framework would you prefer as a user? For me, the latter !
2) Should we wrap maven ? We played with that idea in
BIGTOP-1195. The conclusion was : BEtter to build a easy to use framework with lower barrier to entry, then just wrap a hard to use framework in a pretty UI. So , BIGTOP-1222 was born - a new framework which was so easy to use, and direct at the same time - that no wrappers at all were needed...
Here are the benefits of the gradle smoke tests.
- Still have perfect JVM integration : We don't lose compilation against known sources.
- don't need to scan 3 different directories (test-framework,test-execution,test-artifacts) to determine the code path for their tests. this is a complete show-stopper for anyone who is not a maven guru.
- retain backward compatibliity w/ test-artifacts (i suggest we migrate them into the new framework but wont start that debate here).
- run way faster, and way easier, literally, I think 10x faster last time i checked. this means you can really rapidly test and run smoke-tests on a real cluster and modify them while developing.
- no roadblocks to people who arent' maven/gradle experts. no hidden dependencies.
- have some extra groovy tests? just drop em in a folder! they will run automatically.
- inherit the easy to use gradle interface gradlew compileGroovy test -Dsmoke.tests=pig
- will automatically run inside the bigtop auto-testing infrastructure which runs on virtualbox or docker in the click of a button
Now, if we swap out the elgant and direct gradle->compile classes->groovy test runtime w/ gradle->maven->jar->jar runner i am seeing 5 of those benefits gone (or severly comprimised). The original JIRA
BIGTOP-1222, we decided that test-artifacts was only useful for the purpose of freezing versoins of jars in binary test-artifacts. for all other tests, smoke-tests approach works perfectly. So If we want to keep test-artifacts I promise to keep up the work to make sure that smoke-tests can use the source code from test-artifacts but i really hope we dont take smoke-tests, which can run on any java enabled linux machine in 1 minute, into something that had a bunch of dependencies, which took 8 minutes to run, and was impossible /error prone to modify at runtime. I ran into that alot w/ maven - because I'd need to modify something in, say, a pig test, then i'd need to clean the pig jar, and re run, hence all the work we put into BIGTOP-1195 and BIGTOP-1222 to come to a cleaner decision. Any QE team can easily adopt the current smoke-tests framework and add their own tests - not at all the case w/ the maven style of jar based tests.