[
https://issues.apache.org/jira/browse/BIGTOP-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939667#comment-13939667
]
Konstantin Boudnik commented on BIGTOP-1222:
--------------------------------------------
Hi Martin. Thanks for listing the requirements! A view comments:
bq. 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
Re-compilation isn't specific to Maven. The reason it is done is because
* tests and their execution are separated
* tests are written as a Java or Groovy programs, not scripts
bq. 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)
That's exactly what maven does (and gradle shall seamlessly step into this
later, hopefully without a disruptive change in the pom structure).
bq. you will run just single case easily (ideally just by specifying a groovy
script name)
As I've pointed out a couple time already - there's already a way to do this by
using {{-Dorg.apache.maven-failsafe-plugin.testInclude}} sysprop. I guess the
name can be shorter/cleaner.
bq. without additional logging and maven plumbing during execution
I am not really sure what you're referring to. One of the benefits of plumbing
is to have a nice plug into CI infrastructure. If you are talking about having
a different entry-point into the test system to make ad-hoc experiments easier
- I am all for it. And I think gradle is the right way to go.
bq. groovy scripts runs without the compilation directly
This is clearly possible _only if_ tests are written as scripts, not as
classes. As an example look at what has been done in BIGTOP-952 with the
provisioning script.
I got a little bit oversubscribed with a couple of timeboxed things, but I
should be spending more time on this Gradle stuff starting next week. In the
meanwhile it would be a great starting point if someone wants to drop in some
proof-of-concept patches. Gradle is pretty easy - I have learned its
sophistications in a less than a day working on BIGTOP-1201.
> Completely gradleize 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
>
> 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)
