Yeah, the elasticsearch way. But that is really broken. Java 13 shouldn't be "unsupported", it is a released JVM: been out for months! Sorry, I think its a fucking crazy world if we let groovy just "get away" with this. Let's fix it!
On Fri, Jan 10, 2020 at 2:53 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > 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 <rcm...@gmail.com> 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 <dawid.we...@gmail.com> > 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: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
