> On Feb 1, 2016, at 9:50 AM, Stack <[email protected]> wrote:
>
> Dear Yeti:
>
> We are currently running the full unit test suite for 1.7 and then 1.8 jdk
> when doing a patch precommit run. We'd like to run the unit test suite once
> only (our suite takes too long -- a different problem). I'm trying to
> figure how I might do this with a yetus config/plugin combo but I seem to
> end up cross-cutting yetus so I must be doing something wrong. What I want
> is to be able to specify that, say, we do javac,javadoc,junit with jdk1.7
> but we only do javac with jdk1.8.
>
> Looking at the args we are passing yetus -- I'm talking about the hbase
> project -- it looks like we are passing jdk 1.8 only on the --multijdkdirs
> parameter and that we must be picking up the jdk 1.7 from JAVA_HOME (if I
> am reading our config properly). We are not specifying --multijdktests so
> we are getting the javac,javadoc,junit precommit plugins run by default.
Some background:
When running in multijdk mode, test-patch always appends the JAVA_HOME
version (which is expected to be the lowest release, something we need to
document!), so that the maven repo is kept at a constant state between runs and
between non-multi-idk aware tests (e.g., checkstyle). This means when
test-patch isn’t running and something else is, anything we touch in the maven
repo should theoretically be the same as the JAVA_HOME version. [Remember that
lots of folks use test-patch outside of Jenkins!]
That said, I’d be *extremely* hesitant to yanking out the JAVA_HOME
version from the compile tests as a result.
> I was thinking of something like changing the parse of multijdktests so I
> could pass multiple test lists and then their order would match the jdk
> order in multijdkdirs, but that seems kinda hacky.
>
> What would you suggest?
JDK_TEST_LIST was (originally) designed to tell the system which tests
need multijdk support. So from an API perspective, that’s the thing to
manipulate. But there’s a bug here: the for loop used to cycle through the
tests still uses JDK_DIR_LIST when it should just use JAVA_HOME when
verify_multijdk_test says no. So I think there are two things here:
* need a better API around JDK_TEST_LIST
* need to make the for loops for the existing multijdk aware bits
smarter
If we do that, then this becomes very easy so long as everyone agrees
that the JAVA_HOME version should always be the one that canonical one that
runs.
