OSGi Configuration via JCR Nodes

The reasons to configure OSGi services via content nodes are obvious:

• Configurations are deployed with the code
• Configurations can be transferred with content packages
• Configurations can be managed with source control

Defining an OSGi configuration with content nodes is pretty simple:
You create a sling:Folder 'config' and add nodes below it of type sling:OsgiConfig. This node has to have the name of the persistence ID, usually, that's the fully qualified class name of the service you want to configure, e.g. com.day.cq.wcm.core.impl.VersionManagerImpl.

Therefore, you can configure the service with an xml file in the folder /apps/yourproject/config with the name com.day.cq.wcm.core.impl.VersionManagerImpl.xml and the following content:

<?xml version="1.0" encoding="UTF-8"> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" jcr:primartyType="sling:OsgiConfig" versionmanager.maxNumberVersions="{Long}5" versionmanager.ivPaths="/" versionmanager.purgePaths="[/etc/feeds,/home/users/public,/home/groups/public]" versionmanager.createVersionOnActivation="{Boolean}true" versionmanager.maxAgeDays="{Long}3" versionmanager.purgingEnabled="{Boolean}true" />

You can add factory configurations (multiple settings for one configuration) by adding a unique identifier to the file name, separated by a hyphen. Setting up the MCM configuration e.g. can be done by providing a file named com.day.cq.mcm.impl.MCMConfiguration-myConfiguration.xml. This will create a binding to the configuration.

Only one open topic remains: You usually have one code base, but multiple configuration according to the various systems: An integration test author system has different configurations compared to a production publish system. 

The instances can be distinguished by using different runmodes, and the configurations can be runmode specific as well:
Just add the name of the runmode the set of configurations apply to the config-folder, like 'config.author' or 'config.publish'. By this, you can maintain all applicable configurations in the version control, deploy the code, activate the packages - and the instance itself picks the proper settings. Pretty neat, isn't it?