WebApp: add a profile for provisioning the server

[WolfgangHG]

Part two to resolve #145: I added a profile "arq-provisioned" to the webapp archetype that provisions a server and runs the arquillian tests using this server.

This pull request is a request for comments ;-).

The provisioning profile required a change to the way the arquillian test deployment is created: as the provisioned server already contains the war file, the test deployment war file must have a different name - I added suffix "Tests", e.g. "MyApplicationTests.war".

Probably, it would be more reasonable to name the deployed app "Root.war" in case of provisioning, but this would probably conflict with the old school use case to develop an app without knowing how it will be deployed. So I would prefer to keep the name as is - I added hints to the end user "Readme.txt" to change the deployment name depending on the use case.

[jfdenise]

@WolfgangHG , I realize that we should use in the arq profile the <skipDeployment>true</skipDeployment> config item of the WildFly Maven Plugin. So it will not conflict with the useless app deployment.

[WolfgangHG]

@jfdenise This would mean that we add another profile "provision" that builds the project and provisions a server, but does not run integration tests? And the "arq-provisioned" profile would provision the server, but with "skipDeployment" option, so that the deployed testing war file could keep it's original name?

In the my ear archetype change (#150), this would require two provisioning profiles ("provision" and "provision_for_arquillian")?

Should this also be added to the "getting-started" archetype to keep them in sync? But the "getting-started" archetype does not use profiles up to now.

[jfdenise]

I am not sure of the best, I wanted to highlight this skipDeployment in case it would make things simpler.

[WolfgangHG]

I can't decide either. "skipDeployment" sounds better, as the arquillian deployment could keep its name. But it means more profiles. I leave it to the reviewers of this issue.

[jmesnil]

I'm not particularly keen on having our archetypes propose multiple ways (aka profiles) to achieve the same thing.
This makes them more complex for the users that want to get started (which is the primary target for these archetypes).

So I would prefer that we provide a single way to compile/build and test a Web deployment on WildFly.

I think that the provisioned way is the better approach for development: you control the WildFly version from your Maven POM and you can test the actual deployment. There is no need to use ShrinkWrap to deploy a "fake" test deployment, the WAR is already there ready to be tested.

wdyt?

[WolfgangHG]

@jmesnil I am not sure whether we can remove the shrinkwrap WAR creation, as we have to enrich the deployed archive with the server side test classes so that the Arquillian ServletTestRunner can invoke them on the server side. They will not be part of the provisioned deployment.

Personally, I consider the archetype as a set of possibilities - it shows serveral ways to use WildFly, as it is currently doing for managed and remote instances. Using a provisioned server is another way. It is hard to collect them all in one project.
Would it be reasonable to add another archetype that focuses on provisioning and does not contain the arquillian-managed and arquillian-remote profiles? I agree with your concern that my current pull request makes the archetype project harder to understand for a beginner.

We could also remove the non-provisioning stuff and just point to it in "Readme.txt". This would follow your suggestion to keep it simple.

[WolfgangHG]

Hmmm, just an idea: we could add some properties to the archetype which query from the user the needed functionality (e.g. "provisioning", "arquillian", "jakarta_faces" with "yes/no" values).
In the pom.xml, conditional snippets using the Velocity Template Language seem to be possible: https://stackoverflow.com/questions/38831140/maven-archetype-optional-property-empty-by-default/60748225#60748225 so that e.g. profiles could be removed if "provisioning" is not selected.
Additionally, a groovy script could tailor the project created from the archetype to fit the requirements: https://ngeor.com/2019/09/07/optional-files-maven-archetype.html (e.g. remove the arquillian integration test sample file "SampleIT.java" or "faces-config.xml" if the features are not selected).

But those archetype properties don't allow to add a description, so they should have meaningful names, and there might exist combinations that don't make sense.

[WolfgangHG]

I split provisioning in two profiles (similar to the changes in the pull request draft for the ear archetype):

1. Profile "provision" just builds the server, without running arquillian tests. Here the web application is added to the deployment.
2. Profile "arq-provisioned" provisions a server (in a different directory), but does not add the web application to the deployment. So there is need to rename the arquillian deployment as it does not conflict with an existing deployment.

I think this makes the combination of features a bit more consistent. The only thing that is not perfect is that a provisioned server would probably contain a "ROOT.war" deployment. But I added comments to "Readme.txt" how to fix this.

[WolfgangHG]

After latest rebase, build failed due to the JBoss repository not being available. Had to do a git commit --amend to re-run the failed tests.

[jmesnil]

We discussed this PR during the WildFly Community Call and agreed to move on with a single provisioned server.

• The webapp will provision WildFly and add the deployment
• The Arquillian test will be run against this provisioned server
  • it can test against the actual deployment (with @RunAsClient)
  • it can test against any classes by creating a Deployment with Shrinkwrap

We could replicate what the getting-started archetyp server is doing by having these 2 kind of tests

[WolfgangHG]

@jmesnil So the profiles "arq-managed" and "arq-remote" are removed and replaced by a profile "arq-provisioned" that provisions the server and launches the arquillian tests.
The "getting-started" archetype has no profiles, it always provisions and runs the tests. But I would prefer to have a default profile that just compiles the project without provisioning.

The war file is named "ROOT.war" in "getting-started". Do we follow this approach, or do we keep a deployment name created from the project name?

The arquillian test suite deploys a war file that has a different name, thus it can exist parallel to the "ROOT.war". We could do it the same way here.
But for the ear archetype, Jean-Francois suggested to make two provisioning runs so that two server directories are created. The arquillian deployment can keep the ear name here. Should we do the same here to keep the two archetypes consistent?