• Technical Overview
  • Overview
    • What is Jahia?
    • The closer View
    • Technical Requirements
    • Everything is Content, whatever the type or source
      • Integrator and Developer Customization
    • Integrated technologies
    • Architecture Overview
    • Modules
    • Jahia's Different Actors
  • Web Layers
    • Content Flows
    • Templates and Views
    • The Jahia Template Studio
      • Page templates
      • Content Templates
    • REST API
      • Actions
      • Example : native iPhone/iPad application
    • Mobile Rendering
    • Macros
    • Filters
  • Back-end Layer
    • Workflow
    • JBoss Drools and event listeners
    • File Repository
    • Searching and Indexing
      • Full text queries using search tag librairies
      • Query Languages
    • Enterprise Jahia Tool - Authentication and Authorization
    • Import / Export
    • Enterprise Jahia Tool - Distant Server Publications
    • Portlets
      • Portlets vs. Modules
  • Enterprise Jahia Tool - Optimizing deployment and performance
  • Additional Resources

Modules

Modules are a very important part of Jahia, and may be thought of as Jahia’s plug-in infrastructure. Basically they are composed of directory and files that are packaged as a WAR file and then copied into Jahia’s WEB-INF/var/shared_modules directory for deployment. Upon detection of the new file, Jahia will then deploy the contents into the modules/ directory. Modules may range from very simple ones, such as only defining new views for existing content types, to very complex implementation of new communication layers such as OpenSocial, or implementing back-end LDAP user and group providers.

Template sets (see the Template Studio section below) are also packaged as modules, which make them easy to deploy and update.

Advantages of modules include:

• Re-usability: as they are autonomous, it is easy to move them from development to staging or to production environments. It is also easy to re-use them across projects or share them with others. Also, as it is possible to inherit from existing modules, it makes it nice and easy to extend a default module.

• Maintenance: as they are autonomous blocks, they can focus on a specific use case (like in the case of a forum module), which makes maintenance and evolution easy.

• Reliability: if a module fails, only that part of the system will be unavailable, the rest of the platform will continue to serve requests.

• Separation of concern: as the modules may be integrated at a later time, this makes it easier to split work among members of a team.

A developer will therefore mostly work on modules, either creating new ones or extending the out-of-the-box ones. He may also share his work (or re-use others’ contributions) on Jahia’s forge (http://www.jahia.org/forge).

A module may contain:

• Content definitions

• View scripts (JSP, JSR-286 compatible languages such as Velocity or Freemarker, or even PHP*)

• Static resources (text file, images, CSS files, Javascript files)

• Resource bundles or other property files

• Java classes or JAR libraries

• Filters

• Permission and role definitions

• Rules

• jBPM workflow definitions

• Tag libraries

• Spring Framework configuration files

• Content import files (in XML format)

Note that none of these files are required, and you may create an empty module, although it won’t be very useful.

* Through the integration of Caucho’s Quercus PHP engine, which may require a commercial license depending on deployment needs.