Follow-up: Migrate Wildfly connectivity to use jboss-modules

[asbachb]

Description

We're currently use jboss-cli-client.jar in order to get connectivity to Wildfly remote admin. This jar is a kind of uber jar containing all kind of unnecessary classes to fulfill this connectivity.

In the PR introducing the dependency to jboss-cli-client.jar it was supposed to integrate jboss-modules in order to pull only jar files which are necessary.

see #6138 for more details on that discussion

Use case/motivation

No response

Related issues

No response

Are you willing to submit a pull request?

No

[ehsavoie]

I'm wondering if the simplest solution would be to provide the jar from wildfly-core that we need since those are ASL 2.0. That would be the easiest way as they should be retro-compatible and WildFly team ensure the forward compatibility. We would also be able to get rid of the current reflection code.
Be aware that with the current galleon provisioning of WildFly the jboss-client might not be there anymore too.

[ehsavoie]

@asbachb @mbien WDYT ?

[asbachb]

Actually I'm not 100% sure what consequences are when providing (you mean the module should ship it as dependency?). I don't like the reflection code either. I guess the new solution should be easy to understand and to maintain. Ideally we don't need to touch the code for new releases.
I guess nobody want a solution back where somebody needs to handpick some random jars which needs to be different for different versions.

[ehsavoie]

Yes I mean to add the required jars as dependencies. I know that they used to do it that way in jboss-tools and in the wildfly-maven-plugin. I know that WildFly team is extra carefull to be retro-compatible.