Mvn / gradle plug-in to bootstrap jbang

[maxandersen]

Lower barrier of entry.

Mvn jbangdev:run and jbangdev:install

[abelsromero]

Two considerations:

1. If the goal is to lower the barrier, it makes sense to have a plugin to run scripts from maven because you don't need to install anything. But then, doesn't the install goal becomes a bit meaningless?

2. I think it should be already possible using download plugin, and maven-exec-plugin to extract jbang inside the project and some script. Is there any other advantge to the plugin other than ease of configuration?

[maxandersen]

What I keep forgetting every time I think to do this is that neither maven or gradle seem to allow run arbitrary plugins with a short name unless you are in the list of "blessed" plugins - if you are outside that blessed set you must be referenced in the Pom.xml.

So yeah - main usecase would be to enable more easily run jbang style scripts from builds.

[maxandersen]

How would you do the download / execplugin for this ?

Would be great to at least have it documented.

[abelsromero]

What I keep forgetting every time I think to do this is that neither maven or gradle seem to allow run arbitrary plugins with a short name unless you are in the list of "blessed" plugins - if you are outside that blessed set you must be referenced in the Pom.xml.

Still, an hypothetical plugin would allow running jbang scripts without configuration like this dev.jbang:jbang-maven-plugin:run -Djbang.script=.jbang/run-it-test.java. Not bad I think.

How would you do the download / execplugin for this ?

Can give it a try tomorrow morning :+1: The idea is to use com.googlecode.maven-download-plugin like in https://github.com/asciidoctor/asciidoctor-maven-examples/blob/7e8d7870b2224ac9052db3f076b5cf037c49f409/asciidoc-to-revealjs-example/pom.xml#L59-L76, and then https://www.mojohaus.org/exec-maven-plugin/usage.html. The tricky part is choosing the phases.

But I can also start on the maven plugin, I have no idea how piccoli processes aguments. But unless there's some compile time code generation, a first version with only "run" goal that calls the current Main class should work and should be ready by end of week. In the long run, jbang should provide a API for cleaner integrations to do things like managing "trust" domains cache without affecting local configs, and also expose console messages.

[maxandersen]

Still, an hypothetical plugin would allow running jbang scripts without configuration like this dev.jbang:jbang-maven-plugin:run -Djbang.script=.jbang/run-it-test.java. Not bad I think.

can you avoid putting version ? in any case; yes - better than nothing ;)

calls the current Main class should work and should be ready by end of week

that would be awesome :)

In the long run, jbang should provide a API for cleaner integrations to do things like managing "trust" domains cache without affecting local configs, and also expose console messages.

+1; haven't been needed (yet) but yes that is all doable.

[maxandersen]

btw. https://github.com/fbricon/jbang-maven-plugin has a quick'n'dirty maven plugin - uses process launch as opposed to jbang.Main

[abelsromero]

Here is a working download/exec maven example with a brief README https://github.com/abelsromero/jbang-embedded-maven-example. If you are still interested, point me where in the README you want to add it. I am thinking that just the properties and plugins sections from the pom.xml and the plugins explanations should be enough.

can you avoid putting version ?

Yes. Don't understand how (even tested with a clean local repo), but maven is able to get the latest.

btw. https://github.com/fbricon/jbang-maven-plugin has a quick'n'dirty maven plugin - uses process launch as opposed to jbang.Main

It's a start but it's pretty different from what I had in mind, the plugin runs from local installation so we still need to install it. We could install it inside the plugin manually downloading from releases tab, but then we need to add extra logic (download, extract, path configuration, etc) that imo is more prone to cause issues than help.

I see 3 paths

1. Download manually and run as command: basically doing the same as in the example at the beginning but manually. I would not recommend since implies lots of extra work that has nothing to do with jbang.
2. Let Maven manage the dependency as a normal plugin: users can still change the jbang version so there's no need to relase the plugin on every jbang release. However, users need to add configuration to pom.xml to do so.
3. Manage dependency manually with shrinkwrap's MavenResolver: with this, we could manage the jbang version as a configuration property and add it to the classpath during plugin execution (I will test later the viability). With that, people could still run directly from console without touching the pom, for example: dev.jbang:jbang-maven-plugin:run -Djbang.version=0.36.1 -Djbang.script=.jbang/run-it-test.java

