Change launcher of LSP server so it doesn't show up just as "JarLauncher" about sts4

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

We don't have a direct influence on the name of the java process. But we can change the way we package and launch the language servers by moving away from the Spring Boot maven farjar packaging towards using the maven-assembly plugin to create an uberjar (which also contains all dependencies but was exploded pieces).

Then we would launch the language server based on this new uberjar and use the language-server specific main class instead of the JarLauncher, so that the language-server-specific main class would appear in the jps list of java processes.

[kdvolder]

towards using the maven-assembly plugin

We were using that in the past and there was a reason we switched to fatjar packaging using the boot launcher. Maven assembly packaging basically just unpacks all of the dependcies on top of eachother and this is sometimes problematic as multiple resources end up overwriting eachother. We switched to boot fatjar precisely because this kind of resource overwriting was breaking stuff for us.

I do not think we should switch back, its a bad idea.

[dsyer]

That's why the shade plugin is better than the assembly plugin, because it has configurable strategies for merging things like properties files. If it's a Spring Boot application (or probably even if not) you should be able to use the shade plugin configuration from the spring-boot-starter-parent.

[kdvolder]

shade plugin is better than the assembly plugin, because it has configurable strategies for merging things like properties files

Maybe, but it seems like a real drag to have to figure out how to merge colisions of property files and the like between all your dependencies. Its also not always clear how to properly merge these things as it all depends on what kinds of things they are.

So that's why using the fatjar is even better because it just packages the stuff up as nested jars and there are no such problems that you have to figure out how to solve at all. So I think we should stick with fatjar launcher as it works the best without any special effort on our behalf.

[kdvolder]

Dave, I beleave you had a big hand in creating fatjar packaging / launcher, so maybe you have some good ideas about this.

I think process names might be a little nicer if we could launch all language server via java -jar some-language-server.jar assuming we differentiate the names of the fatjar files.

But unfortunately we can't use that when the language server needs access to tools.jar (on Java 8). It doesn't seem to be on the classpath for a typical jre (even if it is actually JDK) and we have to add it to the classpath via -cp argument. Command like java -cp tools.jar -jar some-language-server.jar also don't seem to work.

Maybe you have an idea how we can get fatjar launcher to pick up tools.jar and still launch with java -jar style command? Or some other idea that might work?

[martinlippert]

@dsyer What about an extension for the Spring Boot Maven plugin that takes an additional config argument from the pom and creates a main class with that specified name and uses that (instead of JarLauncher). I know it might sound a bit crazy, but wouldn't that be even useful for Spring Boot in general? You could specify a name and that name would appear in jps for boot apps in general. WDYT?

[dsyer]

I don’t think that’s the right solution (your main class would have to extend JarLauncher), but you can do it already with a custom “layout”. Check the Maven plugin docs.

How about using PropertiesLauncher? That layout works out of the box, and you can add stuff to the class path with command line args or with properties files.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

Changing this to a 3 points story. I'd give it more than 3 if I could.

The logics around launching jvms and attaching tools.jar is quite fragile and needs to be re-tested thoroughly if make any changes to it. These are manual tests on different os's and separately for atom, vscode, eclipse.

There will also be changes to the CI pipeline for vscode and atom. Another big timesink.

To be sure there are no mistakes in CI packaging there we have to at least smoke-test all the different language server extensions (spring-boot, concourse, bosh and cloudfoundry) across atom and vscode.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

Experimented a bit with properties launcher and I think it will work. Bascially all we need to do is change layout to 'ZIP' when configuring the maven-spring-boot plugin and then we can add do something iike this:

java -jar -Dloader.path=/usr/lib/jvm/java-8-oracle/lib/tools.jar some-language-server.jar

That seems to work fine, adds tools.jar to the classpath properly, and results in a more palatable name for the process in jps output.

[kdvolder]

Sigh... I will probably have to back out of this for now and probably have revert my changes.

@dsyer It seems -Dloader.path handling has a bug. It doesn't like file urls if the path has a space in it. So testing this on Windows stuff broke like this:

 java.lang.IllegalArgumentException: File C:\Program%20Files\Java\jdk1.8.0_161\lib\tools.jar must exist
	at org.springframework.boot.loader.data.RandomAccessDataFile.<init>(RandomAccessDataFile.java:55)
	at org.springframework.boot.loader.jar.JarFile.<init>(JarFile.java:83)
	at org.springframework.boot.loader.archive.JarFileArchive.<init>(JarFileArchive.java:60)
	at org.springframework.boot.loader.archive.JarFileArchive.<init>(JarFileArchive.java:56)
	at org.springframework.boot.loader.PropertiesLauncher.getArchive(PropertiesLauncher.java:494)
	at org.springframework.boot.loader.PropertiesLauncher.getClassPathArchives(PropertiesLauncher.java:470)

I'll raise a bug against spring boot about this. Maybe I can find a workaround. Otherwise we should probably revert the changes and wait for a fix from spring boot properties loader for that bug.

[kdvolder]

Luckily there's a easy workaround for the boot launcher url decoding issue. I simply pass the absolute path of the tools.jar rather than turning it into url and that seems to work both on Windows and Linux.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

I'm delivering this. I think it works. Did testing on Windows and Linux with atom, vscode and eclipse.

I tried a few different jvm / jre / 8 / 9 combos. But to e honest near the end some 'testing fatigue' set in and didnt test Eclipse on Windows in many combinations. Just a quick smoke test with JDK 8.

No testing was done on Mac, but I expect it to be quite similar to Linux and don't have a Mac at my disposal.

Also @mlippert will probably have to do some testing on Mac before accepting the delivery of this anyways.

[mlippert]

Sorry I hate the Mac and avoid it at all costs! 😃 But seriously you've got the wrong person flagged. I'm not a contributor to this project. I suspect you meant @martinlippert as I see comments from him above.

[martinlippert]

@mlippert Hey Mike, sorry for getting you on this thread here. The background reason is that we have an integration for these GitHub issues with our PivotalTracker instance so that comments are synced across the two systems and my handle on the other one is @mlippert, therefore the confusion. Sorry for this... :-)

[mlippert]

@martinlippert All is forgiven :-) actually there's really even no annoyance on my part, mistakes happen, and in this instance I see how easy a mixup it is to make, just by forgetting which system you're commenting in.

If/when it happens again, I'll just comment again (as long as I see your handle in the comment thread so I can figure it out). Good luck w/ the testing.