The build of CQ is based on the OSGi container, so the custom code and functionality can be added to CQ via the feature provided by OSGi. To deploy custom code to OSGi containers, developers must package their code as a bundle. An OSGi bundle is just a jar file with additional metadata added. This article details how to use Apache Maven to create an OSGi bundle, and how to deploy the bundle to a running CQ instance.
building an OSGi bundleThe simplest way for a CQ developer to build an OSGi bundle is to use Apache Maven via the Apache Felix bundle plugin. This plugin was developed by the Apache Felix team based on Peter Kriens's BND tool, although the OSGi bundle it creates is not just for Felix, it can also be used by other OSGi containers.
This plugin allows developers to work with a basic jar file created using Maven (either through the command line or an IDE tool), but can provide low-level control over the OSGi metadata added to the bundle.
The first step is to create a new Maven project, set the package style to bundle, and of course add the Apache Felix bundle plugin definition.
<?xml version= "1.0" encoding= "UTF-8"?> <project xmlns= "http://maven.apache.org/POM/4.0.0" xmlns:xsi= "http ://www.w3.org/2001/XMLSchema-instance "xsi:schemalocation=" http://maven.apache.org/POM/4.0.0 Http://maven.apache . org/xsd/maven-4.0.0.xsd "> <modelVersion>4.0.0</modelVersion> <parent> <groupid>co M.headwire.cqblueprints</groupid> <artifactId>parent</artifactId> <version>5.4.0-sna Pshot</version> </parent> <artifactId>cqblueprints-examples-osgi-bundle</artifactId> <
packaging>bundle</packaging> <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.felix</groupId> <ar
Tifactid>maven-bundle-plugin</artifactid> <version>2.3.5</version> <extensions>true</extensions> </plugin> ... </plugins> </pluginmanag
ement> <plugins> <plugin> <groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId> ... </plugin> </plugins> </build> ... </project>
The next step is to configure the Apache Felix Bundle plugin:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactid>maven-bundle-plugin </artifactId>
<configuration>
<instructions>
<Bundle-Activator> Com.headwire.cqblueprints.examples.osgi.activator</bundle-activator>
<Private-Package> Com.headwire.cqblueprints.examples.osgi</private-package>
<embed-dependency>*;scope=compile| runtime</embed-dependency>
<Embed-Directory>OSGI-INF/lib</Embed-Directory>
< Embed-transitive>true</embed-transitive>
<import-package>!org.slf4j.impl,*</ import-package>
</instructions>
</configuration>
</plugin>
The above example sets several configuration items:
<Bundle-Activator>
OSGi Bundle Activator (a class bound to the OSGi bundle life cycle, through which we can execute custom code when bundles start or close), the full Java class name. This setting is optional.
<Private-Package>
Packages that should not be exposed to OSGi containers (such as packages that contain only implementation classes and not the API-related functionality provided by the bundle). The above example declares the package where the Activator is located as private.
<Embed-Dependency>
Which Maven dependencies to embed when creating the bundle. The above example is set to *;scope=compile|runtime because it will contain all of the dependencies for the scope of compile or runtime, which would be all the classes required for the bundle to function properly.
It is recommended that you include this dependency configuration in your bundle. Instead of embedding dependencies in bundles, the alternative is to import dependencies from the OSGi container. We recommend the former because it makes it easier for other developers to use bundles without having to trace all dependencies and deploy them first when deploying new bundles.
Any dependency (for example, all the classes in the Org.osgi.framework package) that is required at the time of bundle compilation and provided by the OSGi container at run time should be declared with scope provided-so that they are not embedded in the bundle.
<Embed-Directory>
The embedded third-party package will be placed in the bundle's location. Set it to Osgi-inf/lib. The Osgi-inf directory is where other OSGi-related metadata will be placed, mimicking the Web-inf/lib directory familiar to most Java developers.
<Embed-Transitive>
Whether to embed only the direct dependency of the bundle POM (set it to false if embedded), or whether to embed the transitive diagram of the dependency declared by the POM (set it to true if embedded). Set this to true because it will make it easier to process the bundle. If there are some dependencies that should not be included (for example, there might be other bundles that set them to be visible to the entire project, the result is a package conflict), you can filter them out using the embed-dependency tag.
<Import-Package>
The bundle requires a package provided by the OSGi container (for example, the bundle itself needs no embedded classes). Since using the default value is sufficient, this label is usually ignored. The final value will include not only the packages required in the bundle code, but also the packages required by any dependencies that have been embedded. If a class imported by the bundle is not provided in the OSGi container, the bundle can still be installed but cannot be started.
Once the bundle has been created successfully, the required OSGi metadata will be added to the jar's manfifest. MF file, and all dependencies are also embedded in the Osgi-inf/lib directory.
For more information on these and other options, see the Apache Felix Bundle plugin page.
Deploy an OSGi bundleOnce the Maven POM configuration for the OSGi bundle has been created, it will continue to be configured for deployment to a running CQ environment.
Since the build of CQ is based on Apache Sling, we can use a Maven plugin for this project to deploy the OSGi bundle directly to CQ. The Maven Sling plugin allows us to deploy an OSGi bundle to a local or remote running CQ instance.
Next, add a new profile to the POM and add a plug-in definition to the profile to enable the Maven Sling plugin.
<profiles> <profile> <id>auto-deploy</id> <build> <pluginManagement> <p lugins> <plugin> <groupId>org.apache.sling</groupId> <artifactid>maven-sling-p
lugin</artifactid> <version>2.0.4-incubator</version> </plugin> </plugins>
</pluginManagement> <plugins> <plugin> <groupId>org.apache.sling</groupId> <artifactId>maven-sling-plugin</artifactId> <executions> <execution> <id> deploy-to-cq</id> <phase>install</phase> <goals> <goal>install</goa l> </goals> <configuration> <slingurl>${crx.url}/system/console/install</sli ngurl> <user>${crx.user}</user> <password>${crx.password}</password> <
;/configuration> </execution> </executions> </plugin> </plugins> </build> </profile> & Lt;/profiles>
It is important to declare the Sling plugin in a profile and not activate for the profile by default, because the Sing plugin will cause the Maven build to fail if the specified CQ instance cannot be connected. By dropping the Sling plugin into a profile, Maven will be able to build and publish the bundle without having an available running CQ instance.
However, in a re-deployment environment, you simply activate the Auto-deploy profile and then each time you run Maven install, the bundle will be automatically redeployed to CQ. The command line example is as follows:
mvn-pauto-deploy Clean Install
Most common Ides (Eclipse,netbeans, and so on) allow developers to configure which profiles are available when they perform a Maven build.
It is also important to parameterize the Sling connection configuration through the use of Maven properties, so that the build can be easily executed on multiple developer machines, but still provide default values in the POM.
<properties>
<crx.url>http://localhost:4502</crx.url>
<crx.user>admin</ crx.user>
<crx.password>admin</crx.password>
</properties>
When the default values are not available, they can be easily rewritten using standard Maven features. An example of a command line build override for a server URL is as follows:
mvn-pauto-deploy-dcrx.url=http://localhost:8080 Clean Install
Or, for a more permanent rewrite, add the property directly to the user's Settings.xml file:
<?xml version= "1.0" encoding= "UTF-8"?> <settings
xmlns= "http://maven.apache.org/SETTINGS/1.0.0"
Xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance"
xsi:schemalocation= "Http://maven.apache.org/SETTINGS /1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd "> ...
<profiles> ...
<profile>
<id>local-crx-settings</id>
<activation>
<activebydefault >true</activeByDefault>
</activation>
<properties>
<crx.url>http:// localhost</crx.url>
</properties>
</profile>
</profiles>
</ Settings>
After the Maven build is executed, if the deployment succeeds, the bundle will be installed and started. Depending on what the bundle does, any negative effects should be immediately visible. Finally, the bundle will be listed in the Bundles screen of the Administrator console, and the default location is:
Http://localhost:4502/system/console/bundles
Original link: Building & deploying OSGi Bundles.
About the author
The Cqblueprints website is designed to provide some help to architects and developers who use Adobe CQ. Although there is a lot of information about CQ on Adobe's official website, the information is focused on CQ's own products. When you actually go to the landing of CQ you have to consider a lot of additional topics (such as how to develop independently.) What can be developed to work in a deployment environment. )。 The Cqblueprints Web site is focused on these issues.
