7 Replies Latest reply on Nov 13, 2008 10:48 AM by Richard Opalka

    Maven Dependencies Real Problem

    Richard Opalka Master

      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?