SlickEdit Community

Archived Beta Discussions => SlickEdit 201x Beta Discussions => SlickEdit 2019 v24 Beta Discussion => Topic started by: Marcel on August 09, 2019, 05:38:33 PM

Title: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on August 09, 2019, 05:38:33 PM
Still working on collecting data for the subproject issue. I also haven't gotten a PM as of yet.

Title: Gradle project problems (continued from Java import disorganized).
Post by: Dennis on August 09, 2019, 06:13:41 PM
Would you mind if we changed the subject of this thread to something about Gradle, now that it doesn't involve organize imports ?
Title: Gradle project problems (continued from Java import disorganized).
Post by: patrick on August 09, 2019, 06:34:36 PM
Sorry about that, you should have a PM now. 

1. That makes sense.  I looked, and I do need to fix it to remember your choice for the next beta.

2.  That does sound like it could be with our environment handling.  Looking at it, I see that there are some places where I could miss that a project needed the tasks to be upgraded from a previous version, so this may be a combination of the two problems.

3. In general, if you open a project, you should see any other tags in any other projects.  The tags from the sub-projects go either to the workspace tag file, or a project specific tag file - but in both cases those tag files are searched from no matter with sub-project you have active.   So if you're not seeing tags from a particular project, my primary concern is that the files for that project aren't being registered in the tag file.   Back to gradle specific details, that might happen if the sub-project wasn't generated correctly, and is accidentally excluding the project's source files.

In the project view, if you expand a sub-project, and it doesn't show any source, that's a definite problem.  If it does show source, something else is going on, the other debug information you're gathering will narrow down what's going on there.
Title: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on August 09, 2019, 07:12:12 PM
@Dennis
Be my guest.  I have no idea how to link the original thread to this one, I leave this up to you.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Dennis on August 09, 2019, 08:46:34 PM
Original thread:
https://community.slickedit.com/index.php/topic,16952.0.html (https://community.slickedit.com/index.php/topic,16952.0.html)
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on August 10, 2019, 03:52:28 AM
Requested files uploaded.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on August 12, 2019, 12:53:36 PM
Thanks, I've got the files. 
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on August 12, 2019, 03:55:18 PM
The files you collected are a great help.   Thanks.

Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on August 22, 2019, 05:15:40 PM
Ok, found the bugs causing the Java compiler problem.


These are fixed for the next beta. 

It sounded like you wanted it to use the default compiler you set rather than the latest compiler, so you can change that setting for your project. Go to Project -> Project Properties, go to the Compile/Link tab, and change the compiler to "Default Compiler (current default compiler name)".

Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on September 06, 2019, 12:19:02 AM
@patrick: Has any work been done on this feature in b3? There was nothing listed in the readme.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 06, 2019, 12:52:20 AM
Yes, the Java compiler problem was fixed.  See my last post, since in addition to the bugs I found, it sounded like maybe your compiler setting for your project was to use the latest, rather than using whatever the default compiler is set to.

And there were a few problems I fixed with the Gradle dependency tagging that could have prevented you from seeing the tagged dependencies from some projects.  Run through Gradle Options for one of your sub-projects to force the tagging to update.  You may see some dependencies in the list you didn't see before - part of the bug was it was looking at dependencies for a single project when it was supposed to be looking at dependencies for the workspace.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on September 06, 2019, 02:05:28 PM
I did a reset on my Gradle project (nuked *.v* throughout the tree, except for the external dependency project), then recreated from the root build.gradle.

Dependencies for some of the subprojects are declared in the root script like so:

Code: [Select]
project(':sub1') {
    dependencies {
        compile (project (':sub2'))
        compile (project (':sub3')) {transitive = false}
        compile (project (':sub4')) {transitive = false}
        compile (project (':sub5'))
    }
}

After opening the sub1 project and rerunning its Gradle setup (should not be necessary?), anything defined in sub2...5 does not resolve (e.g. import sub2.xxx).



Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 06, 2019, 02:23:13 PM
Ok,  I can see it not picking up the sub-projects declared in that way.  It's a little irritating, because we can see all of the sub-projects from the data we collect, but one part of the code is limiting its scope to what's in the settings.gradle.  I'll take a look at that. 

