dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.49k stars 1.43k forks source link

Get import paths from gradle for Java and friends #587

Closed w0rp closed 5 years ago

w0rp commented 7 years ago

The javac and koitlinc linters are able to find import paths using Maven. This also for semantic analysis including imported classes. It would be nice to do the same for projects using Gradle too.

I am not familiar enough with Gradle command line tools to figure out how to do this myself. I did briefly give it a try, but it seems like the Gradle build configuration files change their format so frequently that you run into trouble trying to get the right version of Gradle to extract the paths with.

teasp00n commented 7 years ago

Hey w0rp.

They're doing this over in vim-javacomplete2.

There are a few key pieces to the puzzle:

  1. classpath.gradle defines a gradle task that will produce a classpath in the correct form for us to consume directly in vim.
  2. classpath.vim is the vimscript that actually determines the type of project (vim-javacomplete2 actually supports a bunch of different project descriptors). Specifically, you would be interested in the gradle flavoured methods.
  3. gradle.vim encapsulates all the logic for finding the build.gradle in the file system and invoking gradle with classpath.gradle I mentioned above and capturing the output.

That said, it would be ideal if this kind of common parsing could be handled in some base plugin that either these projects use as a submodule or that the user is required to explicitly add to their vim config. It could just expose some convenient variable(s) (in fact on *nix systems it can probably just export CLASSPATH) that plugins like yours could use and hide all this detail away/ not duplicate the maintenance effort.

@artur-shaik @wsdjeg @DonnieWest any interest in this?

wsdjeg commented 7 years ago

nice, I have implement the feature in neomake and syntastic, I but I not family with ale, wll look into it. but as I know, jc2 do not support kotlin now.

teasp00n commented 7 years ago

I have implement the feature in neomake and syntastic

This is kinda what I was talking about at the end of my last comment. If the gradle DSL changes in such a way that it breaks the current implementation then all the projects would need fixing. I think having this code in one place could be useful. Thoughts?

w0rp commented 7 years ago

Thank you all for the information. Feel free to create a pull request whenever you like.

wsdjeg commented 7 years ago

I think having this code in one place could be useful. Thoughts?

so I Think just check the value of g:JavaComplete_LibsPath in jc2. That will make neomake and ale 's javac maker simple.

DonnieWest commented 7 years ago

@teasp00n Agreed that having this all in one place would be nice. Perhaps a VIM plugin that has all the logic that's needed and exports makers for syntastic, neomake and ale? This would cut down on the amount of extra stuff in everyone's vimrc and also make it so those linting plugins don't have to add anything custom to support Gradle

teasp00n commented 7 years ago

@DonnieWest I was actually thinking a plugin that just exports g:jvm_classpath, g:java_sourcepath, g:groovy_sourcepath, g:kotlin_sourcepath etc.

w0rp commented 5 years ago

I'll close this, as this has been done by this point.