Hi, Sorry, this is a no-go for going to gradle. We currently want to build and test Lucene with all newer Java versions, including EA releases. I have no idea why the Gradle people are not looking into the issue of forward-compatibility.
I had a long discussion already on the OpenJDK mailing lists about the classfile version issue. The problem is mainly ASM that's used for bytecode analysis where Gradle and Groovy depend on. If you pass ASM a classfile version that it does not unerstand it brings this error. I had a discussion with Remi Forax. My proposal would be: ClassReader should have 2 modes: - strict mode that enables all features (like you can add filtering on top of like method renames,.... and so pass the ClassReader (as visitor) to a ClassWriter. This strict mode ensures that a ClassReader then passed to ClassWriter produces the same class file. The requires that ASM fully understands the class file. - lenient mode: This marks the classreader/visitor as "risky". When passing this to ClassReader, it can open any class file, also those with newer class file versions. The classfile format is made in a way (attributes) that you can easily read over features you don't understand. In that case you can use a ClassReader like this to read method signatures, run forbiddenapi checks,... (what MOST code out there using ASM is doing!). The special flag on the visitor interface is then there to protect people. If you pass a "lenient" class reader to a ClassWriter, the ClassWriter complains. So you cannot open a ClassReader in lenient way and pass it to ClassWriter, because that would produce a classfile where maybe a significant part of stuff is missing/incorrect. In short: If there would be a non-picky ASM version / ASM mode like proposed before - that can just be used for "analysis" of class files, Gradle would be forward compatible. But Remi is too academic and also does not want this because he sees some "maintenance" trouble. But this is why I said strict mode and lenient mode. In lenient mode you cannot complain if your code behaves wrong when you open a class file that is newer than the version of ASM supports. In forbiddenapis I use hack to provide this leniency: When opening class files, I just patch the version number. Maybe gradle should do the same - IF AND ONLY IF IT DOES NOT USE IT FOR WRITING DERIVATIVE CLASS FILES: Maybe we could try to confive Gradle, Groovy and maybe Remi to take one of those routes. Otherwise we cannot use Gradle with CI builds. An alternative here is to go the Elasticsearch approach: Gradle and the Build runs with Java 11 and the Tests are running optionally with a later version - by pasisng a system property pointing to a TestRunner JDK. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Dawid Weiss <[email protected]> > Sent: Wednesday, January 8, 2020 6:06 PM > To: Lucene Dev <[email protected]> > Subject: Re: Gradle build to land on master > > > right, that file is the exact one i change. the problem is if i change it > > to 6.0.1, > then it wants me to buy something. > > You can't change to any other gradle version -- stick to the version > defined in the wrapper and java 11. It is a fragile environment - > switching gradle version will cause plugin incompatibilities, etc. > Sigh. > > We can't upgrade to gradle 6.x yet because palantir's plugin for > dependency management doesn't work for me then. > > Different JVM configurations may be rough, especially with newer JVMs. > > D. > > > > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[email protected]> wrote: > >> > >> ./gradlew should try to use gradle 5.6.4 see > >> ./gradle/wrapper/gradle-wrapper.properties > >> With java 11 this all builds fine for me (can export JAVA_HOME to change) > >> Which version of java are you using? the linked issue hints at java 13? > >> > >> On Wed, 8 Jan 2020 at 16:01, Robert Muir <[email protected]> wrote: > >> > > >> > Here is the issue: https://github.com/gradle/gradle/issues/8681 > >> > > >> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to buy > something? > >> > > >> > ]$ ./gradlew help > >> > Starting a Gradle Daemon (subsequent builds will be faster) > >> > > >> > FAILURE: Build failed with an exception. > >> > > >> > * Where: > >> > Build file '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' > >> > line: > 5 > >> > > >> > * What went wrong: > >> > An exception occurred applying plugin request [id: > >> > 'com.gradle.build-scan', > version: '3.0'] > >> > > Failed to apply plugin [id 'com.gradle.build-scan'] > >> > > This build scan plugin is not compatible with less than Gradle 6.0. > >> > Please use the Gradle Enterprise plugin instead. > >> > > >> > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir <[email protected]> wrote: > >> >> > >> >> I tried it out just to see, here was my experience: > >> >> > >> >> $ git checkout gradle-master > >> >> Switched to branch 'gradle-master' > >> >> Your branch is up to date with 'origin/gradle-master'. > >> >> $ ./gradlew help > >> >> Starting a Gradle Daemon (subsequent builds will be faster) > >> >> > >> >> FAILURE: Build failed with an exception. > >> >> > >> >> * Where: > >> >> Settings file '/Users/rob.muir/eclipse.workspace/lucene- > solr/settings.gradle' > >> >> > >> >> * What went wrong: > >> >> Could not compile settings file > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > >> >> > startup failed: > >> >> General error during semantic analysis: Unsupported class file major > version 57 > >> >> > >> >> java.lang.IllegalArgumentException: Unsupported class file major > version 57 > >> >> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:184) > >> >> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:166) > >> >> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:152) > >> >> at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:273) > >> >> at > org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompile > r.java:81) > >> >> at > org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeRes > olver.java:254) > >> >> at > org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(Class > NodeResolver.java:192) > >> >> > >> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[email protected]> > wrote: > >> >>> > >> >>> I think the gradle-master branch is already workable enough to land on > master. > >> >>> > >> >>> If you're not familiar with gradle then, once merged, run "gradlew > >> >>> help". > >> >>> > >> >>> Some notes. > >> >>> > >> >>> 1) I have been running tests on Windows and Linux, they're ok. The > >> >>> output is slightly different from ANT's but I think it's fine for > >> >>> working. > >> >>> > >> >>> 2) The speed of compilation and running tests selectively is much > >> >>> better than ant's, especially on multicore machines. > >> >>> > >> >>> 3) I use IntelliJ idea and the project imports into the IDE without > >> >>> any special handling. Code formatting and such may need to be adjusted > >> >>> though. > >> >>> > >> >>> 4) Some things are incomplete (precommit does a subset of checks). > >> >>> Some are missing (regeneration tasks). Some are different (handling of > >> >>> dependencies, build output folder locations). It will take some time > >> >>> and learning to live with a new build system. I tried to provide short > >> >>> guides into selective areas (they're available as help tasks or plain > >> >>> text files under help/). > >> >>> > >> >>> 5) If something does *not* work, let me know. > >> >>> > >> >>> 6) It'd be nice if we had a build job somewhere on a faster machine > >> >>> that would run at least "gradlew precommit check -x test" so that > >> >>> rudimentary checks are applied, without running all the tests. This > >> >>> would ensure consistency in dependencies, for example. > >> >>> > >> >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) will be > >> >>> kept open and occasionally merged back and forth. > >> >>> > >> >>> I have to shift more focus to my daily job but will help out and chip > >> >>> at the remaining bits, time permitting. > >> >>> > >> >>> 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] > >> > > --------------------------------------------------------------------- > 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]
