Since the introduction of OSGi modules, Digital Experience Manager no longer “explodes” modules upon deployment. Before version 7, Digital Experience Manager would uncompress the contents of the WAR module file into a sub-directory of the /modules directory. This could lead to multiple problems notably with environments where writing on disk in the web application directory is not recommended (or not allowed), because it is not a good Java EE practice. Also this might tempt developers to modify exploded files directly during development in order to benefit from very quick develop-test-modify cycles, but they would then have the problem of having to sync back (manually) the changes to the module’s source code. Digital Experience Manager 7 solves this by introducing Deploy-free coding. This new features makes it possible, upon compilation and deployment of an OSGI module, to work directly from the source code without needing to redeploy.

How to use it

Create your module’s source code project

Compile and deploy it to your Digital Experience Manager server that must be on the same file system as your project (initial deployment “links” source code with Jahia server). Note that the file system could be a network shared file system this is of course allowed.

Modify static resources directly in your source code; Jahia will pick up the changes directly from the source, no deployment needed.

How it works

When building the project, the Jahia Maven Plugin will add a special MANIFEST.MF header that points to the source code location with an absolute path. This is configured in the Felix Maven Bundle plugin by the following line:

<Jahia-Source-Folders>${project.basedir}</Jahia-Source-Folders>

Upon generation of the MANIFEST.MF inside the JAR, it will look something like this:

Jahia-Source-Folders: /home/jahia/modules/assets

When a request comes in to a /modules/assets URL, Digital Experience Manager will use the Jahia-Source-Folders manifest header (if present) to look for the source code of the project. If it is present, it will try to access the requested resource directly from the source folder instead of using the contents of the bundle. There are some limitations in this mechanism, not all files can be directly used, as some require compilation or internal caches may interfere with the proper detection of file modifications. Here is a list of resource types that are known to work with Deploy-free coding:

JSP

HTML

Images

CSS

Javascript

Velocity

Other static file types such as documents, text files, etc.…

And here is a list of resources types that don’t work:

Groovy files (due to the internal Groovy engine class cache)

Java classes

Java Libraries

Of course, for the file types that don’t work with Deploy-free coding, it is still possible to hot-deploy them using OSGi bundle redeployment. So, for those file types the deployment life cycle is a little longer but still much faster than in previous versions of Digital Experience Manager.

Releasing modules

When releasing modules, it is recommended that you remove the Jahia-Source-Folders configuration attribute from the Felix Maven Bundle plugin configuration. This is just to avoid any potential lookups in case the source folders also exist on the server. It will also prevent unnecessary file lookups.