Gradle and Che

[bobpaige]

We use Gradle (build system similar yet different than maven) to manage our projects. The main one I'm looking at has 16 sub-modules and 13 source directories. I asked about this at JavaOne last week and was told "che dir" is what I want, and to pose the question here.

I've read the documentation on https://eclipse-che.readme.io/docs/getting-started-chedir but it doesn't appear to address the scenario I'm describing.

I also looked at the "Get Started With Java/Maven and Che" page.

I tried just cloning one of our projects locally (had to use the commandline because our internal github server requires authentication), building it, and adding it as a project within Che, but I see Che doesn't understand this is a Java project in the same way it does with Maven (source directories, build directories, external dependencies).

Are the various dependencies and source directories enumerated in some configuration file that Maven creates, but Gradle doesn't (yet)?

[TylerJewell]

The che dir reference is certainly not helpful here. Yes, we do have a gradle plugin, but it does not yet have the dependency discovery, download, and registration added the same way that our maven plugin handles it.

So - separating concerns for a moment. You can specify Java or Maven project to get the intellisense capability for Java. And you need the maven component to get automatic dependency download and registration. So with gradle you can get intellisense, but it's not full download and install of dependencies.

However, you can use gradle on the command line, get the libraries downloaded, and then register the project type as Java to get intellisense with the downloaded libraries.

[bobpaige]

Thanks for the clarification.

I've built it from the commandline which, by default, references the external dependencies in the local gradle cache (the .jars don't exist within my project). I've also set the project type to "Java".

I was able to manually add a couple source directories to the project so I see Che supports it, but how can I automate discovery of all the source directories and external dependencies?

I see that once we have this figured out I can export the workspace as a file and it will include all project configuration, which is great. This will make it easier recreate the workspace for others.

[bobpaige]

I think I found the answer to my own question: the file /projects/PROJ/.codenvy/classpath contains the list of all src directories and external dependencies. If I can generate the contents of this file from my project, I should be good.

This looks like the same format as the Ecilpse .classpath file, which Gradle can already generate, so maybe I can leverage our existing process and copy the .classpath file to the .codenvy/classpath file.

[bobpaige]

Same file format, but editing the .codenvy/classpath file directly is ineffective; Che doesn't see the changes and if I edit the classpath (Project -> Configure Classpath) within Che, it just overwrites my changes to the classpath file. Bummer

[TylerJewell]

I think you are getting into some of the internals. While you are modifying the .codenvy/classpath folder, I believe that you also need to get the workspace configuration updated (the workspace.json) for it to automatically be detected as Java project type with the full list of locations where the classpath lives. I have not attempted to try this approach recently, but there is something along those lines which would work.

[jpe42]

I think I am having a similar problem, sorry if I am off base. For Gradle-Java projects that only use core Java, everything works as expected. For other project dependencies, Gradle downloads to $GRADLE_USER_HOME/caches/modules-2/files-2.1, where GRADLE_USER_HOME defaults to ~/.gradle. Is there a best practice for configuring Che to look into that directory for dependencies, or to configure Gradle to download somewhere else?

...I just tested this out on CodeEnvy using version 5.0.0-M7.

[bobpaige]

Che and Codenvy don't support eclipse or gradle natively but the do support
maven. My conclusion was to write it pom files based on the gradle
dependencies. Then Che Will see them.

I don't have my poc code in front of me, but if you look online for
creating pom files from Gradle you should find what you need.

On Sat, Nov 19, 2016, 9:42 PM James Edwards notifications@github.com
wrote:

I think I am having the same problem, sorry if I am off base. For
Gradle-Java projects that only use core Java, everything works as expected.
For other project dependencies, Gradle downloads to
$GRADLE_USER_HOME/caches/modules-2/files-2.1, where GRADLE_USER_HOME
defaults to ~/.gradle. Is there a best practice for configuring Che to
look into that directory for dependencies, or to configure Gradle to
download somewhere else?

...I just tested this out on CodeEnvy using version 5.0.0-M7.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#2669 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/APsZdzbgGSF0P_D-8QJEq7oqTV0g5yV1ks5q_7OvgaJpZM4KLNE5
.

[jpe42]

I had my hopes up from #802, that everything was working nearly out of the box. Thank you for the quick solution. I'm going to keep my fingers crossed that they will eventually bring stronger Gradle support and keep checking back in.

[TylerJewell]

Right now, we support gradle on the command line, but we do not have a native project type like we do for maven, which can inspect the dependencies list and automatically download them.

The command line configuration of Gradle means that you either use the javac or maven project type, but then configure classpath and other variables in the workspace to work with Gradle. Yes, it is a bit more manual, but it is a suitable solution for gradle temporarily.

We are waiting for the community to get more engaged to help us build and maintain a proper gradle plugin.

