[ 
https://issues.apache.org/jira/browse/BIGTOP-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

jay vyas updated BIGTOP-1222:
-----------------------------

    Description: 
(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.

  was:
Currently, there is a JIRA underway to make running the maven based smoke tests 
easier:  BIGTOP-1195.  

Eventually, however, maybe we could run these smokes from gradle.    I think 
that will obviate BIGTOP-1195 (Although i still assert a bash driver is a big 
win/gain for bigtop's goals : which are to unify the hadoop packaging and 
deployment paradigm).


- run the smokes using a simple gradle goal

- smokes should be easily runnable as scripts, with no need for jar file 
intermediates.

- The bash driver for BIGTOP-1195 (if accepted, still under debate) should be 
upgraded to use the new gradle smokes

- Delete old maven smokes. 

This might be a little ambitious, if so others chime in.  I'm not a 
gradle/groovy expert but getting more well versed.  


> Simplify and gradleize a subset of the bigtop smokes
> ----------------------------------------------------
>
>                 Key: BIGTOP-1222
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1222
>             Project: Bigtop
>          Issue Type: Improvement
>          Components: Build
>    Affects Versions: 0.7.0
>            Reporter: jay vyas
>             Fix For: backlog
>
>         Attachments: BIGTOP-1222.patch, BIGTOP-1222.patch
>
>
> (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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to