Keeping run context as file (alternative to `info tools`)

[jmini]

trafficstars

Is your feature request related to a problem? Please describe. I am using jbang in a CI. I would like to keep a structured artifact of the run context.

Describe the solution you'd like Something similar to info tools but maybe with more information (info tools is focusing on what matters for an IDE)

Describe alternatives you've considered Currently I am using info tools for that:

./jbang info tools myJBangScript >> <saved to file that is stored next to the build result>
./jbang myJBangScript foo bar

I have started to also use --verbose, but this prints stuff in the console and in melt in my CI logs. Also the --verbose output is really log oriented. For example the classpath (resolved dependencies) is way more readable in the JSON tools output than in the logs.

Ideally my CI logs would stay concise.

I think a "--verbose to log file" feature could work for my use case.

Additional context As an example one use case is to understand which version of a jar was used, since I am using open ranges for some of my dependencies (see https://github.com/jbangdev/jbang/issues/1267#issuecomment-1054348159 -- already working when using the @Grab notation)

[quintesse]

All JBang run output (so not the output of the application being run) is on stderr, perhaps it's enough to simply redirect that to a file? (Although that would of course mean that any output on stderr from the application would also be redirected, so it's not the same as a "--verbose to log file")

[maxandersen]

What info is it you are missing specifically in the info tools ?

[jmini]

For example stuff added on the command line --deps / --repos is not present in the info tools JSON.

---

But I think, ideally for me I would like this context file to be created when I run my script:

jbang run --context path/to/output <other jbang args> myScript <script args>

Then the context could also contain stuff like the script arguments. And I would run my jbang command only once (no need to do jbang info tools and jbang run)

[quintesse]

For example stuff added on the command line --deps / --repos is not present in the info tools JSON.

This is actually expected behaviour. Those options are runtime-only, so they are not seen as part of the application. But you can easily include them by adding the same --deps /--repos options to the info command as you'd add to the run command, like this:

jbang info tools --deps org.example:dummy:1.0 myapp@repo

[jmini]

@quintesse: this is what I am doing:

./jbang info tools <args> myJBangScript
./jbang <args> myJBangScript foo bar

<args> is the same for the 2 runs.

---

With jbang info tools --deps org.example:dummy:1.0 --> You see org/example/dummy-1.0.jar in the resolvedDependencies section but not in the dependencies.

Is this really expected?

Tested with JBang 0.9.1

[jmini]

What info is it you are missing specifically in the info tools ?

The JBang version could be useful as well.

[quintesse]

Is this really expected?

Yes, the dependencies are the ones that are defined in the source and do specifically not include the dependencies you add on the command line (which are considered runtime-only as I mentioned before).

On the other hand the resolvedDependencies is the actual full classpath the application is being run with.

[maxandersen]

hmm - why wouldn't we include the --deps in the dependency list as well as resolveddependencies?

[quintesse]

Because info tools returns the information parsed from the source files, that's why it even works when the script isn't compiled. It also is hierarchical, so you can have nested info blocks for each source file, each only showing the dependencies that are defined in that source file.

So it doesn't make sense to add the dependencies that the user adds on the command line to the dependencies, to which one? The top level one? Then the information about that toplevel source wouldn't be correct anymore.

If you want the full classpath you can simply use resolvedDependencies, which is an extra top level element that basically contains the output of info classpath (and is only available if the script was previously compiled!).

Now if for some reason we really really really, with a cherry on top, want to include the dependencies that the user added on the command line we'd have to add an extra top level element, eg. extraDependencies or commandLineDependencies or whatever.