Support Hyper-V on Windows as an alternative to VirtualBox

[binkley]

Unfortunately Hyper-V and VirtualBox are not compatible. Would you consider supporting Hyper-V on Windows as an alternative to VirtualBox?

[axelfontaine]

Yes, this is certainly something we're considering, especially since some users may already be coming from Docker for Windows which requires this. It could never be a full replacement though as it doesn't support Windows Home, only Pro and up.

[axelfontaine]

This is now officially supported: https://boxfuse.com/blog/hyperv

With one limitation: https://boxfuse.com/docs/hyperv#limitations

[binkley]

Giving this a go:

https://github.com/binkley/sproingk/tree/40c634583828399f57d8ea886162370ed52ed69b

I get this error with the Maven plugin:

$ ./mvnw clean boxfuse:run -Dboxfuse.env=dev -Dboxfuse.platform=hyperv

Output:

[ERROR] Failed to execute goal com.boxfuse.client:boxfuse-maven-plugin:1.28.1.1375:run (default-cli) on project sproingk: ERROR: No payload specified and no payloads found in the current directory
[ERROR] => ensure it contains at least one of these payloads types: Jar, Tomcat, TomEE, Play, Grails, JHipster, Spring Boot, Dropwizard, Node.js, Revel, Linux x64
[ERROR] => alternatively specify the payload explicitly
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

As a general rule, when the Boxfuse documentation says to set property "foo", I'm guessing it means "boxfuse.foo". More explicitness would help me.

[axelfontaine]

This is however to be expected as you first clean your target directory, yet fail to build your artifact before invoking Boxfuse.

If you add package to your command line things should work:

$ ./mvnw clean package boxfuse:run -Dboxfuse.env=dev -Dboxfuse.platform=hyperv

As for property names, you can see the distinction in the docs: https://boxfuse.com/docs/maven/run

If you configure the plugin directly in pom.xml you do not need the boxfuse. prefix. However for system properties, to avoid conflicts with other plugins, you do need to add it.

We are certainly open to suggestions on how to clarify the docs or the error messages. We would love to hear how you would improve them.

[binkley]

Thanks, @axelfontaine. I feel slightly embarrassed.

I note the bootRun task for Spring Boot's gradle plugin, and spring-boot:run for the maven plugin, do not use the packaged jar, but run in place. I can see how this won't work for boxfuse -- the unikernel image is rather critical. :)

However, the command-line feel of just saying gradle <somethingRun> or maven <something>:run is natural, so the need to insert package before run with boxfuse feel unfortunate.

Would it make sense for the plugin to detect if the project jar is up to date, and use that without an explicit package, and when out of date run package automatically?

[axelfontaine]

This could be an interesting feature, but in all honesty I am not sure it's possible as I am not aware of any other Maven plugins able to do this.

[binkley]

@axelfontaine I don't have enough free round tuits. But when I do, I'd like to poke at this, and see if I can make a proof of concept. Might be possible to hook into the plugin lifecycle, and make "package" a dependent phase. Thanks, again!