You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by "Martin Bukatovic (JIRA)" <ji...@apache.org> on 2014/03/18 18:43:56 UTC

[jira] [Commented] (BIGTOP-1222) Completely gradleize the bigtop smokes

    [ https://issues.apache.org/jira/browse/BIGTOP-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939522#comment-13939522 ] 

Martin Bukatovic commented on BIGTOP-1222:
------------------------------------------

Since I find this issue important, I'm adding my point of view here:

I agree with [~jayunit100] that we need a better way to execute integration tests while understand why bigtop project decided to pick maven for this task.

Why I don't like test execution via maven?

 * It's harder to integrate with other tests.
   I would like to use bigtop tests when checking integration of hadoop in specific environment and needs to run particular test cases from bigtop while doing something else at the same time. With maven this is hard, because one have to configure maven properly to run just particular test case and then fight maven to produce reasonable output... It can be done somehow, but it's hardly optimal for this usecase.
 *  Maven creates a higher entry barrier: you can run full test suite as it is, but when you decide to dig deeper and eg. modify  and run just single testcase, you need to recompile it and then setup maven to run just this case.

That said maven is really useful for preparation of the test environment: we need it to manage dependencies (resolve and download jars into local maven repository), create classpath for test to run and so on. Even when I would decide to run some bigtop tests via shell script, I would need maven to do this setup. But when it comes to the test execution, I can imagine a easier ways to do this.

So if we decide to go with gradle, I would like to propose to have a some simple plain mode of execution where:

 * maven/gradle sets up the enviroment (jars, classpath) for the case (so we will be sure that the we are not comparing carrots with potatoes)
 * you will run just single case easily (ideally just by specifying a groovy script name)
 * without additional logging and maven plumbing during execution
 * groovy scripts runs without the compilation directly

This approach would be great for just looking around, experimenting and integrating with other environments. I have no knowledge of gradle, but I'm willing to learn about it help this to be implemented if bigtop projects decides to go with gradle.

> Completely gradleize the bigtop smokes
> --------------------------------------
>
>                 Key: BIGTOP-1222
>                 URL: https://issues.apache.org/jira/browse/BIGTOP-1222
>             Project: Bigtop
>          Issue Type: Improvement
>            Reporter: jay vyas
>
> 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.  



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