Thanks, Jeff, for the detailed explanation! On Fri, Dec 1, 2023 at 9:11 AM Jean Francois Denise <jdenise(a)redhat.com&gt; 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

Sounds good, Jeff. I've merged your PR. Thanks for your hard work on this! Brian On Mon, Dec 4, 2023 at 5:26 AM Jean Francois Denise <jdenise(a)redhat.com&gt; wrote: Thank Brian, reply inlined. On 12/1/23 18:09, Brian Stansberry wrote: > Thanks, Jeff, for the detailed explanation! > > On Fri, Dec 1, 2023 at 9:11 AM Jean Francois Denise > <jdenise(a)redhat.com&gt; 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? We currently check the expected layers in all cases. I am going to skip the checks if skipTests or maven.test.skip are set. -fae works as expected. If a scan fails, the maven execution of this module stops and next module is executed. The failures are reported at the end. > > 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 -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His