Improve plugin distribution size

[YannCebron]

Current plugin is 89MB which might be challenging for some users (depending on their connectivity).

I see there's a broad range of bundled versions of Checkstyle (and their corresponding dependencies) packaged inside the plugins lib directory, maybe their total number could be reduced and/or they could be downloaded by demand?

[jshiell]

It actually hit 150Mb a while back, before I started rerouting dependencies for minor patch changes.

Download-on-demand would be the best solution, but it's unlikely to happen. It's a significant amount of work (and support), and I haven't used this myself for years, and hence my motivation to put more than maintaince work into it is pretty low.

As for reducing the versions, it's very possible, the catch is deciding what to delete. The easy option is to remove versions which are backwards compatible - @tsjensen used to maintain a very handy list of such version but it hasn't been updated in some months. Beyond that, it becomes arbitrary. So it's finding that line between people complaining about the version they need no longer being packaged, vs people worried about the file size. No easy answers, I fear.

[YannCebron]

Thanks for the prompt reply and explanation.

[tsjensen]

I like the idea, which is being suggested every once in a while. But like @jshiell explained, it's a bit too much work atm.

On another note, it's absolutely possible to build this. You'd use a library like Apache Maven Artifact Resolver / Aether to get the Checkstyle dependencies from the Checkstyle Maven coordinate, download and cache everything, and build the classpath dynamically. (Currently, the classpath is constructed at build time and read from a property file at runtime.)

About the Checkstyle Compatibility Matrix: I'm actually considering to discontinue it. 😢 It covers more than 10 years of Checkstyle, but its impact has been small, and the effort of analyzing every release for breaking changes has become to much. <rant> Also, I get upset at their amateurish versioning and release practices every time, and feel like I should not spend my time making up for that, when fixing their practices would be so much easier (for them, too). </rant>

[tsjensen]

Or even easier: We keep the build-time generation of checkstyle-classpaths.properties, but add download links, and perform the download when a version is selected. We might even ship a few especially popular versions so that it can work in an offline scenario, where our plugin is installed from disk.

But even this approach is still a lot of work, because we'd have to integrate with the IDEA download mechanisms, add error handling, and add synchronization, so that for example we don't start analysis before the downloads are complete.

[ahus1]

I've implemented something similar for the AsciiDoc plugin. Most of the download code can be found in AsciiDocDownloaderUtil.java.

You'll find some links to implementations in the JetBrains source code and screenshots of the AsciiDoc plugin in issue asciidoctor/asciidoctor-intellij-plugin#515. Maybe you find this helpful.

[jshiell]

I'm going to drop 6.x and 7.x support in the next release, given 8.0 is now 4 years old. That gets it back down to 79Mb at least, not ideal but at least it's in the correct direction.