search

jQAssistant / Idea-Hub

Hub to propose and discuss new ideas, features, as well as general issues
0 stars 0 forks source link

Better support for Gradle multi-project builds #1

Closed jensborrmann closed 1 year ago

jensborrmann commented 5 years ago

We tried to embrace an approach similar to what is demonstrated in https://github.com/kontext-e/jqa-gradle in order to analyze larger multi-project Gradle builds. In principle that worked, so thanks for pointing out to that kickstarter.

But… using the command line in the context of a multi-project Gradle build gives us some challenges on Windows machines. These are caused by the 8191 bytes command line length limitation of Windows (see https://support.microsoft.com/en-us/help/830473/command-prompt-cmd-exe-command-line-string-limitation). The classpaths generated by Gradle dependency config containers can get quite large in some cases an exceed the 8K limitation by far.

We saw the following options: 1) [Already tried and discarded] Implementing our own Gradle plugin using the Java API This gave us major challenges due to the large number of libraries suddenly polluting the classpath of the Gradle build and causing library version conflicts to other plugins. And we just saw that you give the advise NOT to go down that road (https://stackoverflow.com/a/57874919/106260).

2) [Idea] Command line with parameters file The command line could be extended so that it also accepts parameters such as classpath from a file. This is the recommended workaround by Microsoft in their support ticket. Such a file could be populated by information from the Gradle build. Probably changes in https://github.com/buschmais/jqa-commandline-tool/blob/master/application/src/main/java/com/buschmais/jqassistant/commandline/Main.java could be sufficient.

3) [Idea] Hope for a standard Gradle plugin Are there any plans on your side to provide a standard plugin for Gradle? Such a plugin could maybe also use the extended command line [2]. Based on our experiences from [1] we would strongly recommend NOT using the Java API.

What are your thoughts on that?

DirkMahler commented 4 years ago

First of all: what is causing the long command line? Is it a large number of sub-modules?

The best solution would be a native integration within Gradle. This is on the wishlist but sadly not yet on a near horizon.

The parameters file is an idea that came to my mind as well, the Main class would be the right place to have an entry point for that. It should take the parameters supported by the CLI, i.e. URLs, paths as well takes properties for scanner/report plugins, etc.

kontext-e commented 4 years ago

Yes, since newer versions (think it started with 1.6) the classpath becomes too long for windows. The solution that works quite well in several of my Gradle projects is also used in the Kontext E plugin suite: https://github.com/kontext-e/jqassistant-plugins/blob/master/build.gradle Look for tasks jqascan, jqaanalyze or jqs.