Light development update and survey

Published on February 17, 2016 by Christopher Zimmermann

Dear Magnolia Community,


I’d like to discuss the light development initiative with you. To let you know what we have accomplished and what we are working on, and to hear from you about your impressions, wishes and questions.

Especially for those of you that are already using it, please let us know about your experience via the survey at the bottom of the post.


Overview of light development

Light development means two things:

  1. Making projects faster and easier for all Magnolia developers.
  2. Empowering frontend developers to use their existing tools and processes to create Magnolia projects with minimal or no Java development.

A key ease-of-development feature is the concept of a “light module”: a way to package Magnolia functionality without requiring Java jars, but simply a directory of files. A Magnolia instance watches a specific directory on the filesystem, of which every sub-directory is considered a light module. Even for teams that want to deploy their projects with maven java modules - light modules can still facilitate development. Light modules are designed to be easy to convert to a maven module.



We’re really excited to engage the frontend development community more deeply. The key value that I see Magnolia bringing to the CMS space with light development can be summed up as:

Agile frontend development + Robust enterprise backend with Java based integration.

(Two great tastes that taste great together.



In July 2015 we released 5.4 which introduced the ability to configure templates, dialogs and apps via text files in yaml format. We also introduced the resource “loading cascade” including hot-reload from the file system. This has enabled frontenders to develop page and component templates and dialogs directly on the file system - without having to work in AdminCentral and manage xml “bootstrap files” and install tasks. We also released v0.5 of magnolia templating essentials - including a set of basic templates.


Since then we have been making steady updates on the 5.4.x releases, improving the resource loading and re-organizing the set of templates into its own module: Magnolia templating kit, or MTK. This set of templates is now java-free and is available as both a maven module and a light module. This means that frontenders can download the light module, understand exactly how they work, and use them as inspiration or starting points for their own templates.


Plan - A work in progress

Here is what we have in the pipeline. Caveat - things will change - that’s part of the reason for sharing it with you, to discover what should change! And we’re still discussing internally which features make sense in the context of light development.


Resource loading improvements

Improve hot-reload from the file system to detect changes in include files, when directories of files are added, and when files are removed.


Additional mtk components

image, page intro, video, download list, column layout, social share, carousel


Navigation templating functions and component


Decoration via Yaml files

Yaml files can modify existing configuration that was defined in other modules either by JCR bootstrap files or by YAML files. For example in your own custom module you could change the component availability of a template defined in another module, such as the travel demo.


Extends via Yaml files

Yaml files can include other files - AND override some of the values, similar to what is possible in JCR configuration.


Light module packaging via npm

Light modules can optionally use npm for dependency management. Helpers for moving resources to proper locations on install.


Magnolia module descriptors for light modules

Light modules and Maven modules can declare Magnolia dependencies, and optional dependencies on each other. (This is a requirement for the decoration feature.)


JCR Bootstraps via light modules (JCR XML)

We consider enabling bootstrapping (importing) website, asset, custom app content, and configuration. Note: these “bootstraps” behave different from the YAML resources, the content is actually imported into the JCR data repository on module installation, there is no hot-reload. Also note that you can already bootstrap JCR XML by placing them in a special directory in the webapp.


i18n message property files via light modules


Template models via light modules

Groovy classes can be supplied in a light module, and used for any purpose.


Configuration via YAML for:

  • Theme
  • Site
  • VirtualUriMapping


Page template availability via Yaml

Configure which page templates can be added to a page by specifying their id, a directory, or a module


CLI (command line interface)

Command line tool for accelerating common tasks like creating a new component


Light module deployment

If you use light modules in production, currently you must manage deployment of the files (via git for example). We consider adding a feature that will deploy all light module file resources from the author instance to the public instances via the standard jcr activation/publishing mechanism.

For more detail, and links to our JIRA tickets you can visit this page:



Your Input

Please take a few minutes to provide us some feedback on this initiative. Your input will help us build the functionality most important to you. Magnolia employees are welcome to participate too.

Short Survey:



(Photo credit: Scott Produence )


{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Christopher Zimmermann

Christopher is a software developer and startup enthusiast with a focus on front-end web technologies. His interest in innovative UI leads to diverse experimentation from phone based GPS services, to Oculus Rift immersive experiences. He organizes the 'basel.js' javascript meetup group. Christopher is a product manager at Magnolia.

See all posts on Christopher Zimmermann