How to work with gradle projects?

[Tree]

The menu Project -> Open Other Workspace -> Gradle Project File exists, but does not appear to do anything. And I can't find anything in help, either. I have previously been able to open gradle projects using slickedit, but I'm not sure exactly how I did it.

Are there any instructions anywhere?

[patrick]

You don't get a dialog or anything like that you use that menu entry?

[Tree]

Nope. Nothing happens.

If I select a build.gradle from one of the sub-projects, it does go on to prompt for a gradle home directory, and then has a "Task Setup" dialog that is mostly empty. "Task that executes the project" shows "<NONE>" with no other options, and "Tasks exposed in Build menu" is empty. The resulting workspace is not usable. It has the code from that sub-project, but no build options (should there be? I have no idea, there are no instructions...)

I've tried various changes to the top-level build file to get it to be recognized (stabbing in the dark) and nothing has worked.

[patrick]

The subproject problem sounds like it could be a mis-parse of the task list.  What version of gradle is the project using?  Using the gradlew wrapper scripts to select a particular version, or just the system install of gradle?

And for your main project, the one where nothing happens, what do you get if you you go to a terminal, and run "gradle --no-daemon -b build.gradle tasks --all"?

[Tree]

We are using gradle 4.7, using a gradlew wrapper script in the project directory. I could not get this to be recognized by slickedit, however, so I installed gradle on the system and pointed slickedit at that. Vastly different version, though (2.13) which is probably why that didn't work.

Is there any way to get slickedit to use the gradlew or gradle/wrapper from the project itself?
Looks like I can point it at ~/.gradle/dists/gradle-4.7-bin/.../gradle-4.7/ and that works, for the sub-project.

Doesn't help all that much to have a sub project without the higher level project though.

The main project, the real build file, never got to the poing where it asks for a gradle home, though.

To answer your other question (this is on the main build file):

Code: [Select]

$ ./gradlew --no-daemon -b build.gradle tasks --all | wc -l
8584


[patrick]

Once you get it so a project can open, you should be able to tell it to use the gradle wrapper, but that does you no good at the moment.

It looks I've got a Scala gradle project I can't open with that menu entry, with the same symptoms you have with your main project.  It doesn't even look like it's poking gradle or the build file from a quick strace.  I'm taking a look at it now.

[Tree]

I tried something that might be helpful. I copied one of my sub-module vpjs to the top level and renamed it.

I was able to open this project.

Editing the gradle properties for this project now showed all the tasks from the top-level project, but did *NOT* show the "build" target. Maybe failing to find a build target is related to the failure to detect this as a gradle project?

Canceling that dialog left the existing Build target that I'd selected in the sub-module, and running that still worked (at the top level).

I couldn't open any files, though. They all seemed to have the wrong paths (probably stored relative to the build file). This should be a common problem, though, as files are added and removed from a project all the time. How can I refresh the project files? Project-> Refresh didn't seem to do anything.

[patrick]

For your main project, is there already a .vpw for that project?  So if the project dir is /path/somproj, is there a /path/someproj.vpw file already? 

It looks like it tries to not overwrite an existing vpw file, but doesn't open the existing one in that case, or give any sort of feedback to the user as to what's going on.  (edit: to be clear, that's a bug, it should be opening the existing project in that case at the very least).

[Tree]

That did it! I can now open my top-level gradle project.

Still not finding the "build" or "test" targets, though, which is odd. I can add it manually, but I'm not sure if this will affect basic functionality in slickedit. Does it do anything with "build", specifically?

[Tree]

Even with the main build file recognized, slickedit doesn't seem to find symbols for the third-party libraries linked in by gradle. Is there something I need to do to get it to do that?

[patrick]

Mainly just to wire the build command to gradle command to build.  (bound to Ctrl-M on some emulations).

It does not automatically look for files to add to the project, but you should be able to force it by running Build->Gradle Options once the project is open. 

It doesn't follow all of the library dependencies and add all of the downloaded jar files for tagging, it only sees the attached source.  That would be nice to have, and we could get the locations of the cached jars via Ivy, which we're already using in other contexts.

[Marcel]

For more on that topic see my enhancement requests wrt gradle:

https://community.slickedit.com/index.php/topic,16054.0.html

[Tree]

Project -> refresh should refresh the project files. It's what it does for other types of projects.

Build -> Gradle Options does not seem to discover new source files.

It's also really weird that you add the .java files as files, rather than adding wildcards matching the project source sets. Adding as wildcards would seem to be the best of both worlds. You'd still need to refresh the whole project structure somehow, though.

Including third party sources is, indeed, a huge part of the point of using a gradle project in an editor.