Project -> Open Other -> Gradle fails

[jporkkahtc]

It prompts for a build.gradle file,
then it wants gradle home Or "

• Use gradle wrapper".

Using the gradle wrapper doesn't work.
The "..." button is enabled, and shouldn't be.
There is red text "* 'some path' is not a valid Gradle install"

OK, so I hit CANCEL, and I got the following stack.
Even though I hit CANCEL, and I got a slick-stack, Slick created the *.VPW and *.VPJ files.
But, it didn't open the workspace it just created.
I can open that workspace now though.
The workspace has no projects

Code: [Select]

Stack trace written to file: C:\Users\jporkka\AppData\Local\Temp\vsstack.
 Invalid object handle
tagwin.ex 10249 tagwin:_UpdateOneTagWindow(121,
   2:   ._typename()=PREVIEW-FORM-INFO
   2:   .m-form-wid=121
   2:   .m-tagwin-last-seekpos=-1
   2:   .m-tagwin-saved-info=<empty>
   2:   .m-tagwin-use-editor=0
   2:   .m-tagwin-lastItem=(null)
   2:   .m-LastModified=-1
   2:   .m-forceUpdate=0
   2:   .m-tagwin-last-jumppos=-1
   3:   0
   4:   0
   5:   1
   6:   <empty>
   7:   <empty>
   p_window_id: 194
   p_object: OI_TREE_VIEW
   p_name: _proj_tooltab_tree
tagwin.ex 11985 _UpdateAllTagWindows(1,<empty>,<empty>)   p_window_id: 194   p_object: OI_TREE_VIEW   p_name: _proj_tooltab_tree
tagwin.ex 17277 _TagFileRefresh_symbols(,)   p_window_id: 25 (invalid)
files.ex 18257 call_list(_TagFileRefresh_,,)   p_window_id: 25 (invalid)
tags.ex 241 _TagCallList(_TagFileRefresh_,,)   p_window_id: 25 (invalid)
wkspace.ex 15431 workspace_remove(C:\src\plugins3\some_project\some_project.vpj,,1)   p_window_id: 25 (invalid)
project.ex 3830 project:CloseAndDeleteNewWorkspace(0,0)   p_window_id: 25 (invalid)
project.ex 3776 workspace_new_project2(C:\src\plugins3\some_project\some_project.vpj,Java - Gradle,,C:\src\plugins3\some_project\some_project.vpw,0,1,,,1,<empty>,0,0,1)   p_window_id: 25 (invalid)
wkspace.ex 10157 workspace_open_gradle(C:\src\plugins3\some_project\build.gradle,1)   p_window_id: 25 (invalid)


[patrick]

It should not be checking the gradle home if you've got the wrapper checked.  I'll take a look at it.  It must be something specific to the open other path.

It looks like the stack caused the workspace to to not be deleted, so I'll take a look at it as well.

[patrick]

I found the bug, it's specific to Open Other Workspace.  I'm working on a hotfix for it.

There's not a great workaround for this, so I'll send you an updated gradle.e you can load to hold you over till the next hotfix release.

[jporkkahtc]

Thanks

[patrick]

Load this and it should allow you to continue open the existing project without having to give it a gradle home when there's an existing wrapper.

This part doesn't address the stack and the files left laying around after the cancel.

[patrick]

Taking a closer look at the stack now.  Which hotfix are you on?

[jporkkahtc]

Slickedit\25.0.1\hotfixes\hotfix_se2501_2_cumulative.zip (Revision: 2)

[patrick]

re your import problem:  I was wrong, I wasn't running the same version of Gradle as you, I was on 6.2.1.  I could reproduce the problem once I moved to 6.8.3.

The fix for this will be in the next hotfix.   Attached an updated gradle.e.

[patrick]

Putting this reply here, so it is searchable.

Questions though: 
1. How does Slick determine which gradle tasks to expose? Many are not
exposed, for example "ant_all".
 
2. The "buildSrc" project (See:
https://docs.gradle.org/current/userguide/custom_plugins.html)
Shows up in the project window, but with only one file: build.gradle
But, below "buildSrc" (not a child, a sibling), is "
[some java package]", and inside that is the groovy source code.

For 1), it should expose all of them.  Looking on my system, I did find some samples from the Gradle site that don't show all of the tasks, so I'll need to take a closer look at that and see what's happening.

For 2):  The .gradle files should show up, but they won't show up in a package (the entry with the gift box icon), but under a directory in the tree.  If you don't see them in any directory icon in the project tree, then that would be a problem.

