vscode-java
vscode-java copied to clipboard
redhat-developer
JBang support like jbang-idea
This is just an idea and if possible to provide as separate plugin instead of inside vscode-java I'm happy to do that.
Idea, in github.com/jbangdev/jbang-idea we got a plugin that does a "simplified jbang" support.
Two parts:
Easy running: It recognizes if a file has Common jbang start lines. //DEPS, //JAVA, ///usr/bin/env ... and provides a "run with jbang" option similar to how junit tests are recognized.
Updating classpath: Have a action "Sync JBang to classpath" which runs jbang info classpath to then update a classpath container called "jbang" which then is added to the java project (or created when needeD)
This combination makes jbang really accessible and works with and without a Gradle or Pom.xml file being available.
btw. What are the criteria/needs for this being available in code spaces/gitpod.io/Che ?
I think that's an open question. It's in many ways similar to gradle/maven support which comes builtin Afaics?
Are there things that would prevent an external plug-in to be possible to enable on Che, gitpod, codespaces ?
Classpath support makes sense here. Isn't mixing Jbang classpath container with maven/gradle asking for trouble though?
Isn't mixing Jbang classpath container with maven/gradle asking for trouble though?
yes and no. in jbang-idea the classpath container is setup separately from the main classpath container so it is isolated and easy to update independently and possible turn on/off avoiding lots of the problems.
Ultimately we would have a notion of a classpath only applied to a set of files inside a project but unfortunately, IDE's tend to work on the project level not per file thus having it as a separate classpath container is a best of both worlds.
If there was a way to only apply the jbang classpath in per file or folder it would be better but afaik that is not feasible (yet)?
Note, there are different usecases where jbang classpath support shows up:
- a single file that is self-contained (with possibly other source/file referenced), this could be in or outside a traditional java project - but its okey to limit it to only work when it is on source path.
- actual project based on jbang with multiple source files and more like a maven/gradle based projects
With the approach of a classpath container for jbang both of the above can be done fairly well with out too much special handling.
I made a POC some time ago which basically, contributes a new importer to JDT.LS, that delegates processing to https://github.com/jbangdev/jbang-eclipse/ An Eclipse project is created behind the scenes and the java file (and its related files) is linked to it. But, long story short, it's not ready to be shared, it doesn't really work. Between OOME and jdt.ls ignoring some changes, there's non-trivial work to do.
Yeah I think we can do simpler than what jbang eclipse attempts.
Just get the classpath is enough to then have content assist. And then provide run/debug via jbang and you have enough.
Won't that simplify things?
Closing as there's a dedicated extension for JBang now: https://github.com/jbangdev/jbang-vscode