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:
Upon generation of the
MANIFEST.MF inside the JAR, it will look something like this:
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:
- 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.
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.