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.

  • Syntax Highlighting

    The various information in property values are properly parsed and highlighted. Color settings can be adjusted in the preferences as usual.

  • Structured Access

    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
  • Code Completion

    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.

  • Exporting Content

    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.

AEM Components

Components are central building blocks of every application developed for AEM. Therefore, IntelliJ AEM adds a set of features to simplify working with them.

  • References

    In AEM, or rather Sling, resource types like foundation/components/page are essentially references to content nodes. IntelliJ AEM recognizes these references allowing you to navigate directly to a resource type's declaration.

  • Find Usages

    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.

  • MoveNEW/Rename Refactoring

    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.

  • Rename PropertyWIP

    When using OSGi Declarative Services annotations, you can declare your OSGi component's configuration with an annotation interface and pass it to your @Activate method. 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.

  • Code Inspections

    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.

Pro Tip

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 your project.


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.

Workspace Filters

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.

  • Testing Filters

    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.