Add option to generate IDE project and build files in current directory, instead of copying sources to temp dir

[lincolnthree]

In the situation where you're working in a multi-file project, jbang's default handling of IDE workspaces uses a temporary directory to "serve"/regenerate IDE configurations.

JBang also copies the source script to this "virtual" workspace.

This is fine when you only have one source file, but jbang really needs to copy all source files, and ideally, it also needs to be able to sync files that are created by the user in the IDE once the project is open.

I think a solution would be to simply generate IDE files in the current directory. Let the user choose to omit them (via .gitignore or etc,) rather than hiding them away by default.

This could be enabled/disabled by a --flag when starting jbang.

edit --open=code --live hello-world.java --workspace .

[murphye]

I would say, in my opinion, this is the #1 usability issue for JBang right now. The reality is that most developers are going to be working with multiple files including configuration and doc (README.md) put into a Git repo.

I would assume that if you are using Gradle under the covers that you can do some creative stuff with the source and build paths to make it transparent?

[murphye]

Worst case scenario, you might need to create a VS Code plugin to make this fully usable if you intend to hide away the build artifacts.

[maxandersen]

I would assume that if you are using Gradle under the covers that you can do some creative stuff with the source and build paths to make it transparent?

IDE's will assume build.gradle are somewhere in a "root" of the project so can't see how to be creative to work around it.

i've been pondering on how to do this without loosing the simplicity of "single" file edits.

My thinking is to do the following:

Change from jbang edit <file> to jbang edit <list of paths> so jbang edit afile.java works like today - will create a "hidden" symbolic linked project; but jbang edit adirectory will setup a project (or reuse what is there) in adirectory because its a directory.

This means we would scan for source files and locate one with //DEPS and //shebang header to use as "root" for resolving dependencies. In case there are ambiguities users can do jbang edit . src/mycode.java to explicitly mark src/mycode.java as the "root" to look for dependencies.

on top of that I'm considering change default jbang edit to be jbang edit --open --live and what it does today would be jbang edit --no-open. then it will be the most "aggressive" in helping users realize jbang have live edit feature.

[maxandersen]

current progress:

eclipse, vscode, intellij and gitpod.io now has jbang plugins that understands //DEPS so this "just works".

plan is to:

1. jbang edit xyz.java works as today with symbolic linked project
2. jbang edit . will open IDE on this directory and let the IDE Plugins handle it
3. introduce jbang export/convert to get maven/gradle project

[lincolnthree]

Woohoo!

[quintesse]

@lincolnthree we know you had to wait a long time for this, but it really took us quite some time to figure out exactly how we wanted to do this. And in the end a lot depended on the improved support we have in current IDEs for native JBang support. Without that we would probably still be discussing things 🙂

[lincolnthree]

No worries, I know how it goes! It was mostly just feedback to help Max -- And now I've come out of my hidey-hole to say hi :) I hope all is well!