Your typical CQ or CRX project is multi-module, right? You have the typical collection of modules = artifacts = bundles and content packages: content, samplecontent, uiapp, core, taglib – you name them.
For cutting releases, it’s convenient to have just a single, defined artifact that aggregates all project artifacts into one, has a single version number, and is easily installed.
Including OSGi bundles for installation in a content package is easy enough, including content packages in other content packages on the other hand is not so common (but also easy enough). Here’s how it works:
- configure maven-vault-plugin
- add the packages to include as dependencies
- copy the packages into the aggregate package
- adjust your vlt filter config
- set the assembly package configuration (as usual)
configure maven-vault-plugin:
As always, configure maven-vault-plugin. Just use a different group than for your other packages, e.g. by appending ” Releases”. Also, set your module’s packaging to content-bundle.
<plugin> <groupId>com.day.jcr.vault</groupId> <artifactId>maven-vault-plugin</artifactId> <extensions>true</extensions> <configuration> <group>MyProject Releases</group> <requiresRoot>true</requiresRoot> <install>true</install> <verbose>true</verbose> <packageFile>${project.build.directory}/${project.build.finalName}.zip</packageFile> <version>${project.version}</version> </configuration> </plugin>
add the packages to include as dependencies:
Just list them as regular dependencies, with the appropriate type (typically content-bundle).
<dependencies> <dependency> <groupId>my-project-groupid</groupId> <artifactId>uiapp</artifactId> <version>${project.version}</version> <type>content-package</type> </dependency> <dependency> <groupId>my-project-groupid</groupId> <artifactId>content</artifactId> <version>${project.version}</version> <type>content-package</type> </dependency> <dependency> <groupId>my-project-groupid</groupId> <artifactId>samplecontent</artifactId> <version>${project.version}</version> <type>content-package</type> </dependency> </dependencies>
copy the packages into the aggregate package:
Configure maven-dependency-plugin to copy the dependencies to /etc/packages/MyProject as shown below.
You need to list out your artifacts in includeArtifacts.
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>copy-packages</id> <phase>prepare-package</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory> ${project.build.directory}/vault-work/jcr_root/etc/packages/MyProject </outputDirectory> <overWriteIfNewer>true</overWriteIfNewer> <includeArtifactIds> uiapp,samplecontent,content </includeArtifactIds> </configuration> </execution> </executions> </plugin>
adjust your vlt filter config (as usual):
Of course, your aggregate package needs to have an appropriate filter.xml, like so:
<?xml version="1.0" encoding="UTF-8"?> <workspaceFilter version="1.0"> <filter root="/etc/packages/MyProject"/> </workspaceFilter>
set the assembly package configuration (as usual):
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <executions> <execution> <id>package-zip</id> <phase>package</phase> <goals> <goal>single</goal> </goals> <configuration> <appendAssemblyId>false</appendAssemblyId> <descriptors> <descriptor>src/main/assembly/package.xml</descriptor> </descriptors> </configuration> </execution> </executions> </plugin>
<assembly> <id>zip</id> <formats> <format>zip</format> </formats> <includeBaseDirectory>false</includeBaseDirectory> <fileSets> <fileSet> <directory>${project.build.directory}/vault-work</directory> <outputDirectory/> </fileSet> </fileSets> </assembly>
That’s it – now build your bundle with mvn package and you’ll get a neatly wrapped content bundle that contains your content bundles.
handling OSGi bundles
You can include your OSGi bundles directly in this bundle as well, or you can include them in your inner content bundles. Either way works. Above example takes the latter approach (so it cannot be seen and the examples are cleaner :)
adding metadata
As this is a regular content bundle, you can easily add custom content with release information, e.g. a file /etc/myapp-releaseinfo.txt that contains build number, etc.
