Provisioning just the standalone-full.xml fails due to missing modules referenced in the config

Provisioning a bootable jar with the

<included-default-config>standalone-full.xml</included-default-config>

option results in a jar that won't boot. The 'com.h2database.h2' and 'org.wildfly.openssl' are both referenced in standalone-full.xml, but the modules are not provisioned. The 'org.jboss.as.webservices.server.integration' also isn't provisioned.

Adding this plug-option does not help:

<optional-packages>passive+</optional-packages>

My impression from looking at AbstractGalleonConfig.setupPluginOptions() is that setting optional-packages to passive+ shouldn't be required anyway.

I'm discussing standalone-full.xml here, but I expect if I tried I'd see the same thing with standalone.xml, standalone-ha.xml and standalone-full-ha.xml. The standalone-microprofile.xml and standalone-microprofile-ha.xml configs do not have the problem. I believe that is because those use layers, and for each of the missing modules a relevant layer explicitly declares it as a package.

I see three aspects to this:

1) com.h2database.h2. Resolving this would either require new Galleon functionality like WFGP-238, or we move all the standard configs to using layers. I assume the latter will be the short term solution.

2) org.wildfly.openssl. Here there may be a Galleon or wildfly-jar-maven-plugin bug. The io.undertow.core module has an optional dep on this, so AFAICT passive+ should result in it being provisioned. If I've missed something and there's a valid reason passive+ doesn't provision it, then this is another case like com.h2database.h2.

3) org.jboss.as.webservices.server.integration. Here I think there's a webservices bug that likely should be handled under a different issue. My impression is if the subsystem is used this module must always be provisioned, but there is nothing telling Galleon this. It has a lot of dependencies, so relying on passive+ is not safe. Either the WS extension module should add a dependency or its ResourceDefinition should declare the dependency.

I focus on bootable jar here but it would not surprise me if provisioning using the galleon-maven-plugin or the Galleon CLI tool with the '--default-configs=standalone-full.xml' option has similar issues.