Single-VM Packaging

Fabric3 supports two basic models for deploying to a single-VM environment: single contribution deployment and multi-contribution deployment.

Single Contribution Deployment

Single contribution deployment bundles all application services in a single contribution archive as depicted in the diagram below: 

The primary advantage of this approach is simplicity: only a single archive needs to be delivered and deployed. The main drawback of a single contribution is lack of modularity. A single archive bundles all artifacts such as Java classes together. Classes bundled together cannot be individually versioned. Moreover, visibility of implementation classes cannot be restricted using technologies such as OSGi import/export directives (see Modularity for how Fabric3 supports OSGi). For basic applications, the single contribution model may be a reasonable trade-off for the simplicity it offers.

Multi-Contribution Deployment 

Multi-contribution deployment involves separating application services into two or more contribution archives:    

The main advantage of this approach is modularity: contributions can be broken down by functional subsystem allowing them to be versioned and evolved independently. In addition, multiple contributions can promote looser coupling between services as implementation classes can be separated into distinct modules. The downside of multi-contribution deployment is increased complexity; deployers need to manage multiple artifacts.

Single-VM Packaging Best Practice

For all but the most trivial applications, multi-contribution deployment is the recommended approach as the benefits of modularity far outweigh added complexity. This model aligns well with Gradle and Maven (as well as other build systems) multi-module approach to application development. In order to make multi-contribution deployment easier, we have also developed a system of application deployment that relies on automated assembly of custom runtime images. For details, see Service Delivery.