Since JBoss Tools 4.3.0 we require Java 8 for the installation and use of all JBoss Tools, including the Integration Stack tooling. We still support developing and running applications using older Java runtimes. See more in Beta1 blog.

Note: All of the Integration Stack components are Early Access. See the installation section below for instructions.

What’s an Integration Stack?

The Integration Stack for JBoss Developer Studio is a set of features and plugins for Eclipse that further enhances the IDE development functionality provided by JBoss Developer Studio in support of the following frameworks:

JBoss Fuse Development

Fuse Tooling - JBoss Fuse Development provides tooling for Red Hat JBoss Fuse, specifically for integrating and developing software components that work with Apache ServiceMix, ActiveMQ and Camel. It features the latest versions of the Fuse Data Transformation tooling, SwitchYard and access to the Fuse SAP Tool Suite.

SwitchYard - A lightweight service delivery framework providing full lifecycle support for developing, deploying, and managing service-oriented applications.

JBoss Data Virtualization Development

JBoss Data Virtualization Development plug-ins provide a graphical interface to manage various aspects of Red Hat JBoss Data Virtualization instances, including the ability to design virtual databases and interact with associated governance repositories.

Modeshape - A distributed, hierarchical, transactional and consistent data store with support for queries, full-text search, events, versioning, references, and flexible and dynamic schemas. It is very fast, highly available, extremely scalable, and it is 100% open source.

All of these components have been verified to work with the same dependencies as JBoss Tools 4.3 and Developer Studio 9.

What’s Been Updated for Mars?

Almost everything! Updates have been made to the Business Process tooling, Fuse Tooling, Data Virtualization and SOA Development tooling product groups. See the Integration Stack 9.0.0.Beta1 Release Notes for more details.

Drools/jBPM6 Highlights

Data Virtualization Highlights

Teiid Designer Highlights

The JBoss Tools website features tab

Don’t miss the Features tab for up to date information on your favorite Integration Stack components.

Installation

The easiest way to install the Integration Stack components is to first install JBoss Tools 4.3.1 or JBoss Developer Studio 9.1.0 and then select the Software/Update tab in the JBoss Central view. Select the 'Enable Early Access' checkbox.

A couple weeks ago, I started prototyping how we could enable building PRs submitted against the JBoss Tools projects, in order to more easily create installable update sites (Eclipse p2 repositories) from pull requests. This is part of our new thrust to provide more continuous integration and deployment, to better be able to release software faster.

Purpose

Verify a commit before pushing it to master. Continuous feedback. Easier installation testing. Ability to share a proposed change, including the whole built update site so peer reviews can be done against binaries as well as sources.

Job Steps & Deployment

One way to react to a successful build of a PR is to simply deploy to a different URL than normal builds.

For example, a job could be set up such that if ${ghprbPullId} is defined, a deploy-pr profile is used; if not, the usual deploy-to-jboss.org profile could instead be used.

mvn deploy -Pdeploy-pr

However, we might also want a different sequence of build steps in a job. Normally, we orchestrate jobs to build, deploy, & test. But for a PR build, we might instead want to sequence the steps as build+test, and only deploy if successful.

So perhaps instead of parameterizing the job to publish to snapshots/pulls/ or snapshots/builds/, we might instead parameterize the maven lifecycle steps:

Questions / TODOs

Can whitelists be set up programmatically? (git committerIDs which can trigger a build automatically)

Can admins be set up programmatically? (git committerIDs which can approve a PR to be built, rather than ANY submitted PR, to prevent malicious attacks)

How do we roll up a low-level project’s pull request build into a larger stack of projects or products? Do we rebuild everything that’s downstream? Or just the aggregates/product?

How aggressively should we purge pull request builds?

When running matrix jobs, what happens when one part of the job is running, another is waiting, and a force-push updated to a PR arrives? (Answer: the waiting configurations will fail because the expected SHA no longer exists, having been force-replaced.)