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.
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.
FileVault XML Language Support
Jackrabbit FileVault uses a special XML dialect for serializing content. IntelliJ AEM adds language support for its custom property value format including syntax highlighting, error checks, and code completion.
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.
Invalid Node Type Inspection
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 Inspection
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 Inspection
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.
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 and project-specific functionality is provided by OSGi services and components, which also require configuration of some sort. IntelliJ AEM simplifies working with them by providing code completion and refactoring support. The standard way to declare OSGi components is to use annotations that are processed by the build system.
IntelliJ AEM recognizes two sets of annotations, the official OSGi Declarative Services annotations and Apache Felix' SCR annotations. 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 an OSGi component to any of it's configurations.
You can easily create configurations for project or AEM-provided OSGi components directly on the class or from the Project tool window.
Config File Language SupportNEW
OSGi configurations are either stored in XML files, or in a special properties dialect. IntelliJ AEM adds specific language support for the latter. This includes syntax highlighting, error checks, and code completion.
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.
Go to Property DeclarationNEW
For OSGi component properties declared using OSGi Declarative Services annotations, you can now navigate directly from the property to the annotation method that declares it.
Rename a Component Property Type's method, 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.
OSGi bundles as libraryNEW
Since AEM is a closed-source product, many of the implementing classes of supplied OSGi components are not available as public dependencies. In order to provide advanced functionality, IntelliJ AEM automatically adds bundles deployed to your configured AEM instances as external libraries to your project.