Thanks, Jeff, for the detailed explanation!
On Fri, Dec 1, 2023 at 9:11 AM Jean Francois Denise <jdenise(a)redhat.com>
wrote:
Hi,
an heads-up that we are changing the approach when provisioning WildFly
with Galleon layers in the WildFly testsuite.
Prior to
https://github.com/wildfly/wildfly/pull/17153 (that should be
merged soon), a base layer (e.g.: cloud-server) + some decorator layers
(according to the test case) were explicitly set to provision servers used
by tests. So the actual set of required Galleon layers was generally larger
than what the test actually requires.
Thanks to the WildFly Glow <
https://github.com/wildfly/wildfly-glow>
Arquillian Maven plugin, we are now scanning the Arquillian deployments
(prior to the test execution) to discover the required Galleon layers. A
provisioning.xml file containing the discovered layers is generated and
used by the WildFly Maven plugin to actually provision the test server.
In order to validate that what the scanning has discovered is expected,
you can configure the wildfly-glow-arquillian-plugin maven plugin to
contain the element <expected-discovery>. For example:
<expected-discovery>[cdi, ee-integration, ejb, ejb-lite,
elytron-oidc-client, naming,
servlet]==>ee-core-profile-server,ejb,elytron-oidc-client</expected-discovery>
I could ask this on the PR but I'll ask here as it relates to a general
usage question.
I notice we are running the 'scan' goal in test-compile:
https://github.com/wildfly/wildfly/pull/17153/files#diff-100b3a1c5caf72ad...
Can it run in 'test'? How would it relate to standard maven build control
idioms like -fae and -DskipTests?
I'm not asking so much about your PR and the WF build; e.g. if a scan
failure failed our build that's not terrible. (Maybe it is; we'll see!) But
I could see how app developers could want to use this as just another test
of their app. They've at some point come up with provisioning instructions,
and they want to test that changes to the app don't invalidate those
instructions. But they want to be able to control this like any other test
execution.
The left part of the arrow contains the list of the discovered layers
according to the scanning. The right part is what will get
provisioned.
Composed of a base layer (always ee-core-profile-server) + a list of the
discovered layers that has been cleaned-up to avoid to include dependencies.
BTW: The PR
https://github.com/wildfly/wildfly/pull/17153 contains a lot
of examples of WildFly Glow scanning executions that you can use as
starting-point.
In case the test depends on some not discoverable features, you have the
ability to explicitly add add-ons to enrich the set of provisioned layers
(using the <add-ons> configuration element).
In addition, it can happen that some errors are identified by WildFly
Glow. Some need to be fixed, some could be fine in the context of the
tests. Errors that are fine in the context of the test can be ignored using
the <expected-errors> element.
Known WildFly Glow discovered errors:
* jakarta.naming.Context or InitialContext lookup: In case some lookup is
present in the test code that could hide the usage of a layer not
discovered. You can configure the plugin with <add-layers-for-jndi> to add
the layers that are required (if any) and hidden.
* ambiguous resource injection: An un-typed resource injection could hide
a required layer. You can configure the plugin with <add-layers-for-jndi>
to list the layers that are required (if any) and hidden.
* an add-on of the messaging family is expected by the messaging-activemq
layer. One of embedded or remoting messaging add-on is required.
* unbound datasources error: <name of ds>: A datasource is expected but
not found in the deployment. That is generally an error to ignore, the test
itself should add the datasource during the setup.
* no default datasource found error: It has been identified that a default
datasource is required. That can be fixed by adding the add-on
h2-database:default
You can find more information related to WildFly Glow in its documentation
<
http://docs.wildfly.org/wildfly-glow/>.
Thank-you.
JF
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His