Gradle build to land on master

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Gradle build to land on master

Dawid Weiss-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
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(AsmDecompiler.java:81)
        at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
        at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)

On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir

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 <[hidden email]> 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(AsmDecompiler.java:81)
        at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
        at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)

On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Thomas Matthijs-2
./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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
>>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>>
>> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
openjdk version "13.0.1" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 13.0.1+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 13.0.1+9, mixed mode, sharing)

On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
>>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>>
>> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
In reply to this post by Thomas Matthijs-2
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.

On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
>>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>>
>> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Thomas Matthijs-2
Can reproduce your problem with java 13, so guess only 11 is currently supported

The buildscan plugin seems to be a problem

https://github.com/apache/lucene-solr/blob/gradle-master/gradle/ci/buildscan.gradle
https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com

==> "Be careful not to commit agreement to the terms of service into a
project that may be built by others."

Looks like its only for CI builds (?) build should probably be
disabled by default

Builds seems to work with java 13 & gradle 6 with it removed:

diff --git a/build.gradle b/build.gradle
index 8e90409dde7..428d7b3e93c 100644
--- a/build.gradle
+++ b/build.gradle
@@ -1,10 +1,9 @@

 plugins {
   id "base"
   id "com.palantir.consistent-versions" version "1.13.1"
-  id "com.gradle.build-scan" version "3.0"
   id 'de.thetaphi.forbiddenapis' version '2.7' apply false
 }

 // Project version and main properties. Applies to all projects.
 allprojects {
@@ -17,13 +16,10 @@ allprojects {
 // if the build file is incorrectly written and evaluates something
 // eagerly).

 apply from: file('gradle/generate-defaults.gradle')

-// CI systems.
-apply from: file('gradle/ci/buildscan.gradle')
-
 // Set up defaults and configure aspects for certain modules or functionality
 // (java, tests)
 apply from: file('gradle/defaults.gradle')
 apply from: file('gradle/defaults-java.gradle')
 apply from: file('gradle/testing/defaults-tests.gradle')
diff --git a/gradle/validation/check-environment.gradle
b/gradle/validation/check-environment.gradle
index 3acfbb306d2..1d2d6e5509f 100644
--- a/gradle/validation/check-environment.gradle
+++ b/gradle/validation/check-environment.gradle
@@ -3,11 +3,11 @@

 import org.gradle.util.GradleVersion

 configure(rootProject) {
   ext {
-    expectedGradleVersion = '5.6.4'
+    expectedGradleVersion = '6.0.1'
     expectedJavaVersion = JavaVersion.VERSION_11
   }

   wrapper {
     distributionType = Wrapper.DistributionType.ALL
diff --git a/gradle/wrapper/gradle-wrapper.properties
b/gradle/wrapper/gradle-wrapper.properties
index 0ebb3108e20..1ba7206f882 100644
--- a/gradle/wrapper/gradle-wrapper.properties
+++ b/gradle/wrapper/gradle-wrapper.properties
@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-6.0.1-all.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists

On Wed, 8 Jan 2020 at 16:38, Robert Muir <[hidden email]> wrote:

>
> 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.
>
> On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
>> >>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>> >>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>> >>
>> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
In reply to this post by Robert Muir
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
>> >>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
>> >>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
>> >>
>> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
>> >>> For additional commands, e-mail: [hidden email]
>> >>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
In reply to this post by Thomas Matthijs-2
Can you file a pull request to remove it? I added it initially hoping
it'd help with test browsing but it's not going to work anyway
(because Solr emits half a gig of logs).

Dawid

On Wed, Jan 8, 2020 at 4:51 PM Thomas Matthijs <[hidden email]> wrote:

>
> Can reproduce your problem with java 13, so guess only 11 is currently supported
>
> The buildscan plugin seems to be a problem
>
> https://github.com/apache/lucene-solr/blob/gradle-master/gradle/ci/buildscan.gradle
> https://docs.gradle.com/enterprise/gradle-plugin/#connecting_to_scans_gradle_com
>
> ==> "Be careful not to commit agreement to the terms of service into a
> project that may be built by others."
>
> Looks like its only for CI builds (?) build should probably be
> disabled by default
>
> Builds seems to work with java 13 & gradle 6 with it removed:
>
> diff --git a/build.gradle b/build.gradle
> index 8e90409dde7..428d7b3e93c 100644
> --- a/build.gradle
> +++ b/build.gradle
> @@ -1,10 +1,9 @@
>
>  plugins {
>    id "base"
>    id "com.palantir.consistent-versions" version "1.13.1"
> -  id "com.gradle.build-scan" version "3.0"
>    id 'de.thetaphi.forbiddenapis' version '2.7' apply false
>  }
>
>  // Project version and main properties. Applies to all projects.
>  allprojects {
> @@ -17,13 +16,10 @@ allprojects {
>  // if the build file is incorrectly written and evaluates something
>  // eagerly).
>
>  apply from: file('gradle/generate-defaults.gradle')
>
> -// CI systems.
> -apply from: file('gradle/ci/buildscan.gradle')
> -
>  // Set up defaults and configure aspects for certain modules or functionality
>  // (java, tests)
>  apply from: file('gradle/defaults.gradle')
>  apply from: file('gradle/defaults-java.gradle')
>  apply from: file('gradle/testing/defaults-tests.gradle')
> diff --git a/gradle/validation/check-environment.gradle
> b/gradle/validation/check-environment.gradle
> index 3acfbb306d2..1d2d6e5509f 100644
> --- a/gradle/validation/check-environment.gradle
> +++ b/gradle/validation/check-environment.gradle
> @@ -3,11 +3,11 @@
>
>  import org.gradle.util.GradleVersion
>
>  configure(rootProject) {
>    ext {
> -    expectedGradleVersion = '5.6.4'
> +    expectedGradleVersion = '6.0.1'
>      expectedJavaVersion = JavaVersion.VERSION_11
>    }
>
>    wrapper {
>      distributionType = Wrapper.DistributionType.ALL
> diff --git a/gradle/wrapper/gradle-wrapper.properties
> b/gradle/wrapper/gradle-wrapper.properties
> index 0ebb3108e20..1ba7206f882 100644
> --- a/gradle/wrapper/gradle-wrapper.properties
> +++ b/gradle/wrapper/gradle-wrapper.properties
> @@ -1,5 +1,5 @@
>  distributionBase=GRADLE_USER_HOME
>  distributionPath=wrapper/dists
> -distributionUrl=https\://services.gradle.org/distributions/gradle-5.6.4-all.zip
> +distributionUrl=https\://services.gradle.org/distributions/gradle-6.0.1-all.zip
>  zipStoreBase=GRADLE_USER_HOME
>  zipStorePath=wrapper/dists
>
> On Wed, 8 Jan 2020 at 16:38, Robert Muir <[hidden email]> wrote:
> >
> > 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.
> >
> > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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(AsmDecompiler.java:81)
> >> >>         at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
> >> >>         at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
> >> >>
> >> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[hidden email]> 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: [hidden email]
> >> >>> For additional commands, e-mail: [hidden email]
> >> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
In reply to this post by Thomas Matthijs-2
> Can reproduce your problem with java 13, so guess only 11 is currently supported

For completeness: the build actually enforces gradle and Java version
and fails if there is a mismatch. The failure with Java 13 happens way
before this check has a chance to even run.

https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/check-environment.gradle

D.

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
So are we going to be able to do things like EA testing?

On Wed, Jan 8, 2020 at 12:18 PM Dawid Weiss <[hidden email]> wrote:
> Can reproduce your problem with java 13, so guess only 11 is currently supported

For completeness: the build actually enforces gradle and Java version
and fails if there is a mismatch. The failure with Java 13 happens way
before this check has a chance to even run.

https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/check-environment.gradle

D.

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

Reply | Threaded
Open this post in threaded view
|

RE: Gradle build to land on master

Uwe Schindler
In reply to this post by Dawid Weiss-2
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: [hidden email]

> -----Original Message-----
> From: Dawid Weiss <[hidden email]>
> Sent: Wednesday, January 8, 2020 6:06 PM
> To: Lucene Dev <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> >> >>> For additional commands, e-mail: [hidden email]
> >> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
> 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'm sure there are ways to run tests against an arbitrary Java version:
https://docs.gradle.org/6.0-rc-1/userguide/building_java_projects.html#sec:java_cross_compilation

It's just not something I'm concerned with at the moment. Can't do
everything at once.

> 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.

Exactly. I'm sure there are ways to do it.

D.

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
In reply to this post by Uwe Schindler
It is crazy classfiles are involved here at all. It is even crazier to be reading classfiles of the JDK itself. I just asked to print the help... crazy groovy

On Wed, Jan 8, 2020 at 12:27 PM Uwe Schindler <[hidden email]> wrote:
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: [hidden email]

> -----Original Message-----
> From: Dawid Weiss <[hidden email]>
> Sent: Wednesday, January 8, 2020 6:06 PM
> To: Lucene Dev <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> >> >>> For additional commands, e-mail: [hidden email]
> >> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
In reply to this post by Robert Muir
> So are we going to be able to do things like EA testing?

We should be able to, eventually. For now I explicitly limited the
environment to a particular Java/ Gradle version so that
we're all on the same page... Gradle is a much more complicated (and
fragile) ecosystem than ant. Weird things (like the one you
experienced, argh!) can happen out of nowhere.

Perhaps I should also clarify: the ant build will still work (on
master) until we can iron out all the problems. I just don't want to
keep the branch separate anymore. One of the reasons for this is
simple: I've had more feedback in the last 5 minutes than I had in the
last three weeks. :) I am also afraid the whole effort will die if
there is only one person effectively using it -- this is what happened
with Mark's branch. I tried to bring it to a functional level and I
think it's there -- I've been working with it for over a month now.

Dawid

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Robert Muir
Dawid, I think the plan is good, and thanks for working on it.

Maybe the README should be altered a little bit to encourage people to mess around with the gradle build. Currently all the instructions in the root README are ant-based. I am thinking just a simple one-liner that explains it: gradle is WIP, patches welcome, whatever you want it to say.




On Wed, Jan 8, 2020 at 12:44 PM Dawid Weiss <[hidden email]> wrote:
> So are we going to be able to do things like EA testing?

We should be able to, eventually. For now I explicitly limited the
environment to a particular Java/ Gradle version so that
we're all on the same page... Gradle is a much more complicated (and
fragile) ecosystem than ant. Weird things (like the one you
experienced, argh!) can happen out of nowhere.

Perhaps I should also clarify: the ant build will still work (on
master) until we can iron out all the problems. I just don't want to
keep the branch separate anymore. One of the reasons for this is
simple: I've had more feedback in the last 5 minutes than I had in the
last three weeks. :) I am also afraid the whole effort will die if
there is only one person effectively using it -- this is what happened
with Mark's branch. I tried to bring it to a functional level and I
think it's there -- I've been working with it for over a month now.

Dawid

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
> Maybe the README should be altered a little bit to encourage people to mess around with the gradle build. Currently all the instructions in the root README are ant-based.

Will do it, thanks for the suggestion.

D

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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Jan Høydahl / Cominvent
In reply to this post by Dawid Weiss-2
+1 The sooner the better

> This would ensure consistency in dependencies, for example
Are you thinking to have a gradle task that fails if there is mismatch between ant and gradle dependencies versions?

Jan

> 8. jan. 2020 kl. 15:29 skrev Dawid Weiss <[hidden email]>:
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: Gradle build to land on master

Dawid Weiss-2
> Are you thinking to have a gradle task that fails if there is mismatch between ant and gradle dependencies versions?

When you run './gradlew licenses' it currently applies all the checks
against the same "licenses" folders as ant. So when you change something in ant
and not do a corresponding change to gradle dependencies, "gradlew
precommit" (or "licenses")
will fail the build.

Technically there are a few ignored entries inside the gradle validation
script (to skip things like "start.jar"); everything else is resolved
directly from
declared dependencies.

https://github.com/apache/lucene-solr/blob/gradle-master/gradle/validation/jar-checks.gradle#L340-L368

The gradle validation script is more strict than the ant build -- it
fails if there are leftover files that don't belong
anywhere, for example.

Dawid

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