feat: Added support for "plugins"

[quintesse]

Any aliases or commands on the user's PATH that start with "jbang-"
will be considered "plugins" and can be run as if they are part of
the built-in jbang commands.

See #487 for a very related idea. The difference is that there is no integration with jbang code. These plugins are completely separate commands (similar to the way git does it). But they might be used as the basis for the plugins discussed in #487, we'd "just" need to come up with some way to pass information back and forth.

@maxandersen this is some code I had still lying around. I've cleaned it up and created this PR so you can take a look and decide if you like the idea or not :-)

[maxandersen]

Congrats on 1000th pull-request!

I like the idea and been pondering how to have a way to pass on info or some kind of call back.

I was thinking jbang would have a http end point but once the jbang-* scripts runs the jbang process would be gone.

Best thing I can think of is to dump output of "info tools" in a temporary folder and have JBANG_TOOLS_INFO env var set to be passed on ... but that would require some magic in the shell scripts to work.

[quintesse]

I was actually thinking that, as long as the info is limited enough, it could just be directly passed as an ENV var. That way there's nothing to create and nothing to clean up.

You also have to think about what useful information could be passed, there doesn't seem to be that much. You have any examples of data that you'd like to pass that wouldn't be easy enough for the plugin to discover by itself?

[quintesse]

Congrats on 1000th pull-request!

Yay! Do I get a T-Shirt? 😁

[maxandersen]

You also have to think about what useful information could be passed, there doesn't seem to be that much. You have any examples of data that you'd like to pass that wouldn't be easy enough for the plugin to discover by itself?

the challenge is that we can't really pass much in as jbang don't even know what script/file it is targeting - or are you assuming that any non-flag argumentsis the script ref to look for ?

if not, then the plugin would need to have some jbang api dependency it could depend on to include to then do the jbang work.

[quintesse]

Well right now these "plugins" are more like Git plugins: they look like they're part of the main command but they're completely separate and therefore have basically nothing to do with it. (ie they're dumb)

For commands that want to deal with script refs and such we could make sure that JBang has a proper public API that people can use. Then a path to the jbang.jar would be the only information we'd have to pass to the command.

[codecov]

Codecov Report

Merging #1000 (bd83be6) into main (153b18e) will decrease coverage by 0.25%.
The diff coverage is 43.37%.

@@             Coverage Diff              @@
##               main    #1000      +/-   ##
============================================
- Coverage     59.30%   59.04%   -0.26%     
- Complexity      959      966       +7     
============================================
  Files            69       69              
  Lines          5052     5106      +54     
  Branches        859      869      +10     
============================================
+ Hits           2996     3015      +19     
- Misses         1595     1625      +30     
- Partials        461      466       +5     

Flag	Coverage Δ
Linux	57.79% <43.37%> (-0.25%)	⬇️
Windows	57.52% <39.75%> (-0.34%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/main/java/dev/jbang/Main.java	0.00% <0.00%> (ø)
src/main/java/dev/jbang/cli/JBang.java	69.93% <57.14%> (-8.84%)	⬇️
src/main/java/dev/jbang/util/Util.java	60.64% <70.58%> (+0.39%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2e6302a...bd83be6. Read the comment docs.