compiler.nvim

compiler.nvim copied to clipboard

With my Kotlin Spring Boot project, I wondered why gradle didn't show up in compiler.nvim, and turns out it just checks for registered task, while I was just using the default bootRun task, with no need for additional tasks, so I modified the task_match to also look for just tasks.

Hopefully this can help others with no specific gradle configs to get it working in Compiler.nvim without having to resort to create custom tasks.

@Cliffback I've generated a spring project like this and after initializing it I see indeed there's a bunch of tasks.

I was not aware gradle plugins can add their own taks. It's not trivial for us to retrieve those though. We currently just parse registered tasks from build.gradle.kts such as:

tasks.register("hello_world") {
    doLast {
        println("Hello, World!")
    }
}

or in the case of groovy build.gradle:

task hello_world {
    doLast {
        println 'Hello, World!'
    }
}

In order to parse tasks from plugins, we would have to do "gradle tasks --all" and parse the output of the command (which can fail). We are not doing this with any other build automation utility so it would require a new implementation. So I would have to think about that.

We are currently using this test file for build.gradle.kts(kotlin) and build.gradle(groovy).

About the regex in this PR, I can't be really sure what is supposed to parse if you don't upload the example file you are trying to parse and instructions to reproduce.

Also, I've updated the wiki page of gradle covering the topics discussed in this PR.

Oh, I didn't mean to imply to include all tasks, only the application tasks listed in the screenshot you uploaded above (and the testing one is not included).

My reason for doing the pull request was basically that when doing the same Kotling Spring Boot setup with gradle as you did with the starter, the default way to run the app is just ./gradlew bootRun.

The bootRun task comes preconfigured as a part of the setup, and in many cases custom task are not needed.

I realize that the regex command won't work in all situations, as bootRun doesn't need to be mentioned to actually be there.

My suggestion would either be:

To parse gradle tasks --all and filter to only get the application tasks As you say, this would require a new implementation. If you want, I can give it a go, and you can see if it is an acceptable solution? I wrote an awk command that does this, so if so, i would "just" need to convert it to something that works on windows as well. I'd be really happy to give it a try at least :)

Or, you could check if the spring boot plugin is available, and then just assume that bootRun is a task (which it most likely will be).

Or leave it as is, but is less "plug and play", which is totally fine as long as it is mentioned clearly in the docs (which it now is)

@Cliffback Sorry for the long delayed response. Feel free to give it a go. I think both solutions are good. But indeed the current one is less "plug and play".

I'm not gonna develop it myself because I don't currently main java. But I can see how it could improve the QoL of java people.

So if you ever have time that would be cool.

@Zeioth All good, I'll give it a go when I have som extra time in the coming weeks

@Cliffback woah that was fast thanks!! I've tested the PR:

Manual testing

Spring projects now display application taks.

Our /examples/bau/gradle test show user registered tasks correctly too.

So all good!

Bugs found

• If application tasks are found, then user defined tasks are ignored.
• Both types of task should display.

You can reproduce the issue by creating a spring project, pasting this at the end of the kotlin gradle file, and running :CompilerOpen

// Example of a task
tasks.register("hello_world") {
    doLast {
        println("Hello, World!")
    }
}

Extra comments

• I see we consider application tasks and user defined tasks are the only relevant commands for us. As I stated I'm not a main java dev, but it seems reasonable to me.

Performance

• It seems gradle is remarkably slow in listing the tasks, which causes a small delay Telescope. but nothing too bad.

Maintainability

• With a little refactor it should be ok.

Thanks for the feedback! Had some extra time this weekend, so figured I'd give it a go :)

Regarding user defined tasks, i didn't pick that up, since my own user defined task was grouped as an "Application Task" like this.

tasks.register("bootRunProfiles") {
    group = "application"
    ... // Retrieve profile info from file
    finalizedBy("bootRun")
}

I haven't found an easy way to retrieve usertasks by commandline, so I just updated the code to just continue to the previous parsing of the build.gradle.kts file, but only add if the task doesn't already exist.

I also updated the powershell code to actually work on windows. If you want to test the powershell command on a Unix system, just install powershell and replace powershell -c with `pwsh -c'. I did this for writing and testing the command, and then I just verified that it also worked on a Windows machine afterwards.

I also removed the --all from the gradle tasks as it is not needed when we just retrieve Application tasks.

It should be added to documentation that gradle needs to be globally installed for this to work.

It would be important we only run gradle --list after checking a gradle file do indeed exist.

The reason is we check for all build automation tools of the project, and if we run the gradle command before checking if the gradle file exists (like the PR currently do), that small performance impact will affect all build automation tools.

I see, that makes sense! I’ll update it with a check for that. Does everything else look okay now?

Also, perhaps it is better to look for a Gradle Wrapper file in the root (gradlew), and run that instead of relying on a global gradle install? I use ./gradlew instead of gradle globally myself, and it comes as a part of spring boot projects generated with the official starter

If at least one of the files gradlew, build.gradle.kts, or build.gradle is present, then we can then do gradle --list.

I now updated it so that the gradle tasks command will run from inside of the preexisting check for build.gradle.kts and build.gradle

Also, I added support for using the gradlew and gradlew.bat directly, if they exist. So gradle should not be needed installed globally for this to work anymore.

The PR should be a single function. I'm gonna try to refactor it when I have time.