Edit: NOTE: What I say below about 'org.jboss.as.webservices.server.integration' being added as a deployment dependency is incorrect! But my incorrect thesis is leading Jim to review how this module is used, where there may be other subtler effects related to the general point of all the dependencies this module exposes. A good thing is the concern I had about no longer exposing APIs that deployments may have depended on is less of a concern since we're not adding this module as a deployment dep.

The org.jboss.as.webservices.server.integration module exports a lot of its dependencies. The module itself is added as a deployment dependency, so the effect is quite a lot of modules are exposed to the deployment via org.jboss.as.webservices.server.integration.

We recently had a customer issue where they were packaging Bouncycastle and ran into issues because it was conflicting with our internal Bouncycastle. They were wondering why we were exposing private modules to the deployment. AFAICT it must have been via org.jboss.as.webservices.server.integration.

I am not proposing that we change anything, just that we do a review and see if there are possible improvements. For example, if we are exporting things really for our own internal consumption, see if there are other ways to achieve the same effect.

We need to be careful because if we stop exporting something and users were relying on what we exported, that could be a breaking change. Note that these are private modules though; we are allowed to change what they do. But still, we should not do so lightly. OTOH, if we decide to continue to expose a private module for compatibility reasons, we may be able do it directly, not via org.jboss.as.webservices.server.integration, which would then allow users to exclude the module via jboss-deployment-structure.xml.

Note that there are definitely cases where we need to expose private modules to deployments. It's not somehow something forbidden. It's just something to be avoided if not absolutely necessary.