A Magnolia module can be purely file based or it can be wrapped in a Maven project.
|Magnolia module wrapped in a typical Maven module |
structure before it is built.
|File-based Magnolia module under $magnolia.resources.dir|
These two folder trees show typical folder structures rather than structures with all folders possible.
magnolia.resources.diris a property defining the directory from which resources are loaded in a Magnolia instance. This directory is used for file-based resources such as light modules and for overriding classpath resources. The property is configured in
WEB-INF/config/default/magnolia.propertiesand its default value is
$magnolia.home/modules. To see the current value of the property, go to the Config Info tab in the About Magnolia app.
You can use symbolic links (symlinks or soft links) in the resources directory to include light modules located elsewhere on your system.
magnolia.resources.filesystem.observation.excludedDirectoriesproperty to exclude directories from being observed for changes. (See Configuration management - magnolia.resources.filesystem.observation.excludedDirectories.)
<module-name>folder contains exactly the same content in a Maven module and folder-based module. In a Maven module this folder is within
src/main/resources. In a folder-based modules this folder is within
When creating a name for a module, do not use spaces, accented characters such as
üor special characters such as slashes
\and so on. The name must match the regular expression
create-light-module command in the Magnolia CLI creates the module folder structure on the file system automatically.
Configuration data for apps (YAML files)
Definition decorator files (YAML files), see Definition decoration. Contains subfolders.
Dialogs (YAML files), may contain subfolders.
Fieldtype definitions (YAML files) for the Magnolia 5 UI framework.
i18n message bundle (.properties files).
MessageView definitions (YAML files).
All the web resources, typically contains subfolders. (Folder name is arbitrary.)
Template definitions (YAML files) and scripts with subfolders.
REST endpoint definitions (YAML files), with subfolders.
Virtual URI mapping definitions (YAML files) to redirect incoming requests to the actual content locations.
Definition item folders
A definition item is a component configuration for executing tasks in a Magnolia instance. Template definitions, dialog definitions, app definitions (also known as app descriptors), renderer definitions, themes definitions, field definitions and REST endpoint definitions are all examples of such definition items.
The majority of these items can be configured via YAML, in which case they are registered in a specific registry. The items registered can be seen in the Definitions app. Even though definition items can be configured via JCR in the
configuration workspace, configuring them in YAML files is the recommended approach.
The following folders host the definition items:
virtualURIMappings. For more information see Module definition items.
Magnolia module specific files
Module descriptor is a Magnolia-specific file that identifies and defines a module. When you start Magnolia, the system identifies available modules by locating each module's descriptor file.
In Magnolia Maven modules
Magnolia Maven-based modules must provide a module descriptor. It is located at
src/main/resources/META-INF/magnolia/<module-name>.xml. See XML-based module descriptor.
In light modules
In a Magnolia file-based module (light module), the descriptor is located at
$magnolia.resources.dir/example-light-module/module.yaml. See YAML-based module descriptor.
For Magnolia light modules, module descriptors currently support module dependencies only.
The config.yaml module configuration file
A Magnolia Maven-based module may contain the
src/main/resources/<module-name>/config.yaml file. It contains configuration data, which is applied to the Java bean properties of the Magnolia module class. See Module configuration for more information.
Light modules: file-based modules in $magnolia.resources.dir
As of Magnolia 5.4, a Magnolia module does not have to be a Maven module. You can add a file-based module in the
$magnolia.resources.dir is the webapp folder, for instance
magnoliaPublic. See Add the module folder to $magnolia.home for more information about
Creating a light module with Magnolia CLI
Using the Magnolia CLI you can create the folder structure for a light module with the command
create-light-module. Open a shell,
cd to your light modules directory, and execute the following command:
üor special characters (e.g. slashes
\and so on). The name must match the regular expression
Note that this only works if you have installed Magnolia CLI, see Magnolia CLI Installation.
Magnolia Maven module
If you are familiar with Java and Maven, you can use Maven to create and build your Magnolia module. Using Maven streamlines the process of creating a JAR file, deployment, and dependency management of your modules. All modules provided by Magnolia are built with Maven. This makes it easy to install or uninstall them by adding or removing a JAR file.
Creating a Magnolia Maven module with Maven archetypes
Magnolia provides a set of Maven archetypes for various tasks, one of which is creating a Magnolia Maven module.
Before running the Maven
archetype command, please read How to use Magnolia Maven archetypes: Check Maven settings.
If you are not familiar with the Maven archetype plugin, please get familiar with How to use Magnolia Maven archetypes: The archetype plugin.
Executing the archetype plugin command
Open a shell and change to the directory where you want the Magnolia Maven module skeleton to be created.
Run the following command:
Maven prompts you to specify values for several parameters. Use values that fit your requirements:
|Maven ||Typically reflects the name or domain of your company or projects.|
|Maven ||Project-specific identifier.|
|Maven artifact ||Project version. Typically, when creating a new project, use the value suggested by Maven, for example |
|Package name for Java classes reflecting both your company (or domain) and the specific project.|
Magnolia version from which your custom project inherits.
|The Java class name of the autogenerated module class.|
After you have finished entering the values, the archetype plugin displays their list and asks you to confirm it. If you confirm by pressing
ENTER, the plugin generates the skeleton of your archetype. You should see a
BUILD SUCCESS message at the end of the process. If you press
C, nothing is generated.
resources directories contain more subfolders. For further details, see above.