Wednesday, July 10, 2013

Organizing CQ project structure

It's pretty obvious that a good project structure can significantly reduce development and maintainable efforts of any software. CQ5 is not an exclusion, that's why it's important to stick to the best practices of organizing your code.

As you might know, CQ advocates moving all application-specific code to the  folder with custom application name. Resources, located in that folder either inherit base CQ items (components, templates, designs, etc.) or are independent resources. CQ applications can contain:

  • business logic implemented in java code and deployed in OSGI bundles, 
  • presentation logic which is embedded into scripts (JSPs, ESPs, Groovy scripts. etc.), 
  • content data (dialog/page/template configuration metadata, design artifacts like js and css, sample content).
Here is the proposal for a typical CQ project structure (screenshots taken from IntelliJ IDEA):
where bundles folder contains all application OSGI bundles, content folder contains scripts and content data, qa-rulesets folder contains code quality tools profiles. As you can see, project is Maven-based with a root pom in project's root folder. 
Let's expand each folder in more detail starting from bundles:
"Bundles"  folder contains one "core" bundle, which includes some common functionality and at least one "components"  bundle which contains presentation logic code for your application components. It can also contain other bundles according to application needs, but aforementioned two are the required minimum.
If you used Maven before you already noted that all bundles have standard structure with src/main/java for java source code, src/test/java for java tests and src/main/resources for required bundle resources, i.e. some configuration. Each bundle contain its own pom.xml which refers to the parent pom.xml in project's root folder.
Let's have a quick look at the core bundle:
You can see that it contains bundle activator, service (in this case configuration service), servlet, unit tests for all these classes and integration tests under "integration" folder. Integration tests are written using Cucumber framework, which we'll cover in detail in a separate blog post.

Now let's switch to "content" folder:
It contains CQ content structure, which advocates putting data under application-specific folder (in this case sampleapp). 
Components folder is further divided into page and modular folders, where page contains page component-related resources (scripts, JCR metadata) and modular contains components resources which can be used on those pages. Idea here is to split all your components into logical units.
Designs folder contains all client artifacts (JS, CSS) organized into several clientlibs. For example you can see clientlib for twitter bootstrap (clientlib-bootstrap) and application-specific clientlib (clientlib-all).
META-INF contains configuration files for CQ vault tool, which is needed during deployment.
Having organized content this way we isolated our application from core CQ logic and from other applications logic, because everything is put under our own application folder sampleapp. If we want to reuse other components we can easily do so with the help of JCR node's inheritance or composition.

Finally qa-rulesets folder contains profiles for code quality tools which are executed during maven build.
Here we use Checkstyle, PMD and FindBugs for local code quality checks. We also have Sonar profile which integrates all previous profiles.

Automating project skeleton creation.

As our project is Maven-based, it is quite natural that we need to create maven archetype which will generate this project structure. For this project I used one of custom archetypes which: 
  • Contains OSGI modules with Slice activator (more on it in next blog posts), includes sample CQ project based on Twitter Bootstrap.
  • Contains profile for executing local SCA analysis (Checkstyle/PMD/FindBugs are used for that) and automatic SCA using Sonar QA platform.
  • Integrates with Cucumber. Has sample mock usage in unit tests using Powermock/Mockito
You can freely use this archetype as a starting point for creating new CQ5-based project.