Packaging examples

Automating the packaging process allows to setup continuous integration on the Nuxeo Package build, its install and the features it provides.

There are multiple ways to build a Nuxeo Package. Focusing on those using the Ant Assembly Maven Plugin, you can find below the three different methods depending on the constraints and objectives, from the better to the quicker method:

NXR Method
No-NXR Method
Explicit Method

See Nuxeo Marketplace Sample for downloading a project with sample architectures, implementing the three below build methods plus the required modules for testing those Nuxeo Packages with Selenium, WebDriver and Gatling.

Applied to the sample project, here are the results from those three methods. Look at the differences in the content, size and build time. The network bandwidth is not evaluated but it also varies respectively from the most to the less, proportionally to the build time.

NXR Method - Recommended

The recommended method is to build an NXR corresponding to the wanted result after the package install. Then we operate a comparison between that product and a reference one (usually the Nuxeo CAP), and we finally generate the Nuxeo Package which will perform the wanted install.

PROS	CONS
Always up-to-date in regards to the dependencies and requirements (other bundles and third-party libraries). Maven is aware of the project dependencies and can properly order the build in a multi-module project. No maintenance: changes on transitive dependencies won't break the assembly, code is generic. Perfect size: the package contains the exact necessary and sufficient content. Factorization: the NXR can be attached to the reactor for being reused in another assembly.	The drawback is it takes some build time and has a dependency on a whole Nuxeo distribution. Maximum build time: the build performs more actions than the other methods and will consume more bandwidth. Writing requires Maven knowledge on concepts such as the GAV, the dependency graph, the dependency management, the artifact resolution.

PROS

CONS

Always up-to-date in regards to the dependencies and requirements (other bundles and third-party libraries).
Maven is aware of the project dependencies and can properly order the build in a multi-module project.
No maintenance: changes on transitive dependencies won't break the assembly, code is generic.
Perfect size: the package contains the exact necessary and sufficient content.
Factorization: the NXR can be attached to the reactor for being reused in another assembly.

The drawback is it takes some build time and has a dependency on a whole Nuxeo distribution.
Maximum build time: the build performs more actions than the other methods and will consume more bandwidth.
Writing requires Maven knowledge on concepts such as the GAV, the dependency graph, the dependency management, the artifact resolution.

4 directories, 6 files, 128KB. Build time: 11s.

    recommended/
    |-- install
    |   |-- artifacts-sample.properties
    |   |-- bundles
    |   |   `-- The sample project bundle.
    |   |-- templates
    |   |   `-- sample
    |   `-- test-artifacts-sample.properties
    |-- install.xml
    `-- package.xml

The lib directory is empty because all required third-parties are already included in the basic Nuxeo distribution. The bundles directory only contains the sample project bundle because all its dependencies are also already included in the basic distribution.

No-NXR Method

That method is using the same principle for building the Nuxeo Package as for building an NXR, with no final optimization. It is an acceptable compromise between speed and quality.

PROS	CONS
It is as much reliable regarding at the dependencies as the above recommended method. Maven is aware of the project dependencies and can properly order the build in a multi-module project. No maintenance: changes on transitive dependencies won't break the assembly, code is generic. Moderate build time: faster than the recommended method.	The drawback is since the solution is empiric, it will likely embed useless files and generate a bigger archive. Biggest size: the package contains the necessary but also useless content. Writing requires Maven knowledge on concepts such as the GAV, the dependency graph, the dependency management, the artifact resolution.

5 directories, 150 files, 33MB. Build time: 6s.

    nonxr/
    |-- install
    |   |-- artifacts-sample.properties
    |   |-- bundles
    |   |   `-- 46 bundles.
    |   |-- lib
    |   |   `-- 99 third-party libraries.
    |   |-- templates
    |   |   `-- sample
    |   `-- test-artifacts-sample.properties
    |-- install.xml
    `-- package.xml

Here, we are embedding a lot of bundles and libraries which are useless because already included in the basic Nuxeo distribution but that cannot be detected by the build process.

Explicit Method

That latest method is explicitly listing everything that must be packaged. It is not recommended except for specific cases, quick solution or proof of concept.

PROS	CONS
Easy method: very few code is required, you simply list what you want. It requires absolutely no Maven concept knowledge. Minimum build time: the build is really fast.	Maintenance required: you have to manually update the package assembly every time the dependencies change. You also risk not to see that an indirect dependency has changed and requires some changes on the third-party libraries. Managed size: the package contains exactly what you expect, with no guarantee of results.

5 directories, 8 files, 1.6MB. Build time: 3s.

    explicit/
    |-- install
    |   |-- bundles
    |   |   `-- The sample project bundle, explicitly listed.
    |   |-- lib
    |   |   `-- 4 third-party libraries, explicitly listed.
    |   `-- templates
    |       `-- sample
    |-- install.xml
    `-- package.xml

That solution builds a lighter package than the No-NXR method but we don't know if it will be missing some dependencies or not. The embedded bundles and libraries list must be manually maintained.