Core Components

What Core Components are

Core Components are Adobe's maintained, open-source library of standard components: Title, Text, Image, Teaser, List, Breadcrumb, Navigation, Carousel, Container, Experience Fragment, Content Fragment, Embed, Form fields and more. They ship accessible markup, sensible authoring dialogs, Style System support, the Adobe Client Data Layer, and responsive image handling.

They are a real dependency of your project, versioned in pom.xml and developed at github.com/adobe/aem-core-wcm-components. The archetype wires them in for you.

The proxy pattern

You never use a Core Component directly by resource type, and you never copy its code. Instead you create a nearly empty component in your own project that inherits from it:

/apps/wknd/components/title
  .content.xml
    jcr:primaryType = "cq:Component"
    jcr:title = "Title"
    sling:resourceSuperType = "core/wcm/components/title/v3/title"
    componentGroup = "WKND - Content"

That is the whole component. It has no HTL of its own; everything is inherited. What this buys you:

• Your own resource type. Content references wknd/components/title, so you own the contract with your content.
• Upgrades become a one-line change. Moving from v3 to v4 is editing sling:resourceSuperType — your content does not move.
• Selective override. Add a title.html and you replace just the markup. Add a dialog snippet and you extend just the dialog. Everything you do not override keeps coming from Adobe.
• Your own component group, so authors see "WKND - Content" rather than a mixed list of Adobe internals.

Versioning

Core Components are versioned in the resource type path: .../title/v2/title, .../title/v3/title. Adobe's contract is that a version's behaviour and content structure stay stable, and breaking changes arrive as a new version alongside the old one.

So a major bump is not automatic. You change your proxy's sling:resourceSuperType deliberately, then test — because a new version may render different markup or expect a slightly different content structure. Old versions remain available, so migration happens component by component on your schedule.

The Components console

At Tools → General → Components you get a browsable list of every component on the instance. For each one you can see its title, group, resource type, the supertype it inherits from, and — usefully — which templates and policies actually allow it. When an author says "I can't find the Teaser component", this console tells you whether it exists, whether it is in a visible group, and whether the template's policy permits it.

Where custom code still belongs

You will still write components. The realistic split:

• Proxy only — Title, Text, Image, Breadcrumb, Navigation. Just inherit.
• Proxy plus overrides — Teaser or List where you need different markup or an extra dialog field.
• Genuinely custom — something with no Core equivalent: a product finder, an interactive map, a domain-specific widget. Day 21 builds one.