Update subsystem archetype to use wildfly-subsystem.

[pferraro]

No description provided.

[jamezp]

This looks reasonable to me.

[WolfgangHG]

The internal testing script will probably not work as expected (though it does not lead to a failing test): it creates a project from the archetype, applies a patch to add a "System.out.println", then builds and deploys the subsystem.
The output is merely meant for the person running the script to verify that the subsystem is acually loaded.

The line https://github.com/wildfly/wildfly-archetypes/blob/main/wildfly-subsystem-archetype/testing/runtest.sh#L61 applies a patch file https://github.com/wildfly/wildfly-archetypes/blob/main/wildfly-subsystem-archetype/testing/debugging_output.patch that adds the output.

@pferraro Could you restore this feature?

Edit: the failing line for this "patch" operation in the CI build is: https://github.com/wildfly/wildfly-archetypes/actions/runs/18468673006/job/52616879736?pr=182#step:9:62

[WolfgangHG]

And CI build fails when executing "runtest.sh" in the step of registering the subsystem: https://github.com/wildfly/wildfly-archetypes/actions/runs/18468673006/job/52616879736?pr=182#step:9:241

Configuring subsystem...
This might cause errors if a previous test run did not cleanup and e.g. the subsystem already exists.
The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): 
WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
Step: step-2
Operation: /subsystem=mysubsystem:add
Failure: WFLYCTL0155: 'bar' may not be null

Subsystem was registered - check WildFly console for error messages

The script file executes this CLI file: https://github.com/wildfly/wildfly-archetypes/blob/main/wildfly-subsystem-archetype/testing/configure.cli

[jmesnil]

During the WildFly Community Call we discussed this PR and evolving it to create a feature pack that would provision the example subsystem.

It would have an impact on the subsystem testing (it would simplify it by making sure that the server provisioned with that feature pack would successfully start WildFly with the extension).

@pferraro Do you mind if I take your PR to start working on this feature pack improvement?

[pferraro]

@pferraro Do you mind if I take your PR to start working on this feature pack improvement?

Sounds good.

[jmesnil]

With the changes in this PR, the subsystem generated by the archetype does not work (it requires an hypothetical Bar interface that is not provided by anything).

This archetype should generate a functional subsystem that:

1. works out of the box
2. should have a demonstrable feature (ie being able to be tested when provisioned with WildFly)
3. is simple enough that the developers could tweak it to their purposes without too much initial changes.

What do you think how using the example in our doc at https://docs.wildfly.org/38/Extending_WildFly.html#Example_subsystem as the subsystem?
We could make it even better by requiring a ManagedExecutorService through a capability to let users know how they can access WildFly services

[jmesnil]

superseded by #194