Btw, I saw jbang in not available in maven central, do you think it makes sense to publish? I also noted jbang jar is a fatjar, ideally we should publish as a normal one, so integrators can adjust dependencies.

[maxandersen]

thanks for the details and sorry for the delay - I've been pondering on this :)

• Download manually and run as command: basically doing the same as in the example at the beginning but manually. I would not recommend since implies lots of extra work that has nothing to do with jbang.

I must say I'm most inclined for this one as it enables use of the wrapper script and avoids adding in java API deps - what is that lots of extra work you are referring to here? is that the download of the jar ?

• Let Maven manage the dependency as a normal plugin: users can still change the jbang version so there's no need to relase the plugin on every jbang release. However, users need to add configuration to pom.xml to do so.

Yeah - this would be my least favourite choice; but if doing the option below it would be fine as a way to ensure the dependency is actually downloaded and shrinkwrap would find it.

• Manage dependency manually with shrinkwrap's MavenResolver: with this, we could manage the jbang version as a configuration property and add it to the classpath during plugin execution (I will test later the viability). With that, people could still run directly from console without touching the pom, for example: dev.jbang:jbang-maven-plugin:run -Djbang.version=0.36.1 -Djbang.script=.jbang/run-it-test.java

I can see the advantage; but does include commitment to a java api; unless just calling in via static void main() then it would stay the same. Would though need to remove/change the exit handling...

[maxandersen]

Btw, I saw jbang in not available in maven central, do you think it makes sense to publish? I also noted jbang jar is a fatjar, ideally we should publish as a normal one, so integrators can adjust dependencies.

its currently intentionally not published as its not (currently) designed to be reusable/composable as a dependency. Could change if find some usecases that justifies it.

[abelsromero]

I must say I'm most inclined for this one as it enables use of the wrapper script and avoids adding in java API deps - what is that lots of extra work you are referring to here? is that the download of the jar ?

:laughing: my order of preference is 3,2,1. About 3, you are right that calling main would be good enough for a first iteration.

The reasonfor my issues with 1 are that we will need to implement:

• Download and zip extraction.
• Defining where to store and cache the files.
• Error handling based on text parsing. At least some basic thing to detect if something failed and throw a MojoException. So that people integration in CI (eg. jenkins) tools can get some sort of standard report.

That's replication the whole logic of download-maven-plugin and exec-maven-plugin. That's where my original question "Is there any other advantge to the plugin other than ease of configuration?" was aiming. If we are only doing that, I don't see much point in the plugin, most likely scenario is we end up with a lot of manteinance work that is not related with jbang at all.

Maybe the best thing is document the usage of the other plugins and see if at some point the need for an API appears.

[maxandersen]

We already have inprogres of making jbang script self booting thus we need to define location for download (basically in ~.jbang) so that is not extra.

The advantage for the Mvn/gradle plugin is that you don't need to add 20-30 lines of mvn config :)

[abelsromero]

Sorry, took some time off, summer holidays.

We already have inprogres of making jbang script self booting thus we need to define location for download (basically in ~.jbang) so that is not extra.

Maybe it's better to wait and see where that leads to. Any link?

[aalmiray]

I can help with the gradle plugin if needed 😏

[maxandersen]

Feel free :)

I'm not sure if gradle usecase is as interesting as maven as with Gradle I can't run a plug-in without referring it in build.gradle, true ?

[aalmiray]

Oh yes, _youcan -> https://kordamp.org/kordamp-gradle-plugins/#_org_kordamp_gradle_inline You must have the org.kordamp.gradle.inline plugin configured in settings.gradle of course. Might be even possible to hide this with an init script (available to all projects for example).

[maxandersen]

meh ;) why is everything easy with maven hard with gradle and viceversa ? :)

[aalmiray]

Nailed it 😜

[maxandersen]

/cc @gastaldi doesn't seem to be able to assign you but now you are mentioned :)

[gastaldi]

Working on it 👍

[gastaldi]

Voilà: https://github.com/jbangdev/jbang-maven-plugin

[maxandersen]

going to update this to be just mvn and open separate one for gradle. now that mvn one is there.