Re: [jboss-dev-forums] [JBoss Tools Development] - Integration Tooling Release Process
by Max Rydahl Andersen
Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] commented on the document
"Integration Tooling Release Process"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48326#comment-11577
--------------------------------------------------
I fixed the Kepler/JBT 5 to Kepler/JBT 4.1.
About major version bump then I just want to point out Indigo->Juno is Eclipse 3.3 to 4.2, where as Juno->Kepler is 4.2 to 4.3 so its two different kind of jumps.
In JBT we bumped major version of JBoss tools because Eclipse bumped major versions and changed hard.
--------------------------------------------------
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Max Rydahl Andersen
Max Rydahl Andersen [https://community.jboss.org/people/maxandersen] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 within the aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. JBoss Central Discovery Updates
*Goal:* Modify the JBoss Central mylyn discovery install/update mechanism.
JBoss Central, based on http://wiki.eclipse.org/Mylyn/Discovery Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provides a richer, yet simpler UI than what Eclipse's p2 Install Manager provides out of the box.
For detailed information see https://community.jboss.org/docs/DOC-48297 https://community.jboss.org/wiki/JBossCentralsSoftwareUpdateTab-HowDoesIt...
1. For changes to the discovery update: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/di...
2. Follow the same git process as defined in the Components Updates section.
3. Modify the discovery connector descriptors and installation units as needed within the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/di... discovery plugin.
4. Add any icons that may be required.
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * *target platform* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* *aggregate* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* *aggregate publish/promote* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* *discovery* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* *install tests* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. 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.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 within the aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. JBoss Central Discovery Updates
*Goal:* Modify the JBoss Central mylyn discovery install/update mechanism.
JBoss Central, based on http://wiki.eclipse.org/Mylyn/Discovery Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provides a richer, yet simpler UI than what Eclipse's p2 Install Manager provides out of the box.
For detailed information see https://community.jboss.org/docs/DOC-48297 https://community.jboss.org/wiki/JBossCentralsSoftwareUpdateTab-HowDoesIt...
1. For changes to the discovery update: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/di...
2. Follow the same git process as defined in the Components Updates section.
3. Modify the discovery connector descriptors and installation units as needed within the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/di... discovery plugin.
4. Add any icons that may be required.
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * *target platform* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* *aggregate* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* *aggregate publish/promote* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* *discovery* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* *install tests* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 5). This should serve as an early warning system to identify platform incompatibilities early in the process.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 within the aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. JBoss Central Discovery Updates
*Goal:* Modify the JBoss Central mylyn discovery install/update mechanism.
JBoss Central, based on http://wiki.eclipse.org/Mylyn/Discovery Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provider a richer, yet simpler UI than what Eclipse's p2 Install Manager provides out of the box.
For detailed information see https://community.jboss.org/docs/DOC-48297 https://community.jboss.org/wiki/JBossCentralsSoftwareUpdateTab-HowDoesIt...
1. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/di...
2. Follow the same git process as defined in the Components Updates section.
3. Modify the discovery connectors as needed within the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/di... discovery plugin.
4. Add any icons that may be required.
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * *target platform* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* *aggregate* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* *aggregate publish/promote* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* *discovery* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* *install tests* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 5). This should serve as an early warning system to identify platform incompatibilities early in the process.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Multiple instances of JBoss AS7 on the same machine
by Marc Gagnon
Marc Gagnon [https://community.jboss.org/people/MarcGagnonPincourt] commented on the document
"Multiple instances of JBoss AS7 on the same machine"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-16705#comment-11574
--------------------------------------------------
You might want to look at our solution: https://community.jboss.org/docs/DOC-48321 https://community.jboss.org/wiki/HowToDefineMultipleJboss7ServerInstances...
--------------------------------------------------
12 years, 1 month
- 1
- 0
[JBoss AS 7 Development] - JBoss AS7 Securing Passwords
by Peter Skopek
Peter Skopek [https://community.jboss.org/people/pskopek] modified the document:
"JBoss AS7 Securing Passwords"
To view the document, visit: https://community.jboss.org/docs/DOC-17248
--------------------------------------------------------------
This article will describe the capabilities available in JBoss AS7.1 with regard to securing sensitive attributes such as passwords.
h2. Disclaimer:
The default implementation described in this article only solves the problem of masking clear text passwords. There is always a weak link (in this case, the keystore password).
For windows platform, refer to https://community.jboss.org/docs/DOC-17763 https://community.jboss.org/wiki/AS7PasswordVaultOnWindows
**
#Disclaimer Disclaimer:
**
#What_is_needed What is needed?
**
#Process Process
***
#Step_1_Create_a_Java_KeyStore Step 1: Create a Java KeyStore
***
#Step_2_Use_the_Vault_Tool_scripts_to_store_a_password_in_the_vault Step 2: Use the Vault Tool scripts to store a password in the vault
***
#Step_3_Configure_the_attributes_in_your_xml_such_as_standalonexml_and_hostxml Step 3: Configure the attributes in your xml such as standalone.xml and host.xml
**
#Guidance_for_subsystems_seeking_passwords_in_AS7 Guidance for subsystems seeking passwords in AS7
**
#Frequently_Asked_Questions Frequently Asked Questions:
*****
#How_secure_is_this How secure is this?
*****
#Can_I_really_secure_the_keystore Can I really secure the keystore?
*****
#How_do_I_get_foolproof_security_for_passwords How do I get foolproof security for passwords?
*****
#I_lost_the_vault_formatted_string_for_my_attribute I lost the vault formatted string for my attribute?
*****
#Can_I_do_all_this_from_the_UI Can I do all this from the UI?
*****
#Show_me_how_to_do_this_on_Windows Show me how to do this on Windows.
*****
#Please_give_me_an_example Please give me an example.
h2. What is needed?
1. Java KeyStore.
2. Scripts provided in the bin directory of JBoss AS 7 .1 (vault.sh etc)
h2.
h2. Process
h3.
h3. Step 1: Create a Java KeyStore
$ keytool -genkey -alias vault -keyalg RSA -keysize 1024 -keystore vault.keystore
Enter keystore password: vault22
Re-enter new password:vault22
What is your first and last name?
[Unknown]: Picketbox vault
What is the name of your organizational unit?
[Unknown]: picketbox
What is the name of your organization?
[Unknown]: JBoss
What is the name of your City or Locality?
[Unknown]: chicago
What is the name of your State or Province?
[Unknown]: il
What is the two-letter country code for this unit?
[Unknown]: us
Is CN=Picketbox vault, OU=picketbox, O=JBoss, L=chicago, ST=il, C=us correct?
[no]: yes
Enter key password for <vault>
(RETURN if same as keystore password):
It is important to keep track of the keystore password and the alias. In this example, the keystore password is "vault22" and the alias is "vault".
If one preferes just one command here is equivalent:
keytool -genkey -alias vault -keystore vault.keystore -keyalg RSA -keysize 1024 -storepass vault22 -keypass vault22 -dname "CN=Picketbox vault,OU=picketbox,O=JBoss,L=chicago,ST=il,C=us"
h3. Step 2: Use the Vault Tool scripts to store a password in the vault
/bin/util$ ./vault.sh
=========================================================================
JBoss Vault
JBOSS_HOME: /home/anil/as7/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT
JAVA: /opt/java/jdk1.6.0_23/bin/java
VAULT Classpath: /home/anil/as7/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT/modules/org/picketbox/main/*:/home/anil/as7/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT/modules/org/jboss/logging/main/*:/home/anil/as7/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT/modules/org/jboss/common-core/main/*:/home/anil/as7/jboss-as/build/target/jboss-as-7.1.0.Alpha2-SNAPSHOT/modules/org/jboss/as/security/main/*
=========================================================================
**********************************
**** JBoss Vault ********
**********************************
Please enter a Digit:: 0: Start Interactive Session 1: Remove Interactive Session 2: Exit
0
Starting an interactive session
Enter directory to store encrypted files (end with either / or \ based on Unix or Windows:/home/anil/vault/
Enter Keystore URL:/home/anil/vault/vault.keystore
Enter Keystore password:
Enter Keystore password again:
Values match
Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):50
Please make note of the following:
********************************************
Masked Password:MASK-5WNXs8oEbrs
salt:12345678
Iteration Count:50
********************************************
Enter Keystore Alias:vault
Sep 28, 2011 11:48:39 AM org.jboss.security.vault.SecurityVaultFactory get
INFO: Getting Security Vault with implementation of org.picketbox.plugins.vault.PicketBoxSecurityVault
Obtained Vault
Intializing Vault
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit
0
Task: Store a password
Please enter attribute value:
Please enter attribute value again:
Values match
Enter Vault Block:ds_ExampleDS
Enter Attribute Name:password
Attribute Value for (ds_ExampleDS, password) saved
Please make note of the following:
********************************************
Vault Block:ds_ExampleDS
Attribute Name:password
Shared Key:N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
Configuration should be done as follows:
VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0
********************************************
Please enter a Digit:: 0: Store a password 1: Check whether password exists 2: Exit
2
Scriptable (non-interactive) command to create vault (available from AS 7.2 on):
./vault.sh -k vault.keystore -p vault22 -e /home/anil/vault -i 50 -s 12345678 -v vault -b ds_ExampleDS -a password -x sa
for more information use ./vault.sh --help
h3. Step 3: Configure the attributes in your xml such as standalone.xml and host.xml
h3.
<server xmlns="urn:jboss:domain:1.1">
<extensions>
...
</extensions>
<vault>
<vault-option name="KEYSTORE_URL" value="/home/anil/vault/vault.keystore"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-3y28rCZlcKR"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="12438567"/>
<vault-option name="ITERATION_COUNT" value="50"/>
<vault-option name="ENC_FILE_DIR" value="${user.home}/vault/"/>
</vault>
...
<subsystem xmlns="urn:jboss:domain:datasources:1.0">
<datasources>
<datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
<connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
<driver>h2</driver>
<pool></pool>
<security>
<user-name>sa</user-name>
<password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
</datasource>
<drivers>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
</datasources>
</subsystem>
Note previously, the datasource password would have been:
<security>
<user-name>sa</user-name>
<password>sa</password>
</security>
h2.
h2. Guidance for subsystems seeking passwords in AS7
The server module in JBoss AS7 workspace has a class called as VaultUtil which has methods for you to seamlessly pass the vault formatted string to get the password from the vault.
I am posting the integration done in org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService
Note that do not seek the password from the vault during the xml parsing phase because the vault has not been initialized and ready. It has to be done in the services phase when you actually do something with the configured elements of your subsystem.
In the case of JCA datasource integration, we do it in AbstractDataSourceService
import org.jboss.as.server.services.security.VaultUtil;
import org.jboss.security.vault.SecurityVaultException;
final DsSecurity security = dataSourceConfig.getSecurity();
if (security != null) {
if (security.getUserName() != null) {
managedConnectionFactory.setUserName(security.getUserName());
}
if (security.getPassword() != null) {
String password = security.getPassword();
if (VaultUtil.isVaultFormat(password)) {
try {
password = VaultUtil.getValueAsString(password);
} catch (SecurityVaultException e) {
throw new RuntimeException(e); // TODO: use bundle from IJ
}
}
managedConnectionFactory.setPassword(password);
}
}
We do not want to make the configuration of the vault formatted string to be very difficult. As long as the formatted string is prefixed with VAULT::, the vault will be invoked. Custom implementations of the vault should consider the last token for any configuration.
If you are using the AttributeDefinition classes the vaulted expression will be automatically resolved when calling AttributeDefiniton.resolveModelAttribute(). If you are not using AttributeDefinition you need to call OperationContext.resolveExpression() yourself as this example from DataSourceModelNodeUtil
> ...
> *final* String password = +getResolvedStringIfSetOrGetDefault+(operationContext, dataSourceNode, +PASSWORD+, *null*);
> ...
>
> *private* *static* String getResolvedStringIfSetOrGetDefault(*final* OperationContext context, *final* ModelNode dataSourceNode, *final* SimpleAttributeDefinition key, *final* String defaultValue) {
> *if* (dataSourceNode.hasDefined(key.getName())) {
> *return* context.resolveExpressions(dataSourceNode.get(key.getName())).asString();
> } *else* {
> *return* defaultValue;
> }
> }
>
h2.
h2. Frequently Asked Questions:
* h5. How secure is this?
* The default implementation of the vault utlizes a Java KeyStore. Its configuration uses Password Based Encryption, which is security by obscurity. This is not 100% security. It only gets away from the problem of clear text passwords in configuration files. There is always a weak link. (+*As mentallurg suggests in the comments, the keystore password is the weakest link*+).
* Ideally, 3rd party ISV robust implementations of Vaults should provide the necessary security.
* h5. Can I really secure the keystore?
* You can store the keystore on an USB or an encrypted secure usb or such.
* When the server starts, insert the USB. On successful start, you can remove the USB.
* Ideally, use a FIPS 140-2 certified keystore from a keystore vendor if you want foolproof security.
* h5. How do I get foolproof security for passwords?
* The default implementation of Vault in JBossAS7 is not 100% secure.
* You can increase level of security by adopting a FIPS 140-2 certified keystore.
* You can use 3rd party implementations of the Vault (this is something we are pushing for ISVs to do).
* h5. I lost the vault formatted string for my attribute?
* Just reinsert the attribute value in the vault to overrwrite what was previously stored. You will get a new formatted string to insert in the xml.
* h5. Can I do all this from the UI?
* Hopefully with time, we can get this integrated into the console.
* h5. *Show me how to do this on Windows.*
* https://community.jboss.org/docs/DOC-17763 https://community.jboss.org/wiki/AS7PasswordVaultOnWindows
* h5. Please give me an example.
* https://community.jboss.org/docs/DOC-17472 https://community.jboss.org/wiki/AS7UtilisingMaskedPasswordsViaTheVault
* https://community.jboss.org/docs/DOC-17503 https://community.jboss.org/docs/DOC-17503
* *What if my vault expression in AS7 configuration file (e.g. standalone.xml) didn't get resolved?** Vault expressions cannot be used everywhere. Only in attributes or elements marked as "allowedExpressions".
Then both "VAULT:: ..." and "${VAULT:: ...}" are fine. In some cases (XML attribute value) only "${VAULT: ...}" form is resolved.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17248]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 within the aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * target platform - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* aggregate - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* aggregate publish/promote - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* discovery - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* install tests - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 5). This should serve as an early warning system to identify platform incompatibilities early in the process.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
Community Updates, February 7 - February 14
by JBoss Community
===============================================================
Community Updates for February 7 - February 14
===============================================================
Your Content
* testing the new list server [https://community.jboss.org/thread/127309]
was viewed 13,200 times and replied to by 3 people
* No Link to Jboss Nukes [https://community.jboss.org/thread/90785]
was viewed 111,515 times and replied to by 3 people
Your Connections - Activity by people you are following
You don't have any connections yet. Find people and connect! [https://community.jboss.org/people/]
Popular Content - The content that is most viewed and participated in
* Open Session in View [https://community.jboss.org/docs/DOC-13954]
* Data Source Configuration in AS 7 [https://community.jboss.org/docs/DOC-16657]
* Sessions and transactions [https://community.jboss.org/docs/DOC-13951]
* how I set up a PostgreSQL JDBC Driver on JBoss 7 [https://community.jboss.org/blogs/amartin-blog/2012/02/08/how-to-set-up-a...]
* JBoss Tools 4 and Developer Studio 6 is ready! [https://community.jboss.org/community/tools/blog/2012/12/10/jboss-tools-4...]
* Statement Regarding Security Threat to JBoss Application Server [https://community.jboss.org/blogs/mjc/2011/10/20/statement-regarding-secu...]
* Re: Jboss 7.1.2.Final is only for EAP? [https://community.jboss.org/message/796576#796576]
* Re: java.net.BindException: Address already in use: JVM_Bind [https://community.jboss.org/message/795418#795418]
* Re: HTTPS on JBoss AS 7 - truststore configuration [https://community.jboss.org/message/746287#746287]
Tips and tricks - Personalize your Homepage
You can personalize the Community home page so that it shows the things you care about most. As you and others use Community, the amount of activity there will grow. You'll develop a preference for certain people's blogs, for discussions in certain areas, and you'll learn that some areas just rarely have something you need. When personalizing your view, you use widgets, which are windows on content either inside and outside of Community.
Personalize your page now or find out more.
Not interested in these emails anymore, or want to change how often they come? Update your email preferences by visiting: https://community.jboss.org/user-notification-preferences!input.jspa
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 within the aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ag.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *Jenkins* -
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 5). This should serve as an early warning system to identify platform incompatibilities early in the process.
3.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* 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.
h2. Assumptions
* 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.
h2. Implications
* 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.
h2. Definitions
* *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.
h1. Roles and Responsibilities
h2. 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.
h2. 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).
h1. Release Process
h2. 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 branch in user repository for IS configuration changes.
2. Update IS configuration for 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. Modify the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... compositeArtifacts.xml and compositeContent.xml files (in aggregate-site) to point to the new update site.
2. Modify the category.xml file (in aggregate-site) as necessary for any feature changes (e.g. adding a feature).
3. Modify project version (pom.xml in aggregate-site).
4. For changes to dependencies:1. Modify base.target or community.target (in target-platform)
2. Modify project version (pom.xml in target-platform)
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create 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)
5. 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
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. 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)
h2. 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 jboss.org.
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.
h2. Versioning Rules - major.minor.update.build
*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).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *Jenkins* -
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform.
h1. 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.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 5). This should serve as an early warning system to identify platform incompatibilities early in the process.
3.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
12 years, 1 month
- 1
- 0