I'm not sure I'd want to see the gradle files in the package tree.  Package doesn't have any meaning for Gradle files.  They're technically Groovy, but really they're a DSL that you can't "import" anywhere, they can only be interpreted by Gradle.   If we want to group the plugin's gradle files with the plugin's supporting source code, maybe a better option would be to create a separate project for the plugins in the root project. 

[patrick]

The main problem with the missing tasks was some of the sub-projects that weren't directly off the root directory of the Gradle project weren't picked up.  I've put a fix for this in the next hotfix.

The projects it built were wrong enough where I wouldn't depend on a Gradle Options fixing it. It would be best to remove all of the SlickEdit project files, and re-import it after you have the update.

[jporkkahtc]

This update to gradle.e didn't appear to change the set of tasks available -- still many missing.

WRT the list of tasks: Please include the fully-qualified task name instead of just the task name.
There can be duplicate task names - and it is impossible to tell one from the other.

So instead of just "build", it should be ":project:build" because I may have
:project_A:build
:project_B:build
:project_C:build


"gradle tasks --all" prints the task names this way.

Please include the leading ":" to distinguish the root project tasks from sub project tasks.
In my root build.gradle file I have:

Code: [Select]

allprojects {
    // Print all project properties
    task showProperties {
        group('DebugBuild')
        doLast {
            project.properties.each { println "ProjProp: ${it}" }
        }
    }
}
Which makes "showProperties" appear in each sub project.
"gradle tasks --all" shows

Code: [Select]

showProperties
test_projects:showProperties
test_projects:ctp:showProperties
test_projects:PowerShell:showProperties
test_projects:wave:showProperties
test_projects:wbem:showProperties
wsinc:showProperties

Run 'showProperties' for all projects: gradlew showProperties
Run 'showProperties' for root project only: gradlew :showProperties

[patrick]

Is this for the project I have the gradle Output from?  Which commands aren't showing up?  I might be able to work out what's happening just looking at that output.
 
I'm experimenting with showing the full command list with no filtering for the current project, and leaving the fully qualified command.  It seems like a good change, it allows commands we filtered out before. There are more commands to sort through for complicated projects.  It's manageable, and if it becomes a problem, we could add filtering controls to that panel in a future release.

Just to make sure I'm clear: assume I have three projects, the root project, :a, and :a:b. And I have your showProperties task.   Ignoring the other commands, the command list would look like this

Code: [Select]

showProperties              - for current project and all projects below
:showProperties             - for root project
:a:showProperties           - for :a
:a:b:showProperties         - for :a:b

For the first one, that just runs the command unqualified, I'm unsure if I need to add a note to the description that says it runs from directory the current SlickEdit project, so for that project and everything below, or if that's clear to Gradle users from the context.

[jporkkahtc]

Interesting --- I hadn't thought of what the currently selected project means.
I always just build from the top level - but then, my project is small.

[patrick]

Ok, fixed it so all of the tasks are shown and properly qualified.  Unqualified tasks appropriate for the current project/sub-projects are also shown.

This also fixes the bug with the missing tasks.  Part of it was the task filtering I had to rework.  The rest was us unintentionally blowing away snake_cased task names.

WRT these tasks in the Build menu: Add something to make it clear these are Gradle tasks.
Maybe in the build menu instead of "ShowProperties", make it "Gradle: ShowProperties" or "Task: ShowProperties"
Or even as a sub menu: Gradle -> ShowProperties.
I like that better -- with a sub menu you can put *all* of the tasks and the user doesn't need to pick which ones are available.

For the fix, I just prefixed the Build target entries so they come out as "Gradle :app:build".  It would be nice to also have a sub-menu with all the tasks.  I believe we do something similar for Makefiles. I suspect that might need to be pushed to a release, because we don't keep all of the task information on hand, and we can't call gradle when building/updating the dynamic menus.

[jporkkahtc]

It works.
The new task list is great!