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.