This Jira is cloned from https://github.com/wildfly-extras/wildfly-myfaces-feature-pack/issues/12

This feature pack does two things:

1. Installs some modules necessary to use.
2. Makes a simple config change to make those modules the default JSF impl. (See https://github.com/wildfly-extras/wildfly-myfaces-feature-pack/blob/master/galleon-content/src/main/resources/layers/standalone/myfaces/layer-spec.xml#L13-L15)

The latter is reasonably done by the feature pack itself via a Galleon layer, and that limits its use to slimmed standalone servers, as those are what use Galleon layers.

But there is no reason to limit the former (module installation) to slimmed standalone servers. The modules are useful in domain mode installations and in non-slimmed standalone servers. 99% of what this FP does is provision the modules, so simply by using it the user has indicated those modules are wanted, regardless of specifying layers.
I believe they are usable via deployment configuration with changing the configuration. And even if they are not, the config change can easily be applied via CLI after using this feature pack to install the modules.

Work on this should not include making a domain.xml config change when the FP is provisioned. We'd need to decide what profiles etc to change, and the only logical answer would be default, ha, full, full-ha, which very well may not be what's wanted. Better to let users decide what profiles they want updated and let them use the CLI to do it.

I believe a configs/domain/model.xml like this would fix it for domain mode:

 <?xml version="1.0" ?>
<config xmlns="urn:jboss:galleon:config:1.0" model="domain">
    <packages>
        <package name="jakarta.faces.impl.myfaces"/>
        <package name="jakarta.faces.api.myfaces"/>
        <package name="org.jboss.as.jsf-injection.myfaces"/>
    </packages>
</config>

 
An analogous change to configs/domain/model.xml would do the same for standalone servers.