https://eclipse-che.readme.io/docs/che-and-gradle

[vorburger]

From what I understand, the che-gradle-plugin, notably in its class GradleProjectManager, from @vzhukovskii @codenvy, appears to have (at least some of) the missing pieces for full native Gradle project type support in Che .. perhaps that could be a basis, for @vzhukovskii or anyone else from the community reading this and motivated, to contribute this feature into master.

Also eclipse-che/che-docs#158 raised to clarify the doc about this feature, as its currently initially slightly misleading (for a noob, like me, who just tried Che for the very first time, with a Gradle project).

Re. @bobpaige's tip to "write it pom files based on the gradle dependencies. Then Che Will see them." and to "look online for creating pom files from Gradle you should find what you need.", this PR che-samples/console-java-gradle#1 illustrates how to do that.

[vzhukovs]

@vorburger as for the Gradle plugin for Che, which is located in my repository, I can say, that this is not official development and made just on purpose in a free time. At the moment, sources are not fresh and need to be reviewed due to architectural changes in Che.

[edeandrea]

Has this moved at all? All of us Gradle users are being left behind. With Gradle, not only are we modeling our source/dependencies, but we're also modeling our IDE environment (classpaths, etc). Is Eclipse Che structurally different than Eclipse (i.e. does using Gradle's Eclipse plugin not work correctly with Eclipse Che)? Gradle has tight integration with Eclipse/IntelliJ - simply by running a task I can generate all of the necessary IDE plugins. The Buildship Eclipse plugin then knows how to dynamically manage the project's classpath based on changes to the build file, similar to the way the Maven plugin does.

[TylerJewell]

Unfortunately, there has been no progress. The plugin model for Che is very different from other plugin models since the system is distributed. It would be great if the community could keep requesting the cradle community to make a contribution here. We have invited them to provide a PR to support Che the way they support other products. I suppose they are needing to verify the demand before stepping in.

[edeandrea]

Sounds like the chicken & the egg problem. No demand because there is no support. No support because there isn't demand....

[TylerJewell]

We build and maintain the maven plugin with support for multi modules, custom commands, and dependency analysis with downloads. It is a fair amount of work.

We would not be as effective at doing the same for gradle as our core team lacks some experience with it.

It will eventually show up as we were bought by redhat and they have a large internal tool community. Someone somewhere will eventually make a contribution.

[edeandrea]

I've found even RedHat is lacking in the Gradle community. Just look at their SourceToBuild process within OpenShift - it only supports Maven :(

I appreciate the feedback.

[TylerJewell]

From time to time I have wondered if porting Che build system from maven to gradle would make it faster. But we have 1000s of hours of maintenance into our maven build system and it works really great. Incredibly stable. So it is a hard path for me and others to convince our core contributors to experiment on this vs other projects. Build systems are incredibly sticky.

[edeandrea]

I can tell you from experience it would be a whole lot faster. I've been a Gradle user & plugin developer since before its 1.0 release a few years ago. There are things you can do in Gradle that just aren't possible with Maven due to the fact that Maven is constrained by an XML schema. Your build is structured text vs code. For large builds it will outperform Maven hands-down.

I have some contacts at Gradle and I'll poke them a bit and see what they say.

[TylerJewell]

Tell them that Che is now the most active project at the eclipse foundation with over 100 contributors. We had more commits to our repo last year than the desktop ide. So we are a massive maven implementation that would need to change. We have many modules that can and should be built in parallel.

[karstengresch]

Though I find Tyler's reasoning fully understandable, there are on the other hand many folks out in the wild that have massive Gradle installations.

Wouldn't it be wise for an IDE to be as much platform/technology/framework agnostic as possible for attracting as many devs as possible?

Maybe one could leverage the one or other concept from https://github.com/JetBrains/gradle-intellij-plugin?

Anyway - is there any progress on this or is this issue put on hold?

[kesara10]

Interested in knowing "Is there any progress on this or is this issue put on hold?" too

[gorkem]

This will be resolved as part of #6157 since jdt.ls supports gradle, which is actively worked on.

[cosmocracy]

This would be great. We passed on Che—we do a ton of Gradle—because we don’t want to go back to Maven’s...quirks, limits, and declarative sit-ups. Would be happy to lend effort beta testing when this is out!

[Geethree]

Ditto. Passed over Che as it didn't have native gradle support... Would love to get my developers away from intellij and into the cloud...

[dneary]

Anyone tried this since the integration of JDT.ls into Che 6?

[edeandrea]

I tried with Che 6.18.something yesterday and it fell on it's face.

[nickboldt]

There's a new Gradle 5.2.1 / JDK 11 stack available OOTB in Che 7 RC1, which appears to sort of work w/ the sample gradle project.

[slemeur]

Gradle support is provided OOTB with Che 7.