This page contains a comprehensive overview of the features provided by IntelliJ AEM. It will be updated when new functionality becomes available.
Features marked with WIP are work-in-progress and are either not fully functional yet or not available in all places. Those features marked with NEW have been added in a recent update.
Custom Language Support
One of the plugin's most notable additions is support for the custom XML format that Jackrabbit FileVault, and thus AEM's package manager, use for serializing JCR content. It's the foundation that makes some of the other features possible in the first place.
The various information in property values are properly parsed and highlighted. Color settings can be adjusted in the preferences as usual.
With the custom lexer and parser comes an extension of IntelliJ's Abstract Syntax Tree (AST). The various parts of a property definition are treated as individual tokens and thus allow more fine-grained code assist and refactoring.
Direct Integration with AEM
In order to provide advanced functionality, IntelliJ AEM directly connects to your AEM instances. In addition, it indexes entities provided by AEM or one of its underlying technologies such as JCR. This currently includes:
- Node types and their declared child nodes
- Property names and their types and cardinality
- Registered namespaces
- Component resource types
- Principal names and privileges
Without a doubt, code completion is one of the most useful features of modern IDEs. IntelliJ AEM provides completions for all indexed entities. And not only in XML, but also in other formats like JSON.
For development and testing, it's common to make changes in AEM directly, for example using CRXDE Lite. Instead of using command line tools or packages, you can simply export the content directly into your IntelliJ project.
Components are central building blocks of every application developed for AEM. Therefore, IntelliJ AEM adds a set of features to simplify working with them.
In AEM, or rather Sling, resource types like
foundation/components/pageare essentially references to content nodes. IntelliJ AEM recognizes these references allowing you to navigate directly to a resource type's declaration.
By providing the resource type references, IntelliJ IDEA is enabled to find all the code places where a resource type is used, be it in Java string literals, in XML attributes, or anywhere else.
When moving or renaming a resource type's folder (or one of it's parent folders), IntelliJ AEM makes sure that all code places that reference the resource type are being adjusted properly.
OSGi Components and Configurations
A lot of AEM's functionality is provided by OSGi services and components, which require configuration of some sort. IntelliJ AEM simplifies working with them by providing code completion and refactoring support. It recognizes the official OSGi Declarative Services annotations and Apache Felix' SCR annotations. Even though the latter are deprecated now, most legacy code still depends on them.
Go to Configuration
When OSGi configurations exist for a class, a gutter icon will be displayed on the left side of the editor. This allows you to quickly navigate from the OSGi component to any of it's configurations.
Code Completion for Properties
If a Java class for an OSGi component is available on the project's classpath, IntelliJ AEM will provide code completion for properties and their types.
Move/Rename OSGi Components
Moving or renaming an OSGi component's class, or any of its parent packages, will also adjust names of OSGi configuration files accordingly.
When using OSGi Declarative Services annotations, you can declare your OSGi component's configuration with an annotation interface and pass it to your
@Activatemethod. If you rename any of the annotation's methods, IntelliJ AEM will make sure that corresponding property names in OSGi configuration files will be adjusted accordingly.
By default, IntelliJ IDEA is not aware of the runtime that your code runs in and assumes that OSGi component lifecycle methods are never used. It also assumes that fields containing service references are never assigned. IntelliJ AEM now makes sure that this runtime use of methods and fields is recognized.
Since AEM is a closed-source product, many of the implementing classes of supplied
OSGi components are not available as public dependencies, thus code completion will not work. However,
if you have access to an instance's file system you can copy all
bundle.jar files from
<aem-installation-path>/crx-quickstart/launchpad/felix and add them as a library to
Some issues often become only apparent after installing your content or code. In order to safe precious time, IntelliJ AEM adds various inspections that highlight common errors or problems, and it allows you to fix them immediately.
Invalid Node Types
If indexing of your AEM instance is complete and a node type is not found in the index, an error annotation is shown.
Missing Required Properties
Some node types declare mandatory properties. If such a property is missing, an error annotation is shown and an intention action is provided that adds it for you.
Property Type Mismatch
If a mismatch between a property's expected and actual type is detected, a warning annotation is added and an intention action is provided that changes the type accordingly.
Since workspace filters are essential to every AEM project, IntelliJ AEM adds a few useful features related to them.
File Coverage Inspection
Ever wondered why your content doesn't show up in AEM, just to find out that you forgot to add a workspace filter? The workspace filter coverage inspection warns you when the currently edited file is not included. Alternatively, you can check all files using the Inspect Code... action.
Sometimes it's hard to find proper filter rules if your content is spread across multiple packages or otherwise special. IntelliJ AEM provides a dialog for testing workspace filters against path samples.