multijdkdirs

[Stack <st...@duboce.net>]

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.

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?

Thanks,
St.Ack

Re: multijdkdirs

[Allen Wittenauer <aw...@altiscale.com>]

> On Feb 11, 2016, at 10:44 AM, Stack <st...@duboce.net> wrote:
> 
> That sounds great Allen. So --multijdktests="compile", if we had jdk7 and
> jdk8 for our jdks, would compile using 7 and 8 but then the 'default' would
> be used to do the general suite (javadoc, unittests, etc.)


	Yes, exactly.

Re: multijdkdirs

[Stack <st...@duboce.net>]

That sounds great Allen. So --multijdktests="compile", if we had jdk7 and
jdk8 for our jdks, would compile using 7 and 8 but then the 'default' would
be used to do the general suite (javadoc, unittests, etc.)

Thanks sir,
St.Ack

On Thu, Feb 11, 2016 at 10:23 AM, Allen Wittenauer <aw...@altiscale.com> wrote:

>
>         Just to follow up on this, I’ve uploaded a patch for YETUS-297
> that will allow users to select which individual subsystems/tests should
> use MultiJDK mode if those tests are aware of it.  By default, Yetus
> enables it for compile, unit, and javadoc.  Using —multijdktests=“javadoc”
> would mean that multiple JDKs are only used during the javadoc portion and
> not for compile (read: javac, cc, scalac, etc) or for unit tests.  Doing
> —multijdktests=“” (or even —multijdktests=“shellcheck” or some other test
> that doesn’t know about Java) would disable all of them (although it’s
> probably easier to just not set the JDKs to begin with …) .

Re: multijdkdirs

[Allen Wittenauer <aw...@altiscale.com>]

	Just to follow up on this, I’ve uploaded a patch for YETUS-297 that will allow users to select which individual subsystems/tests should use MultiJDK mode if those tests are aware of it.  By default, Yetus enables it for compile, unit, and javadoc.  Using —multijdktests=“javadoc” would mean that multiple JDKs are only used during the javadoc portion and not for compile (read: javac, cc, scalac, etc) or for unit tests.  Doing —multijdktests=“” (or even —multijdktests=“shellcheck” or some other test that doesn’t know about Java) would disable all of them (although it’s probably easier to just not set the JDKs to begin with …) .  

Re: multijdkdirs

[Allen Wittenauer <aw...@altiscale.com>]

> On Feb 1, 2016, at 9:50 AM, Stack <st...@duboce.net> 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.