I implemented testing against arbitrary JVMs yesterday - it is nicely
self-contained:
https://github.com/apache/lucene-solr/commit/4599c51f0d324464ddcaadbbaad76d9cdc0cc3fe

I'm also thinking that having a separate (and stable) JVM used for
build itself may guard us
against odd jvm-related failures when you wish to run tests against
bleeding edge JVMs.

We could also specify JVM used for compilation this way but I didn't
think it's that crucial
at the moment.

D.

On Fri, Jan 10, 2020 at 12:26 AM Robert Muir <[email protected]> wrote:
>
> Maybe there is an alternative solution to this. I got the hint from Uwe that 
> only recent groovy uses ASM in this way. Actually older versions of gradle 
> don't do it and use simple reflection. Because of this, the ant build 
> (despite calling out to groovy) still works with EA builds, because it uses 
> the older version!
>
> So maybe we should open an issue at the groovy bugtracker: if the ASM can't 
> read the classfiles because they are too new, fall back to reflection?
>
> On Thu, Jan 9, 2020 at 11:08 AM Dawid Weiss <[email protected]> wrote:
>>
>> > Thanks Dawid! I tried it out locally, working fine on the mac for me now 
>> > with 13!
>>
>> Yep, works for me too. It still doesn't work with Java 14 so the
>> general issue will require cross-compilation
>> strategy and remains open, but it's a start.
>>
>> Something is off with palantir's plugin too. Maybe we'll just switch
>> to explicit version numbers instead
>> at some point if it turns out too painful to use this plugin, we'll see.
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to