(Rewritten the description for clarity)
We need an easier way to run bigtop smoke tests, and gradle provides this:
1) Easy to script/modify
2) Human readable
3) equally oriented towards both groovy and plain old java
The advantage of this method to running smokes :
1) No need to compile a jar : this is a costly step and not much value added, also creates indirection which can make debugging a broken test very hard.
2) Simple: A smoke test doesnt need to make low level API calls or be compiled against the right APIs - rather, it should test the end user interface ("hive -q ....", "pig -x ....", "hadoop jar ....", and so on).
3) Customizable: The smoke tests shouldnt require users to have to write XML and debug environmental variables / grep around for System properties etc. Rather, a high level controller should do all that checking for you.
The initial idea was to write a python/bash implementation wrapper of scripts, but that was replaced by the idea of using gradle. The advantage of gradle is that we don't need to manually set the classpath and run groovy commands: Gradle wraps groovy scripts in their native java context quite nicely - but it doesnt add any other unnecessary overhead (xml, jar files, no need for complex xml tag wrappers for simple tasks - just plain groovy code).
So, here the goal is just to create a nice, clean, extensible non-jar, non-API dependent gradle runner for the smoke tests which exersizes the hadoop cluster the same way a typical end-user would.
|Update build.gradle in smoketests to read from paramterized file input