Add stork module for LRA (required for JBTM-3987)

[mmusgrov]

This change is required for running the MP-LRA testsuite (https://issues.redhat.com/browse/JBTM-3987 added a dependency on SmallRye Stork). It is required for jbosstm/lra#50

[marcosgopen]

Good PR, it is good that it is open here in our repo in order to test the LRA PR, but we need to remember we will need to create a WLFY issue for this and open a PR for wildfly too

[mmusgrov]

The wildfly issue should be the upgrade.

[mmusgrov]

@marcosgopen We'll need to change this to a released version before merging our WildFly clone. And the released version won't work with WildFly until the WildFly MP LRA testsuite has been updated.

[marcosgopen]

Please consider keeping this PR open and never merge it here. I would usually prefer to have it merged in wildfly main and then pull that change into our jboss-as repo.
+1 to change the version to a released one for the WildFly PR

[tomjenkinson]

Just to mention we can't keep the SNAPSHOT version in the main branch of our WildFly fork because it causes the Narayana build to fail (https://github.com/tomjenkinson/narayana/actions/runs/15850027491/job/44680987225). I will raise a pull request to set this back to 1.0.1.Final for now

[tomjenkinson]

I have raised #98 - I hope it won't cause a problem to the rest of the changes here because the LRA changes proposed here related to stork module don't seem to necessarily (except for the functionality itself!) need a Narayana LRA version change for the stork module to be added

[marcosgopen]

The wildfly issue should be the upgrade.

I am not sure, I think having only one issue (e.g. upgrading LRA and apply these changes) is feasible but since I think these changes are not 'strictly dependent' to the LRA upgrade I would slightly prefer to have 2 issues:

• one with the changes to include stork ( and merge the related PR first)
• one with the LRA upgrade (which must depend on the first one!) which can be opened when a new version of LRA is released
  The benefit of this would be to keep track of the 2 changes (stork and lra upgrade) and better specify (with Jira links) how they are related.

WDYT?

p.s. please consider this message as a suggestion only (based on my previous experiences), one issue is also fine.

[mmusgrov]

OK I'll create a WildFly issue for adding the stork module, hopefully nobody will complain about it not being used so we'd need to follow up quite quickly with a WildFly component upgrade. If the WildFly team does object then they may have a suggestion about how we can work around the problem.

[mmusgrov]

Of course if we add the stork module first then since it won't be used until the upgrade there won't be any test to validate it.

[tomjenkinson]

Can Stork be added to WildFly only for use by LRA? Adding a new feature like Stork to WildFly for general purpose use will imply that it would be maintained by someone for general usage. Can the use of Stork be narrowed to a scenario that we (Narayana LRA team) are willing to support?

[mmusgrov]

The module is marked private so anyone other than the MP-LRA subsystem that uses it should not expect us to provide support.

[tomjenkinson]

On that's good and hopefully that is enough protection against using it in a non-supported manner (though I am not sure of the expectations for WildFly - it would be important to be explicit about that in whatever documentation is expected from WildFly when proposing the new functionality). I would imagine it will still imply people from the Narayana LRA team being prepared to be listed for maintaining it (such as for CVEs) at least from a subject matter expert point of view in case of assistance required.

[mmusgrov]

But MP-LRA will/is supported so any usage of any private module by the LRA subsystem comes with support guarantees.