jbang
jbang copied to clipboard
jbangdev
jbang "plugins"
until now i've been hesitant to make jbang pluggable but I think I found a usecase where it could be the best option: extend jbang to do things like test, codecov etc.
these are things I don't really want to put into the core of jbang but I would like to be more accessible to jbang users.
i.e. today you can do the following to instrument your code for codecoverage:
jbang --javaagent=agent@jacoco Snake3dApp.java
that is easy enough; but when it comes to the report:
jbang cli@jacoco report --classfiles ~/.jbang/cache/jars/Snake3dApp.java.18fdbbb06380ec9b425414e14b60f3aab129ea87e6941197850153239801f846 --html html --sourcefiles . jacoco.exec
now..we can simplify some of this using:
jbang cli@jacoco report --classfiles `jbang info classpath Snake3dApp.java` --html html --sourcefiles . jacoco.exec
but what if you could do:
jbang codecov report Snake3dApp.java
and it would be able to transform that into the right command.
We kinda could make it work with aliases today we just need to find a way to have the alias "talk back" to jbang...i.e. if alias marked 'plugin' we pass a json doc to it via env var or similar for it to extract get info needed, possibly make a small client lib.
btw. thinkinga bout this we probably be better of just making a jbang api aliases can use/do to get access to classpath, caache info etc.
What would that API look like? An actual API? Another option would be to write that info (to yet another temp file? hehe) and pass in a path to it using a system property for example. (We could then create a simple Maven module to obtain and parse the file to make it even easier)
The Challenge is we don't know what the parameters after the plugin means so we can't really know which file to parse.
So we would kinda need to give access to some boiled down API to get access to something similar like Script.
But right now that is a mess :)
But isn't that something we could define? That plugins always get passed the path to that file as their first parameter?
Wouldn't that be too limiting ? For example then doing other things like, 'alias' wouldn't work as it has name then script.
I'm not sure I understand, alias is a built-in command, not a plugin. I'm referring to the underlying program that would get executed. That could have an extra first parameter that would be hidden from the user, right? You could then say that all plugin commands have the support being passed that path as their first parameter. That was my idea at least.
But how would you know what is the script ?
'jbang myplugin X y c'
...which of those three are the script and which are other arguments ?
Wait, now that I think about it my first idea was to pass the path to a file as a system property, not as an argument :-)
that is fine - we can pass it along in a bunch a ways (sys property/env var etc.) but the problem is still (which I didn't think about when opening this) jbang can't know what is the relevant script file as the location on the user call to jbang cannot designate what is the relevant script file.
like, give me an example of jbang command line that activates a plugin which itself takes some arguments...
It would be nice to take a fresh look at this. I think there are some (current) commands that could be turned into plugins thereby reducing the "load" on the main jbang application ("export" could be one of them for example).
So my first question would be: can you explain a bit more what you meant by:
like, give me an example of jbang command line that activates a plugin which itself takes some arguments...
Perhaps you can do the opposite and give an example of a command line that shows the issue/problem you are referring to?
NB: one issue I can think of that might make turning subcommands into plugins problematic is when someone expects the command to be available in an offline situation and it's not. (Eg. imagine "export" to be a plugin. Then a user installs jbang, disconnects from the network and tries to run jbang export. Fail.)
So having a way to pre-install plugins (aliases) without actually executing them would be necessary (Edit: ok jbang build can do that, of course). But then you have to be careful to never run cache clear or suddenly your plugins stop working.
Not sure if I'm overthinking this :-)
is this request replaced with https://www.jbang.dev/documentation/guide/latest/integration.html
@filippor not exactly - the integration is for integration external code into jbang's build phase.
This issue here is about enabling to add additional commands into jbang.