Maven Dependencies Real Problem

[ropalka]

Relates to: JBWS-2376

Current Solution:

JBossWS allows to deploy multiple SOAP stacks (Metro, CXF and Native) to multiple JBossAS servers (4.2.x and 5.0.x).
To easily integrate different SOAP stacks with different AS versions we have a deploy magic implemented in each stack. This deployment magic consists of two steps:
* deploy-artifacts directory creation (containing jar files and other artifacts that will be deployed)
* deploy procedure using the artifacts created in previous step that integrates SOAP stack to particular AS
We also reuse this integration magic in AS code base:
* where step 1 is omited there because deploy-artifacts directory is AS/thirdparty directory in such case
* step 2 is slightly modified to don't deploy container integrations jars (these are created in JBossAS webservices module build process)

Identified problem:

We have to emulate AS/thirdparty directory structure to have full control of the jars that will get deployed to AS (because of reused macro).
AS/thirdparty dir is created by maven-buildmagic-thirdparty-plugin that copies all dependencies to thirdparty dir. This leads to multiple artifacts with the same name present in different directories (e.g. jaxb-api.jar).
Thus our deployment macro is error prone because:
* we need to watch for changes in AS/thirdparty/pom.xml and any new mappings introduced there must be applied to all three stacks deploy macros (because we have to emulate AS thirdparty directory structure)
* deployment macro have to use groupId/artifactId includes instead of wildcars **/artifactId (to match particular artifact and to allow us to have the control over the jars that will get really deployed)

Questions:

How to do it properly? Any opinions or suggestions?

[ropalka]

We're reusing deployment macros because of:
* easily integration
* native stack integration changes gets to the AS without need for review and patching the different build process (if such would be introduced)

[ropalka]

To don't it be such an easy problem many of JBossWS deployed jars are overwritten by JBossAS build distribution process. Hence we really have no control over the files that will get to the AS once we're integrated to the AS :(

[starksm64]

The first thing I would suggest is that the webservices integration layer not be trying to do the install of its dependencies. If it does not fully contain the dependency, the dependency has to be installed by the layer that is bringing webservices into itself.

If there are dependencies that do need to be installed into the webservices deployment, the wildcard patterns need to be replaced with integration target specific properties files that can be set to the correct location of each dependency reference by the project that is integrating webservices.

[ropalka]

Thanks for opinions Scott.
From my understanding of the problem reusing the deployment macro isn't nice idea because it's magic and we don't have the control over the integration process with the AS now. I'm thinking about removing the JBossWS deployment macro call from AS build process and reuse the JBossAS build distribution logic instead.

[starksm64]

Yes, that is the only thing I can see working in general. You need to declare your dependencies and whatever project is integrating the webservices deployments has to install these.

[ropalka]

Yes, we decided to go this way because it's the least error prone approach for our integration.

[ropalka]

Cross reference: JBAS-6195