Day CQ is a very popular enterprise CMS (Content Management System) suite from Adobe. Although most of the time the development on Day CQ is related to CMS and most of the development can be mapped to a proper CMS system, there are times when you would need to develop some logic in your application, or need to develop some feature that may not be available readily within Day CQ. In these cases, you may need to write some application code.
Day CQ is a Java based software, and Java is the most popular way to develop custom features and application logic. To be specific, Day CQ is largely built using OSGi - a technology that enables you to develop truly modular applications. Developing any custom Java application modules also needs to be built on OSGi.
I have noticed that developing OSGi modules is often a pain for a CMS developer, largely because of the lack of full development support (or call it a buggy development support) from the CRXDE (The bundled Eclipse based IDE), which makes OSGi module development to take long time and painful. This post intends to give more insights to a CQ developer on OSGi, and also to do faster development of OSGi modules with OSGi.
Why the development pain?
Why is OSGi development painful with vanilla Day CQ development environment? Day CQ provides an Eclipse based IDE called as CRXDE. It is excellent for typical CMS development, but when it comes to developing Java applications, it lacks a lot of features, where a regular Eclipse (or your favorite IDE) will win.
CRXDE is not a Eclipse plugin, but rather an RCP application. For this reason, we cannot add any plugins to the CRXDE, as in a regular Eclipse. For this reason, it is not possible to create a regular Java/Maven project in CRXDE, and regular Java development is not possible. Although CRXDE allows us to write Java code, it is buggy. I have often encountered unwarranted compilation errors in Java code. Moreover, we cannot enhance the IDE with any plugin, such as Maven, which is useful for dependency resolution.
Utilize the expertise
It would have been the best thing, if CRXDE was available as an
Eclipse plugin. But since it is not, we will explore options where we
will develop OSGi bundles where we will use the tools for which they are good at. Use CRXDE for regular CMS development -
develop templates, components, workflows etc. Use regular Eclipse (or
your favorite IDE) for Java / OSGi development. Use Maven for build and
dependency resolution.
One
may have some workarounds with CRXDE itself, but again, if we follow
the approach I give below, it would be save a lot of our development
time, apart from the ease of development.
How each of these tools are used independently is beyond the scope of this post, but rather my focus here is to provide an approach to use these tool in a collaborative manner to make CQ development easy. That apart, we will use few more toolis specific to OSGi, that will make our life simpler when developing OSGi bundles.
Developing bundles for Day CQ
Let me outline the approach on how we will develop, test and finally deploy the OSGi bundles on Day CQ and see it working.
- Make a Maven project which can create OSGi bundles.
- Write code and install the bundles in local maven repository.
- Test the bundle
- Configure Day CQ's Felix web console to install bundles just created
- Test the Day CQ applications for the bundle just created.
Let me demonstrate the approach with the famous "Hello World" example, since it is better than giving abstract instructions and code samples. We will create three bundles:
- a hello world API bundle
- a hello world Service implementation bundle
- a client test bundle which will utilise the hello world service
Note however, that this approach will be more useful when you have complex requirements and more external maven dependencies.
I have made this "Hello World" application available on
github.
Create a Maven Project for your OSGi bundle
I suggest to use Maven for your OSGi bundle projects because:
- Maven is excellent in managing all the dependencies
- Creating OSGi bundles with Maven Bundle Plugin cannot get simpler. It automatically takes care of including any headers required due to the transitive dependencies.
- The learning from Maven can always be reused in your other projects as well, since Maven focuses on convention over configuration.
I prefer to use the following configuration for Maven Bundle Plugin:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>${bundle-plugin.version}</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-Name>${project.name}</Bundle-Name>
<Bundle-Description>${project.description}</Bundle-Description>
<Export-Package>${bundle.namespace};version="${project.version}"</Export-Package>
<Private-Package>${bundle.namespace}.internal.*</Private-Package>
<_removeheaders>Ignore-Package,Include-Resource,Private-Package,Embed-Dependency</_removeheaders>
<_include>-osgi.bnd</_include>
</instructions>
</configuration>
</plugin>
Here I have a osgi.bnd file place besides the pom.xml which has any specific instructions that needs to be provided to the bnd when creating the bundle. This will also override any instructions that are provided at the POM level (eg. some inherited instructions). For more details on the plugin, visit the
official documentation for the Maven bundle plugin.
What's next?
I have given a heads up on a less painful and more robust method to develop OSGi bundles for Day CQ. But there are more things, that can make things easier when developing applications on Day CQ. This would require a more deep dive into OSGi, and I will try to illustrate approaches that uses OSGi's best practices while making the OSGi development easy.
So mark this space for more on OSGi development with Day CQ!
