The AEM Developer’s Survival Guide: Why a Simple Link Repository Has 388 Stars
Hook
A repository with no executable code has 388 GitHub stars. It contains only markdown files with links. Yet for Adobe Experience Manager developers, it’s often the difference between solving a problem in 10 minutes versus burning an entire afternoon searching through Adobe’s documentation maze.
Context
Adobe Experience Manager is built on a fascinating stack of open-source technologies—Apache Sling, Jackrabbit Oak, Apache Felix OSGi—wrapped in proprietary tooling and enterprise licensing. This creates a peculiar documentation problem: official Adobe docs cover the proprietary layers but often gloss over the OSS foundations, while Apache project docs explain Sling and JCR beautifully but don’t address AEM-specific quirks. Add to this a fragmented community spread across consulting company blogs, individual Twitter accounts, Stack Overflow, and Adobe’s own forums, and you have an ecosystem where finding the right answer requires knowing exactly where to look.
Paul Rohrbeck’s aem-links repository emerged as a crowdsourced solution to this fragmentation. Rather than building another tool or framework, it curates the collective knowledge of the AEM community into a navigable structure. Think of it as the Awesome List for AEM, but with more opinionated curation and a focus on practical problem-solving. The repository organizes hundreds of links into categories covering component development with HTL/Sightly, Dispatcher configuration nightmares, OSGi bundle debugging, and the arcane art of JCR query optimization. For developers joining an AEM project, this repository functions as an informal onboarding curriculum that no single company’s internal wiki could match.
Technical Insight
What makes aem-links valuable isn’t just breadth—it’s the way it maps the AEM technology stack to specific resources. The repository is organized around how developers actually work with AEM’s architecture, not how Adobe’s marketing materials describe it.
Take the Sling section as an example. AEM sits atop Apache Sling, a RESTful web framework that maps HTTP requests to JCR content through resource resolution. When you’re debugging why your custom servlet isn’t catching requests, you need to understand Sling’s resource resolution chain, script resolution order, and servlet ranking. The repository links directly to Sling’s resource resolution flowchart, practical examples of custom ResourceResolverFactory usage, and—crucially—cheat sheets for curl commands that let you inspect what Sling is actually doing:
# Check effective resource type resolution
curl -u admin:admin http://localhost:4502/content/mysite/page.json
# Force specific selector/extension for testing
curl -u admin:admin http://localhost:4502/content/mysite/page.model.json
# Inspect Sling servlet/script resolution
curl -u admin:admin "http://localhost:4502/system/console/servletresolver?url=/content/mysite/page.html&method=GET"These aren’t documented well in Adobe’s official materials because they’re Sling fundamentals, but they’re essential for AEM troubleshooting. The repository bridges this gap by linking to both the Apache Sling documentation and AEM-specific blog posts that show these techniques in context.
The cheat sheet section demonstrates particularly strong curation choices. It includes practical incantations for common tasks that every AEM developer Googles repeatedly: Query Builder syntax for finding nodes with specific properties, Dispatcher flush configurations that actually work in production, Maven commands for deploying only changed bundles during development. Here’s a Query Builder example the repository highlights for finding all cq:Page nodes modified in the last week:
path=/content/mysite
type=cq:Page
orderby=@jcr:content/cq:lastModified
orderby.sort=desc
daterange.property=jcr:content/cq:lastModified
daterange.lowerBound=2024-01-01T00:00:00.000Z
p.limit=50This kind of practical reference saves hours when you’re trying to build content migration scripts or audit tools. The repository links to the full Query Builder API documentation, but also to blog posts showing real-world patterns and performance considerations—like why you should avoid nodename predicates on large hierarchies.
Another standout section covers AEM DevOps tooling, an area where the official ecosystem is surprisingly sparse. The repository catalogs open-source projects like aemsync (watches filesystem changes and pushes to AEM in real-time, essential for rapid development), Gradle plugins for building AEM packages, Docker containers for local development environments, and CI/CD pipeline examples for Jenkins and Bamboo. This tooling layer exists because Adobe’s official tooling (like the repo tool or Content Package Maven Plugin) solves 80% of workflow needs but leaves developers building custom solutions for the remaining 20%.
The repository also functions as a social graph of AEM expertise, linking to active community members’ blogs and Twitter accounts. This matters because AEM problems are often solved through pattern recognition—seeing how someone at another company tackled a similar challenge with Dispatcher caching or OSGi configuration. The curated blog list points to consistently high-quality sources like The Real AEM, AEM.Design, and technical leads at agencies who regularly publish deep-dives on topics Adobe’s docs treat superficially.
Gotcha
The fundamental limitation of aem-links is the same as any curated link collection: link rot and content obsolescence. The repository itself notes that some blogs and tools are ‘outdated,’ but without automated link checking, there’s no systematic way to know which resources have disappeared or become irrelevant. I found several dead links to personal blogs where developers have moved on from AEM work, and some tool repositories that haven’t been updated since AEM 6.2 (several major versions ago).
More significantly, the repository shows its age in coverage of AEM as a Cloud Service, Adobe’s replatformed offering that fundamentally changed AEM’s architecture. Cloud Service eliminates direct server access, changes how Dispatcher works, restricts certain OSGi configurations, and shifts the entire deployment model. Many of the curl commands, server-side debugging techniques, and local development patterns documented in aem-links don’t translate directly. While the repository has started adding Cloud Service resources, the coverage is far thinner than for AEM 6.x on-premise deployments. If you’re exclusively on Cloud Service, you’ll find yourself returning to Adobe’s official Experience League documentation more often than this community resource.
Verdict
Use if: You’re working with AEM 6.x on-premise or hybrid deployments, onboarding new developers to an AEM project, troubleshooting problems that aren’t clearly documented in official channels, or exploring the open-source technologies (Sling, Oak, OSGi) that underpin AEM. The cheat sheets alone justify bookmarking this repository, and the curated blog list will save you hours of searching for quality AEM technical content. It’s also invaluable if you’re evaluating third-party AEM tools and want to see what the community has built to fill gaps in Adobe’s official ecosystem.
Skip if: You’re working exclusively with AEM as a Cloud Service and need up-to-date architectural patterns for the new platform, you need authoritative documentation for compliance or enterprise architecture review (stick to Adobe’s official Experience League), or you’re looking for interactive help with specific problems (Adobe’s community forums or Stack Overflow will get you answers faster). Also skip if you’re already deeply embedded in the AEM ecosystem with your own curated resources—this repository shines brightest for newcomers and intermediate developers who haven’t yet built their own mental map of AEM knowledge sources.
