Uses shaded eclipse dependencies in Gradle plugin

[magJ]

As mentioned in #139 (comment)
When running the gradle plugin using versions of org.eclipse.jdt:org.eclipse.jdt.core above 3.17.0, formatter tasks(ie checkFormat* or format) fail with a Java heap space issue.

Exact cause is unknown, but it appears as though the loop in io.spring.javaformat.formatter.eclipse.DefaultCodeFormatter#tokenizeSource never encounters it's break condition.

Demo project that produces the issue: https://github.com/magJ/spring-format-issue

Now using the plugin, and replacing the shaded runtime jar with the real eclipse dependency, is not documented anywhere, so I anticipate this being closed as an unsupported use case.
I could raise the problems with using the shaded runtime jar as a separate issue if desired, but in short, it contains all sorts of classes and junk that conflict with other plugins used in gradle.

[wilkinsona]

Thanks, @magJ. I wasn't aware that you were overriding the version of the Eclipse runtime that's used. I'm pretty sure that makes this a duplicate of #139. Let's keep it open for now though as I'd like to learn more about the problems caused by "all sorts of classes and junk that conflict with other plugins used in gradle". Can you expand on that a little bit please? What sort of problems and conflicts have you seen?

[magJ]

@wilkinsona I can't provide you example code at the moment, but the problem that I ran into was with a plugin that used a jersey client.
Jersey has some code to detect OSGI which was failing with a java.lang.NoClassDefFoundError: org/osgi/framework/SynchronousBundleListener.
This is because the spring-javaformat-formatter-eclipse-runtime jar contains the referenced OSGI class.
However, just looking at what other classes are included, I would anticipate that it could also interfere with all sorts of other plugins.
For some reason the shaded jar includes:

• junit
• mockito
• assertj
• OSGI

Seems like it could go on a diet.

[wilkinsona]

Unfortunately, I don't think that's possible. Those classes come from the various jars files in Eclipse upon which spring-javaformat-formatter-eclipse-runtime depends. The build already uses Proguard to reduce things down to what's needed to get things running outside an Eclipse IDE. It may be that there are some false positives there but it would be an error-prone process to find them and I think the end result could be rather brittle.

The lack of class loader isolation between plugins is a long-standing weakness of Gradle. There was talk of it being addressed a few years ago but, as far as I know, other higher priority changes took priority and it has yet to happen. If clashes become regularly problematic (this is the first time we have heard of one) it may be that we have to implement our own isolation.

[philwebb]

The updates sample works with the latest version when jdt 3.19.0 is used. Unfortuantely 3.18.0 doesn't work.

[philwebb]

I've updated the Gradle plugin to use shaded dependencies which should stop the classpath clashes.