IDE and Dispatcher Tools

Choosing an IDE

Adobe documents three: IntelliJ IDEA, Eclipse and Visual Studio Code. All three work. For a Java-heavy AEM project IntelliJ is the common professional choice; VS Code is popular when most of your day is HTL, CSS and JS.

Whichever you pick, you need three capabilities:

• Maven integration — build and deploy the project.
• Content sync — push a single file to a running instance without a full build.
• Remote debugging — attach to the local JVM (day 38).

For sync, the tooling is built on VLT (Jackrabbit FileVault): IntelliJ uses Repo or the AEM plugin, Eclipse uses the AEM Developer Tools, VS Code uses the AEM Sync-style extensions. They all do the same job — map a folder in your project to a path in the repository and push or pull individual files.

Two very different ways to get code onto an instance

The profiles you will actually type, from the project root:

# Build everything and install the 'all' package to author on 4502
mvn clean install -PautoInstallPackage

# Build and install only the core bundle (much faster for Java changes)
mvn clean install -PautoInstallBundle -pl core

# Target publish instead
mvn clean install -PautoInstallPackagePublish

Editing HTL? Sync it and refresh. Editing Java? You must rebuild the bundle. Confusing the two is the classic "why isn't my change showing up" of week one.

The local Dispatcher

The SDK's Dispatcher tools run the real Dispatcher module in Docker, using the same configuration your pipeline will deploy. Testing locally matters because Dispatcher problems — a filter that is too strict, a caching rule that never matches — are invisible until something sits in front of AEM.

# One-off: unpack the dispatcher tools from the SDK
./aem-sdk-dispatcher-tools-*.sh

# Validate the configuration (this is what the pipeline runs too)
bin/validate.sh dispatcher/src

# Start it, pointing at your local publish instance
bin/docker_run.sh dispatcher/src host.docker.internal:4503 8080

Your site is then at http://localhost:8080, going through the Dispatcher rather than straight to AEM. The difference is immediately visible: pages get cached, and requests your filters deny now actually fail.

A workable local loop

1. Author instance on 4502, publish on 4503.
2. Dispatcher in Docker on 8080 in front of publish.
3. Author content on 4502, publish it, check the real rendering through 8080.
4. Java changes: -PautoInstallBundle. Front-end changes: sync, or the ui.frontend watch task.

You do not need all of this every day. Most component work happens on author alone. But when you are chasing a caching bug or a filter problem, having publish and Dispatcher running locally is the difference between reasoning and guessing.