Use Gradle Wrapper instead of fixed version from SDKMAN

[vorburger]

https://gitpod.io/#github.com/apache/fineract/pull/598 fails saying:

Could not run phased build action using Gradle installation '/home/gitpod/.sdkman/candidates/gradle/current'. Build file '/workspace/fineract/fineract-provider/build.gradle' line: 77 A problem occurred evaluating root project 'fineract-provider'. Could not get unknown property 'classesDir' for main classes of type org.gradle.api.internal.tasks.DefaultSourceSetOutput.

{
    "resource": "file:///workspace/fineract/fineract-provider/build.gradle",
    "owner": "file:///workspace/fineract/fineract-provider/build.gradle",
    "code": "0",
    "severity": 1,
    "message": "Could not run phased build action using Gradle installation '/home/gitpod/.sdkman/candidates/gradle/current'.\nBuild file '/workspace/fineract/fineract-provider/build.gradle' line: 77\nA problem occurred evaluating root project 'fineract-provider'.\nCould not get unknown property 'classesDir' for main classes of type org.gradle.api.internal.tasks.DefaultSourceSetOutput.",
    "source": "Java",
    "startLineNumber": 76,
    "startColumn": 0,
    "endLineNumber": 76,
    "endColumn": 0
}

This is unexpected, and likely due to it using a fixed Gradle version (I noticed e.g #69), instead of the Gradle wrapper (./gradlew), where this works.

This is fairly "critical", in the sense that there's no code completion & navigation etc. due to this.

The particular project is going to upgrade from the admitedy ancient pre-historic Gradle version it uses (see https://issues.apache.org/jira/browse/FINERACT-700), but even so, there will invariably always be "version skew" between the Gradle version in the GitPod workspace container and the one a project requires (expressed via Gradle Wrapper, which is the canonical "this is the one that works for this project"), and, in my experience, major Gradle versions are not really backwards compatible at all.

[vorburger]

BTW: I'm almost certain about a week or two ago I somehow had this working... in this spectrum.chat I said:

it seems to just automagically figure it out and just work - AFTER one does a ./gradlew build - that seems totally fair... ;-)

but right now, that doesn't seem to work anymore, for me.

[vorburger]

This is unexpected, and likely due to it using a fixed Gradle version (I noticed e.g #69), instead of the Gradle wrapper (./gradlew), where this works.

Yup, it's reproducible if I use gradle build instead of ./gradlew build in the GitPod terminal.

BTW: I'm almost certain about a week or two ago I somehow had this working.

Oh, I forgot that was on a branch where I was experimenting with an upgraded Gradle version, that would explain it.

So the problem will go away when we finish and merge https://issues.apache.org/jira/browse/FINERACT-700 in that project, but...

... but it would still seem much safer if GitPod thing which creates the classpath for IDE functionality would use any project's Gradle wrapper, instead of using the Gradle version present in the Docker image.

[jankeromnes]

Interesting feedback, thanks a lot! Is it common for projects to have a local Gradle wrapper? And is it standard/expected to always call it ./gradlew?

@meysholdt or @AlexTugarev, would you have any insight in Gitpod's Java extension / Language Server, and how it could be nudged to prefer using a local ./gradlew wrapper instead of the system's gradle command?

[vorburger]

Interesting feedback, thanks a lot! Is it common for projects to have a local Gradle wrapper?

Yeah, I'd say it's "pretty common", given there are 620k gradlew on this GitHub query... :smiley:

[meysholdt]

My understanding is that if you want to run gradle-wrapper you run ./gradlew and if you want to run the system's gradle, you run gradle.

Am I understanding you right that you would like grade to call ./gradlew if gradlew does exist?

[vorburger]

@meysholdt nope, misunderstanding - this issue is not at all about using Gradle in the Terminal, but about the Gradle version used in the LSP integration. The error I had copy/pasted above is an example of what you see in the Problems view in GitPod, not the Terminal, if you open a (Java) project which relies on an older, or I guess in theory also newer, version of Gradle than the one you package, and uses something incompatible in its build.gradle with the version you package (but which works via the version ./gradlew pulls).

What I'm trying to suggest is that, in an ideal world, the LSP integration should use the Gradle version a project wants, as expressed by its Gradle wrapper, instead of being hard-coded, as it currently seems to be, to the one you ship.

Similar comment also just posted in reply on https://github.com/apache/fineract/pull/598.

Hope this helps and clarifies? Do shout if it's not and I can help to make this clearer in some way.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.