Version 17


    This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).


    • Provide a light-weight process with minimal overhead for component owners.
    • Provide an ever-current update site containing the latest, stable releases of integration tooling components.
    • Allow component owners to independently manage their release schedules.
    • Allow component owners to manage their own dependency stack.


    • Components use released versions of dependencies (i.e. stable builds).
    • Component owners manage their own interdependencies with other integration components.
    • Components and dependencies adhere to Eclipse API versioning rules.


    • Aggregate releases will be driven by component releases.
    • Aggregate releases should manage themselves.
    • Component nightly/milestone builds should always be compatible with other components in the aggregate.


    • Integration Stack (IS) - all JBoss middleware integration tooling
    • IS configuration - the definition of specific components and versions that make up the IS
    • IS build - an update site (p2 repo) aggregating specific versions of integration tooling components.
    • Release types:
      • stable - an IS build aggregating stable (i.e. final) builds of all components that has been certified/tested by QA.
      • development - an IS build aggregating stable builds of all components that has not been certified/tested by QA.
      • integration - an IS build aggregating stable, development (e.g. beta) and/or integration builds of all components
      • next - an internal IS build incorporating the latest integration builds of all components (i.e. the current "trunk" build).  This will be used for identifying potential future incompatibilities.


    Stable builds will align  with a JBDS release in the same way JBT core builds do today.  Development builds will reflect the current state of all stable components.  Theoretically, any development build could be QA'd and promoted to stable (assuming no test failures).  Integration builds allow for an "interim" stack which may be useful during a QA cycle (e.g. verifying a fix that requires updates to multiple components; a single component can be updated via the component update site).  Next builds are used to identify potential incompatiblilities among components before they are integrated into a release and would occur weekly/monthly via a Hudson job (e.g. targeting JBT integration builds).


    An IS build only needs to occur when the IS configuration changes.  Because the IS stack is composed of stable components, configuration changes will only occur when individual components are released.  For this reason, it is assumed the build would be invoked manually and there is not reason for a nightly build.

    Roles and Responsibilities

    Component Owners

    1. Component update site:  Component owners must provide an update site for each release of their component that is included in an IS build.
    2. Updating IS configuration:  Component owners must update the IS build configuration when a new version of their component is released.  This ensures the IS is up-to-date.
    3. Respond to change requests:  Component owners must review IS configuration change requests and respond in a timely manner.  If a requested change is incompatible with the current version of your component, provide details regarding when your component will be compatible, along with a patch containing changes to the IS configuration for your compatible release.

    Release Engineers

    1. Maintain build infrastructure:  Release engineers will be responsible for maintianing the build infrastructure, primarily the Jenkins jobs.
    2. Processing pull requests:  Release engineers will be responsible processing all pull requests related to IS configuration.  This is to ensure consistency in the composition of the stack (e.g. components, component versions, IS version, etc.).
    3. Initiate IS builds:  Release engineers will be responsible for initiating IS builds.
    4. Build promotion:  Release engineers will be responsible for the promotion of IS builds (e.g. from development to stable).

    Release Process

    Component Updates

    The following outlines the basic process for updating the IS configuration.  Typically, this would occur when a component is released, but the same process is also used for updating shared dependencies (e.g. JBT core, third-party plugins, etc.).

    1. Create a branch in the user repository for your IS configuration changes.
    2. Modify the Integration Stack configuration for your updates, e.g. update URL for SwitchYard from 0.5.0.Final to 0.6.0.Final; update IS version from 0.9.0 to 0.9.1 (see versioning rules)
      1. For changes to your component you must update the community aggregate:
        1. Modify the compositeArtifacts.xml and compositeContent.xml files to point to the new component update site.
        2. Modify the category.xml file as necessary for any feature changes (e.g. adding a feature).
        3. Modify the project version in pom.xml.
      2. For changes to your component within the production aggregate:

                          * Note: The production component update sites will be drawn from the community composite files.

        1. Modify the category.xml file as necessary for any feature changes (e.g. adding a feature).
        2. Modify the project version in pom.xml.
      1. For changes to dependencies:
        1. Modify, or

          The integration-stack-base and core-base combine to include all dependencies which are included as part of JBDS.  See the generated in your repository.  The community target extends the base target by including dependencies which are only available in community JBT releases (

                             e.g. I need to update to graphiti 0.9.2:

          1. fork/branch/modify
          2. update the version of graphiti
          3. verify that the updated version is being mirrored correctly on
        1. Modify project version in pom.xml

        2. Ensure plugins are mirrored on


    1. Build locally to validate stack dependencies.
    2. Create a JBTIS JIRA task requesting update, e.g. update SwitchYard to 0.6.0.Final
      • Include link to github branch in task
      • Include build  results (e.g. SUCCESS or specific dependency resolution errors)
    3. Create subtasks against each IS component for verification/approval
      • For components that failed the consistency check, mark subtasks appropriately, e.g. m2e-wtp version is inconsistent
    4. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
    5. Build IS locally to validate dependency consistency
    6. Issue pull request against upstream IS configuration project
    7. Process pull (by release engineer)
    8. Invoke build job (by release engineer)

    Platform Updates

    Goal: release updated IS within four weeks of JBT/JBDS core release.

    1. Initiate platform update during JBT beta phase
    2. Follow the component update process above (e.g. update JBT core from 3.3 to 4.0)

    JBoss Central Discovery Updates

    Goal: Modify the JBoss Central mylyn discovery install/update mechanism.

    JBoss Central, based on Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provides a richer, yet simpler UI than what the Eclipse equinox p2 install manager provides out of the box.

    For detailed information see


    1. For changes to the jbosstools community discovery update: or production discovery update: follow the same git process as defined in the Components Updates section.
    2. Modify the plugin connector descriptors and installation units as needed within the discovery plugin.
    3. Add any icons that may be required.

    Dependency Updates

    The process for updating a shared dependency is the same as that for updating any other component, with the following additions:

    1. Make sure the dependency is mirrored on
    2. Make sure the dependency is not already included through JBT core.

    If a dependency is included through JBT core, you will need to coordinate with the core team on the upgrade, as the change may impact components outside the IS.

    Versioning Rules -

    Major should be updated for:

    • Base platform changes, e.g. Eclipse Indigo->Juno, JBT 3.3->4.0
    • Major component updates, e.g. SwitchYard 1.0->2.0

    Minor should be updated for minor component updates, e.g. SwitchYard 0.5->0.6

    Update should be updated for minor component updates, e.g. SwitchYard 0.5.0->0.5.1

    Build should be updated for each build, e.g. when building against nightly/integration/development repositories


    ** Note, the basic assumption here is that components are adhering to basic API rules (per Eclipse; e.g. minor includes bug fixes and api additions, major may include breaking api changes).

    Update Site Locations


    Target Platforms

    The provided target platforms define all upstream dependencies available to an IS component.  Three target platforms are provided:, and (see Component Updates above).   If your component needs to be included in a JBDS release, DO NOT use the community target platform.  For more information and an example on how to refer to the target platform definition, see:

    Future Plans

    1. Add support for executing component unit tests as part of the aggregate build.  The goal being to help ensure the stability of the aggregate.

    Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 4.1).  This should serve as an early warning system to identify platform incompatibilities early in the process