I didn't fix the saved state for the gradle wrapper check mark yet.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 10, 2019, 08:36:18 PM
I checked in some fixes for the next build for the problem with the dependencies not being found after updating some sub-projects.  It could do a bit of damage when the bug triggered, since it could remove previously resolved dependencies from the list. 

With this fixed, you shouldn't see different results when you update different sub-projects.  And when dependencies change, updating a single project should update the tagging dependencies for all of the projects in the workspace, you shouldn't have to go to run update on each one.   I'm leaving the update as having to be triggered manually for this release.

Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 11, 2019, 06:22:40 PM
Fixed the problem with the gradle wrapper checkmark not remember what you chose previously for the next build.

The first time you bring up Gradle Options for a project in your workspace, it will still have it checked, because it will see the gradle wrapper in your workspace directory, and it won't have a previous choice to go by.  But after that, it should remember your choice for that workspace.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on September 20, 2019, 02:46:19 PM
I tested b4.  The Gradle wrapper checkbox problem is fixed, thank you.

As far as the missing subproject references go, I am beginning to think that my expectations are off. 

The difference is obviously that in the latter case SE does not have access to the root .vtg file which would provide the needed tags.

Do I need to manually add the root tag file?
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 20, 2019, 03:52:41 PM
If the root project and the sub-project are in the same workspace, then the tags are visible between the projects.  So if you go to "Tools -> Tag Files..." and look at the "Workspace and Project Tag Files" entry, the same tag files should be there no matter which project is open.

However, another developer pointed out to me that there are some options that can change the search scope to the current project.

Assuming you're using push-tag (ctrl-dot for most bindings), there's a option to restrict it to only show symbols in the current project.  If the language was Java, you'd go to "Tools -> Options -> Languages -> Application Languages -> Java -> Context Tagging", and in the "Go to Definition" group, check to see if the "When there are multiple choices"  is set to "Only Show Symbols in the Current Project".   There is also an option there to prefer symbols in the current project. So if you have a symbol that's shared between two projects, the it will prefer the definitions in your current project.

For searches under the Search menu, there are also options there to restrict searches to the current project.  Different from tagging, but something to keep in mind.

A less likely culprit would be that the two sub-projects have source files in different languages that we don't recognize as sharing symbols. (just as an example, Kotlin can see symbols for Java,  but wouldn't be able to see symbols in a C++ file, unless the "Tools -> Options -> Editing -> Context Tagging -> "Allow mixed language references" is turned on). 
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on September 20, 2019, 04:48:09 PM
This goes back to my wrong expectation remark.

If I open the subproject .vpj directly, it is detached and not part of the workspace, there is no back link to the original workspace.  SE will create a local .vpw and its very own .vtg.

I should not do that, it sabotages the whole workspace setup.  However, I need to find a way to work on multiple subprojects side-by-side, probably by using multiple -sc since I can only have one active project at a time.

Thanks for pushing the Gradle support ahead by a few miles.

p.s. Maybe you can convince Dennis to use your new workspace info for the organize import function, it still cannot find 3rd-party imports.


Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 20, 2019, 05:04:21 PM
Ahh, I was assuming you just had the root workspace open, and just changing the active project. 

Out of curiosity, what other operations do you need to do that depend on the current workspace?  Are you modifying a few projects at once and having to build them occasionally?  Depending on what you're doing, you may be able to access what you need for projects other than the current project via another mechanism, rather than having to fire up another instance.

Organize imports should use the tags of the workspace without any other setup, but I'll let him know in case I'm missing something there.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: Marcel on September 20, 2019, 06:10:12 PM
It is quite common that I have to work on several subprojects at the same time, e.g. a common library, a client and a server.  Each one is run through edit, build unit tests and debug cycles.  It would indeed be helpful not to have create separate instances.
Title: Re: Gradle project problems (continued from Java import disorganized).
Post by: patrick on September 20, 2019, 06:59:07 PM
I think the only way to do that via the UI is to right click on the project in the projects toolbar and choose the command you want from the context menu that pops up.  It will show any of the targets that would normally show up in the Build menu when the project is active.

If you were thinking about something that you could bind to a key or a toolbar button to perform the project specific actions, well it looks like you can't record a regular macro to do that menu action, because it's looking at the currently selected project in the Projects tab.  But it is doable with custom macro code, I can post an example if you're interested in that.