In order to take benefit from galleon layers feature, the servlet and full galleon feature-packs should define layers that could then be used to build custom installation. The layers are not intended to be exposed as a public contract, they are an implementation detail allowing for internal custom provisioning.

Only standalone configurations are impacted by layers.

We are proposing:

1) Define a set of servlet layers:
ee
legacy-security
naming
undertow
undertow-load-balancer
vault
web-server (complete servlet container)

2) Express the servlet default standalone configurations by a set of layers. The default configuration based on layers would be identical to the current one (based on feature-groups). feature-groups are the place where feature configuration occurs, layers are referencing feature-groups. The default configuration extends layers with legacy security aspects and undertow welcome content.

3) Define a first set of full layers that target standalone kind of configurations.
List of layers, layers defined in this feature-pack depend at least on web-server servlet layer.
cdi
h2-database
jaxrs
jms-activemq
jpa
microprofile
resource-adapters

4) Some servlet layers are extended to include packages present in full feature-pack:
ee
undertow
vault

5) Cloud profile layer
cloud-profile (aggregation layer of cdi, jaxrs, jms-activemq,jpa,microprofile,resource-adapters)

6) Resource management API is used to advertise modules injected in deployment units. Impacted subsystems: ee, security, connector, microprofile, jpa, jaxrs, weld, bean-validation.