AEM Links: The Missing Index for Adobe's Scattered Developer Ecosystem

Hook

Adobe Experience Manager has been around since 2010, yet finding reliable documentation for its Sling/JCR/Oak stack still feels like archaeology. One developer decided to fix that with a curated bookmark collection that's now more valuable than Adobe's official docs.

Context

Adobe Experience Manager sits in a peculiar position in the enterprise CMS landscape. Built on powerful open-source foundations—Apache Sling, Apache Jackrabbit Oak, OSGi—it's wrapped in proprietary Adobe tooling and scattered across a decade of documentation rewrites, community blog posts, and Stack Overflow threads. Unlike modern developer platforms with centralized, searchable documentation, AEM knowledge exists in fragments: official Adobe docs that often lag real-world usage, personal blogs from consultants who've moved on, GitHub repositories with cryptic READMEs, and tribal knowledge passed between teams.

Paul Rohrbeck's aem-links repository emerged from this frustration. Rather than building yet another tool or framework, he created something simpler but more immediately useful: a curated index of the AEM developer ecosystem. It's not software you run—it's a map you consult. The repository organizes links to cheat sheets, command references, troubleshooting guides, essential tools, and community resources that experienced AEM developers have collectively deemed worthy. With 390 stars, it's become the unofficial starting point for developers entering the AEM world or trying to solve specific problems without drowning in Google results from 2013.

Technical Insight

The repository's architecture is deliberately minimal—a collection of markdown files organized by AEM subsystem and use case. This simplicity is its strength. The main index provides jump points to specialized sections: cheatsheets.md for quick command references, tools.md for the essential developer utilities, problems_solutions.md for common troubleshooting scenarios, and links.md for deeper dives into specific technologies.

The cheatsheet section demonstrates why this repository matters. Take the Dispatcher cheat sheet, which consolidates Apache mod_dispatcher configuration patterns that are otherwise scattered across Adobe's documentation. You'll find the critical /filter rule syntax that determines what content gets cached:

/filter {
  # Deny everything first, then allow specific patterns
  /0001 { /type "deny" /glob "*" }
  
  # Allow specific selectors and extensions
  /0023 { /type "allow" /extension "(css|gif|ico|js|png|swf|jpe?g)" }
  /0024 { /type "allow" /path "/content/*" /selectors "(feed|rss|pages|languages|blueprint|infinity|tidy)" }
  
  # Deny access to author tools in publish
  /0041 { /type "deny" /path "/apps/wcm/*" }
  /0042 { /type "deny" /url "/crx/*" }
}

This isn't code you'd find in a tutorial—it's production-hardened configuration that prevents security holes. The repository links to expanded explanations of why each pattern exists, but having the syntax reference in one place saves hours of documentation diving.

The Query Builder cheat sheet similarly consolidates JCR query syntax that AEM developers need daily but constantly forget. Instead of remembering whether it's property.value or property=value, you have a reference showing both the predicate format and equivalent JCR-SQL2:

// Find all pages modified in last 7 days
// Predicate format:
Map<String, String> map = new HashMap<>();
map.put("path", "/content/mysite");
map.put("type", "cq:Page");
map.put("daterange.property", "jcr:content/cq:lastModified");
map.put("daterange.lowerBound", "2024-01-01T00:00:00.000Z");
map.put("daterange.lowerOperation", ">=");

Query query = builder.createQuery(PredicateGroup.create(map), session);
SearchResult result = query.getResult();

// Equivalent JCR-SQL2:
SELECT * FROM [cq:Page] AS page
WHERE ISDESCENDANTNODE(page, '/content/mysite')
AND page.[jcr:content/cq:lastModified] >= CAST('2024-01-01T00:00:00.000Z' AS DATE)

The tools section is where the repository's curation shines brightest. AEM development involves a constellation of third-party utilities that fill gaps in Adobe's official tooling. The repository indexes AEMSync for real-time file synchronization during development, the Gradle AEM Plugin for modern build pipelines, Grabbit for content migration, and ACS AEM Commons for reusable components. Each entry includes not just a link but context about what problem the tool solves.

For example, the entry for AEMSync explains that it watches your local filesystem and pushes changes to AEM instances in milliseconds—critical for rapid iteration that Adobe's default Maven-based workflow doesn't support. The repository links to the tool, explains the use case, and points to related resources about AEM development workflows. This curatorial layer transforms a simple link list into a knowledge graph.

The problems-solutions section captures institutional knowledge that typically lives only in senior developers' heads. It addresses questions like "Why is my OSGi bundle in installed state but not active?" with links to explanations of dependency resolution, "How do I debug slow JCR queries?" with pointers to Oak indexing guides, and "What's causing my Dispatcher flush to fail?" with troubleshooting workflows. These aren't comprehensive tutorials—they're starting points that prevent the most common rabbit holes.

The community section indexes the human infrastructure around AEM: key Twitter accounts to follow (though some have migrated to other platforms), AEM-focused meetups, conference sessions, and the most active Stack Overflow contributors. This social dimension is often overlooked in technical documentation but is crucial for staying current in an ecosystem that evolves through community practice as much as official releases.

Gotcha

The fundamental limitation of aem-links is inherent to its design: it's a snapshot that decays. Links rot. Blogs get taken down when consultants change companies. Tools get deprecated when maintainers move on. A repository last updated months ago might contain broken links to resources that have moved or disappeared. Unlike executable code that breaks visibly when dependencies change, a link collection fails silently—you only discover the problem when you click.

The lack of quality ranking creates a different problem. The repository lists resources but doesn't explicitly indicate which are canonical, which are outdated-but-historically-interesting, and which are actively harmful. A link to a 2014 blog post about AEM 6.0 sits alongside a 2023 guide for AEM as a Cloud Service, and the burden falls on you to determine relevance. For developers new to AEM, this can be disorienting—you're looking for answers but now must develop the context to evaluate which answers apply to your situation.

There's also zero executable content. This repository won't teach you AEM through hands-on practice. It won't provide working code samples you can clone and run. It's entirely meta—a guide to guides, a tool for finding tools. If you learn best by doing rather than reading, you'll still need to jump to the referenced repositories and work through their examples. The repository saves you search time but doesn't replace the learning process itself.

Verdict

Use if: You're onboarding to an AEM project and need to rapidly orient yourself in the ecosystem, you're an experienced AEM developer who needs quick command references without searching Adobe's documentation labyrinth, you want to discover community tools that solve specific workflow problems Adobe's tooling doesn't address, or you need to find troubleshooting resources for a specific AEM subsystem like Dispatcher or Oak indexing. This repository excels as a navigational aid and reference index. Skip if: You need in-depth tutorials with hands-on examples (go directly to the linked tool repositories instead), you require guaranteed up-to-date information for production decisions (verify everything against current Adobe docs), you're working exclusively with AEM as a Cloud Service where some traditional concerns are abstracted away, or you expect a living, actively maintained resource (treat this as a historical snapshot that requires verification). Best used as your first stop for finding resources, not your last stop for learning them.