Installing Bundles by Runmode

If I had a dollar for every bundle configuration I've looked at where there was a little checkbox titled "Enabled", I'd have, like, maybe $31 dollars and I could afford a new Indie Steam game or perhaps 12 of them if I waited for the summer or holiday sales... In reality, I've been on countless projects where the prevailing approach for ensuring a bundle only runs for a specific runmode is to make it configurable via the aformentioned checkbox. While this approach certainly works, there's a much easier and, in my opinion, cleaner and better way to handle this that I think gets overlooked

For starters, consider that you can provide runmode-specific configurations for your bundles via simple naming convention. I'd cover this myself, but Krtisian Wright does an excellent job of doing so here. In short, you'll typically see structures along the following lines:

• /apps/skynet/config.author
• /apps/skynet/config.publish
• /apps/skynet/config.<some-other-runmode>

And, yes, Skynet is being built on top of AEM. You heard it here first... Back on topic, the same naming conventions apply for installation of bundles as well. For example

• /apps/skynet/install.publish

will have any bundles therein installed only if the current runmode is publish. Also, for what it's worth, you can even chain runmodes together for both the configuration and installation of bundles. For example

• /apps/skynet/install.publish.staging

will install any bundles underneath so long as the instance's runmode is both publish and staging. For the unaware, yes, you can have as many runmodes as you want for any particular instance. This allows you to set up environment-specific configurations. Further, note that the runmodes "author" and "publish" are just two default runmodes for AEM that have a bunch of predefined configuration set up for you. In fairness, one advantage to using the "Enabled" checkbox approach is that you could then test your bundle on any instance by configuring it. However, configuring bundles directly through Felix instead of doing so via sling:OsgiConfig nodes can open up its own can of worms in the generation of an nt:file and actually overwriting your sling:OsgiConfig with this nt:file if it exists :(. So, for future projects, I highly recommend setting up runmodes for your specific environments and building out your configurations and bundle installation for each exactly as you want them using the above approach.