IntelliJ AEM

Features

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.

Jackrabbit FileVault

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.

  • Pull/Push/Export Content

    IntelliJ AEM comes with support for pushing content to and pulling/exporting content from AEM. This simplifies the development workflow and reduces the need to use other tools such as Maven or the FileVault command line tool.

  • Open in browser

    When working with FileVault XML files, you can easily open the current file's root node in CRXDE from within the IDE. In addition, if the root node represents a page, you can open it in the page editor or view it as published.

  • 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.

  • Workspace Filter Validation

    IntelliJ AEM comes with a schema that validates filter.xml and filter-vlt.xml workspace filters and provides completion of XML elements and attributes.

  • 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.

  • 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

  • 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.

  • Compare with AEM instance

    Sometimes it's useful to compare a local file with its counterpart on one of your AEM instances, for example when upgrading to a newer AEM version or when troubleshooting a bug. With this feature you can easily open a view that shows a diff between the two.

AEM / Sling Components

Components are central building blocks of every application developed for AEM. Therefore, IntelliJ AEM adds numerous features to simplify working with them. In particular, IntelliJ AEM recognizes resource types like foundation/components/page, which are essentially references to content nodes.

  • 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.

  • Move/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.

  • Coral / Granite UI ComponentsNEW

    Creating or modifying CQ component dialogs is a recurring task, so advanced code completion for nodes and properties of Coral / Granite UI components is a huge time safer. Supported components include containers, form fields, data sources, render conditions and more.

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.

  • Create Configuration

    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 Support

    OSGi configurations are stored in either JSON or 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.

  • Custom Name OSGi Components

    An OSGi component's custom name is recognized and can be renamed to adjust names of OSGi configuration files.

  • OSGi Bundles as Library

    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.

  • Generator for Injected OSGi Service References

    This generator action allows to select from a list of interfaces that are implemented by OSGi service components and then adds the respective field using the appropriate @Reference annotation.

  • Rename Property

    When renaming a Component Property Type's method, IntelliJ AEM will make sure that property names in OSGi configuration files will be adjusted accordingly.

  • Implicit Usage

    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.

  • Go to Property Declaration

    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.

  • Configuration File Inspections

    Several inspections are provided that check the validity of your configuration files. For example, ensuring existence of properties and their correct type.

Sling Models

Sling Models have become the backbone of almost every AEM project's presentation layer. They are easy and quick to use, but there are still some tricky things to keep in mind. IntelliJ AEM makes working with Sling Models not only easier and faster. By providing inspections and hooking into IntelliJ platform's static analysis capabilities it's also much safer.

  • Code Completion for Properties

    In JCR content files, injected fields and constructor parameters are provided for completion based on the name defined in the Sling Model.

  • Code Completion for Resource Types

    Resource types are provided for completion in the @Model annotation's resourceType attribute.

  • Inferred Nullability Annotations

    IntelliJ IDEA automatically infers nullability annotations from code. This feature is extended for injected fields and constructor parameters.

  • Code Completion for Injected Classes

    Fields and constructor parameters annotated with @Self are recognized and the injected class' fields and constructor parameters are provided for completion, as well.

  • Injection Constructor Inspection

    This inspections checks that constructors used for injection are annotated with @Inject. In addition, it checks that all parameters requiring a name are either annotated with @Named or have a name attribute in their injection annotation.

  • Injected Field Inspection

    This inspection checks that injected fields are actually available when adapting the Sling Model from the specified adaptable.

  • Generator for Injected Fields

    A generator action is provided that allows to select injectable fields, such as script variables, from a dialog and then adds the respective field to the Sling Model using the proper annotation, for example @ScriptVariable.

  • Generator for Injected OSGi Service References

    This generator action allows to select from a list of interfaces that are implemented by OSGi service components and then adds the respective field using the @OSGiService annotation.

  • ACS AEM Commons AnnotationsNEW

    Supported annotations include injection annotations provided by the ACS AEM Commons open source project.