wilkinsona
commented
7 months ago Thanks for the suggestion. If the two were decoupled, it would then make sense for them to be versioned and released separately. That's a significant ongoing cost that we don't want to take on. We'd also have to write and maintain the code to perform the dynamic download.
All things considered, I think it's better that we keep the VSCode plugin structured and released in the same way as the other IDE plugins.
rubensa
For now, looks like a specific spring-javaformat-vscode extensions version is linked with a specific spring-javaformat-formatter version, as spring-javaformat-vscode generates a "shaded" jar file adding only one class and specifying it as the main class in the resulting jar file MANIFEST.
It should be great to decouple this dependency and allow use different spring-javaformat-formatter versions with the same VSCode extension version.
I think this is feasible by creating a jar file containing only the VisualStudioCodeFormatter.java class and allowing specify the version (dynamic download) or path (specify a pre-downloaded version) for the spring-javaformat-formatter jar. Then, in SpringDocumentFormattingEditProvider.ts set the CLASSPATH to include both the spring-javaformat-formatter jar and the jar with only VisualStudioCodeFormatter class before running.
NOTE: I could already include a default spring-javaformat-formatter jar version or dynamically download latest on install to use it as default.
This should allow running the VSCode extension in a project configured with and old spring-javaformat-maven-plugin version 0.0.35 that has no spring-javaformat-vscode matching extension version.
In the future, it would also be great if the extension could infer the spring-javaformat-formatter version based on pom.xml and use that by default.