WildFly Glow support in the WildFly Maven Plugin should be used

[jfdenise]

Today an hard coded layer is defined in the generated pom.xml, it should be replaced by the ability of the WildFly Maven Plugin to discover the layers.

[WolfgangHG]

@jfdenise do you mean to replace the lines

wildfly-archetypes/wildfly-getting-started-archetype/src/main/resources-filtered/archetype-resources/pom.xml

Lines 219 to 229 in 18e0ed9

	<configuration>
	<feature-packs>
	<feature-pack>
	<location>org.wildfly:wildfly-galleon-pack:\${version.wildfly.bom}</location>
	</feature-pack>
	</feature-packs>
	<layers>
	<!-- layers may be used to customize the server to provision-->
	<layer>cloud-server</layer>
	</layers>
	</configuration>

by

                <configuration>
                    <discover-provisioning-info>
                        <version>\${version.wildfly.bom}</version>
                    </discover-provisioning-info>
                </configuration>

(probably the most simple configuration, it worked for me when testing)

If this is what you expected, I can create a pull request. It probably requires more work to document this change for the users of this archetype.

Disclaimer: though I did some work with the archetypes, I had no idea about glow before you created this ticket, and I am not in the position of deciding whether this change is reasonable ;-).

[ehsavoie]

I agree it would make things easier. I was wondering if we should apply that to the archetypes

[jfdenise]

@WolfgangHG , yes that is what I was thinking it. Replacing all places were we hard code feature-packs and layers with the discovery. Let me know when we have a new release of the WildFly archetypes that integrate this fix.
Thank-you for taking this improvement into consideration BTW!
JF

[bstansberry]

@darranl raised a good point in #wildfly-developers > Using WildFly Glow in the getting-started archetype -- we need to coordinate this change with changes to places that document this archetype. So, @jfdenise we need a plan for that.

There may be nothing to do; https://github.com/wildfly/wildfly.org/blob/main/getstarted.adoc doesn't seem to discuss the provisioning details. But we should check if there are other guides that build on that and do discuss this.

Plus if there's some other place I'm not thinking about.

[WolfgangHG]

I tried to add a additional "provisioning" profile to the "wildfly-jakartaee-webapp-archetype" and ran into an error WFLYCTL0212: Duplicate resource [(\"deployment\" => \"multi.war\")]"
Reason: The provisioned server already contains the app created by the archetype ("multi.war"). The arquillian integration test creates a deployment itself that is deployed to the server and the test is to be executed on the server side. But this deployment is also named "multi.war".

In the "getting started" archetype, it is solved by using two different names: the resulting war of the generated project (that is added to the provisioned server) is named "ROOT.war". The deployment that is created as part of the arquillian test is named "GettingStarted.war" here (because of the "defaultClassPrefix" defined in archetype.properties).

So, when the test is running, we have deployed an application as "ROOT.war", and the arquillian test deploys another app with different name, but similar server side content plus the test class.

In the "webapp-archetype", the war file is named "${project.artifactId}.war". So, in order to run the tests on a provisioned server, I would have to give it a different name (e.g. "${project.artifactId}ForTesting.war").

Before starting to do the same for the "wildfly-jakartaee-ear-archetype", I want to fetch feedback: do you think it is reasonable to have three profiles "remote server", "managed server" and "provisioned server" in those two archetypes? This way they would be more in line with the "wildfly-getting-started-archetype".

[jfdenise]

@bstansberry , @darranl I looked into guides and WildFly doc. There are 2 places where the archetype is referenced.

• https://github.com/wildfly/wildfly.org/blob/main/guides/database-integrating-with-postgresql.adoc
  In this one we are already making use of WildFly Glow so we are good. No changes required.
• https://github.com/wildfly/wildfly.org/blob/main/guides/get-started-microservices-on-kubernetes/simple-microservice-part1.adoc
  In this one we need to update the guide, I opened a PR with the expected changes: Use WildFly Glow support for simple-microservice-part1.adoc guide wildfly.org#776

[WolfgangHG]

A pull request for the GettingStarted archetype was sent.

@ehsavoie In my local project, I also added a "provisioning" profile to the web app project (additionally to "managed" and "remote"), and all three profiles seem to work - but it feels a bit strange to combine them all in one project. This could cause big trouble. And I prefer using a remote profile when building my own stuff, so don't feel like discarding the managed/remote profiles completely.

But now I am stuck with the ear archetype: the integration tests in the web module are run after the web module was built. But provisioning must happen when the ear project was built. So the provisioned server is not available in the web module tests.
@jfdenise do you have any idea how this could be resolved with glow (if possible at all)?
It would only work if the integration tests of the web module are run after the ear project was built.

[jfdenise]

@WolfgangHG , I had a look to the ear project.
The tests that are in the web project could be removed and moved to a new module named "tests". This module would depend on web and ejb modules.
You would then document that to run the tests with the provisioning profile do:

mvn clean package
mvn wildfly:start
mvn verify -Pprovisioning
mvn wildfly:shutdown

You will have to change the names in the IT test to avoid conflict with the deployed ear.

I noticed that the ejb depends on the EE configured default datasource. Glow can't see what kind of datasource to provision (could be h2, postgreSQL, ...)
To fix that you have 2 choices:

1. Use the h2 datasource. In persistence.xml replaces java:comp/DefaultDataSource with java:jboss/datasources/ExampleDS. Doing so Glow will understand that you want h2 datasource.
2. or don't edit the persistence.xml and in the <discover-provisioning-info> of the WildFly Maven Plugin used to provision the server in the ear module add the h2 default datasource add-on, that would look like:

<discover-provisioning-info>
  <version>${version.wildfly.bom}</version>
  <add-ons>
    <add-on>h2-database:default</add-on>
  </add-ons>
</discover-provisioning-info>

I would prefer the solution 2, it will make it clear that we made the choice to use the h2 default datasource. But open to feedback.

[WolfgangHG]

@jfdenise About the datasource: yeah, I found out two days ago too. Glow pointed me in the right direction, and I also followed suggestion 2.

I sent a pull request for the web app archetype (#148) and request comments. It required a change in the way the test war is created (#145 (comment))

About the EAR archetype:
The easiest way to resolve this would be to create a profile "provisioning" that does not perform tests, and afterwards execute the profile "arq-managed" with a jboss home pointing to the "target/server" dir.

Splitting the project in multiple parts is a rather big change, just for resolving this one special case. Currently, I don't have a concrete idea how to do this - I would have to do a lot of research and experimenting. I am not a maven pro ;-).

[WolfgangHG]

Should we keep this issue open, as the webapp and ear archetype pull requests are still open?