My Take Aways from adaptTo() 2018

In September 2018 I’ve attended adaptTo() the fifth times in a row 4th times. Unfortunately I missed adaptTo() 2017 but I visited the conf in 2018 again. This year the organizers made the decision to rent a bigger venue in Potsdam, Germany.


adaptTo() is a technical meetup aimed at developers using the Apache Sling, Jackrabbit/Oak and Felix stack. 2018 was the eighth edition. Sessions also covered commercial implementations such as Adobe Experience Manager, with a particular focus on how these products leverage the Sling stack.

adaptTo() 2018 had 25 talks plus lightning talks, a playground session, hands-on labs and about 270 participants.
The slides and source code (if applicable) can be downloaded from the adaptTo() web site:

Below are my take aways from the conference.

Best practices

  • Integrating a modern frontend framework
    • This is one of the most important decisions/activities on AEM projects.
    • In the talk you can learn about how to choose a modern frontend for an AEM project.
    • They recommend the following setup
      • Use Webpack to manage the frontend build tasks
      • Store the frontend code in component folders
      • Traverse the component folders for finding, compiling the frontend sources
    • There is a maven frontend plugin “Maven-node-grunt-gulp-npm-node-plugin to end all maven-node-grunt-gulp-npm-plugins.”
    • Be careful with lazy loading (of below the fold content) from SEO perspective
      • Use server side rendering techniques
    • Here you can read a lot more about Robust Configurations for AEM
  • SPAs
    • Adobe releases the SPA editor for AEM in these days.
    • It is based on the Sling model exporters (@Exporter annotation)
      • There will be a demo site: We.Retail Journal
    • Alternatives
      • Generic React helpers and components supporting AEM authoring.:
      • React DOM Components: this is an alternative for those who cannot invest into the full SPA editor
  • Migrating to Touch UI
    • My key take aways here:
      • Reuse the existing content data structure in JCR (e.g. ensure the touch UI multified uses the same persistence)
      • Ensure co-existence of classic + touch components and their clientlibs
      • Avoid coralui 2 components and deprecated coralui 3 components
      • Be aware of AEM’s sustainable upgrades approach, which raises a numer of constraints regarding what OOB functionality can or can’t be overlaid.
  • Modern authentication in Sling with OpenID Connect and Keycloak
    • Keycloak
      • Free, backed by Redhat
      • Supportsseveral SSO protocols: OpenID Connect, SAML, CAS
    • The approach
      • Authentication: Servlet filter, authentication handler
      • Authorization: Keycloak access control
      • User provisioning: external identity data exchange solution is proposed, e.g. SCIM
  • Integration of web apps into AEM sites
    • There was a great summary of the various approaches, highlighting the pros/cons. Look at the slides if you need to implement the same.
  • Content invalidation
    • This presentation filled a gap. They covered the topic of content invalidation in a thorough but enjoyable session. We learnt about the caching layers, invalidation models.
    • A few key learnings
      • Never purge the entire cache. Invalidate as precisely as possible.
      • Plan invalidation at the beginning of the project. Don’t leave it to the end.
      • It is possible to setup script on the DSP that can perform extra work when DSP cache is cleared. E.g. invalidate related resources or clear CDN cache by the DSP script.
      • Use the power of the Surrogate-Key HTTP response header to invalidate all pages that e.g. use a certain layout. Not supported by Adobe DSP, but other caches (Fastly) support it.
  • How to analyze and tune deployments & upgrades
    • In this presentation we got a great overview of the evolution of upgrades from Adobe managed services.
    • They’ve analysed many projects to come up with the best approach for sustainable upgrades.
    • If you have a huge (really huge!) repository and need to upgrade, look at their presentation.
  • Cluster deployment using Docker
    • Many of us have already realized container based AEM deployments.
    • However in this presentation they came up with a new idea that solves the problem of the monolithic, shared repository, in order to make AEM a better fit to Docker based deployments.
    • The idea is to use the composite node store, and store the read-only parts in the docker image (/libs, /apps), while storing contents in the shared repository.
    • Those who are interested can sign up the AEM Docker beta program.


  • Sling developer tooling
    • The community recognized that the market share of IntelliJ IDEA is higher than that of Eclipse.
    • Refactoring of the Sling dev tools was initiated to support easy porting to other IDEs
    • IDE support
      • Eclipse
      • IntelliJ IDEA
      • Netbeans (PoC only)
      • + CLI (command line)
  • Maven archetypes for AEM
    • There are 3 popular archetypes
      • The official one from the Adobe Marketing Cloud
      • – This is the most feature rich archetype
        • Webpack support
        • features (CONGA, AEM mocks)
        • Feature flags to control what is needed in the resulting project
      • Lazybones templates by Adobe consulting
        • A more interactive project creation tool that I would position between the above two
    • We also learnt about a configuration management archetype for setting up AEM infrastructure and application.
      • Ansible automation – used for cloud deployment provisioning
      • Terraform – for AWS resource generating
      • Can be used to create local environment with Vagrant
      • Sensitive data encrypted using Ansible Vault
      • CONGA is used instead of runmode specific configurations
  • Gradle AEM plugin
    • An AEM plugin to build rapidly AEM applications using Gradle Build System Gradle Sling plugin – fork of the AEM plugin
  • Felix search plugin
    • A useful Felix plugin that searches for classes in OSGi console, de-compiles into java code and makes the code download able
  • System ready framework
    • This is an upcoming solution for checking if AEM system is ready. This is a typical issue for those who want to automate AEM deployments and need to know when the system has started, finished indexing, etc.
  • Easy content upgrade with Groovy Console
    • Groovy Console is a great tool. But these people made it even greater by adding many new features
      • Automated script execution on deployment time
      • Consolidated history
      • Runmode support
      • More features on the UI (batch execution, etc.)
      • Health check
      • And many more…
  • AEM sync tool
    • AEM sync tool is just a handy tool that pushes code changes to AEM instance(s) upon a file change.

Coming soon…

In my next post I’ll describe my take aways from the following topics:


  • Toughday
  • AET – website monitoring with automated exploratory
  • Karate – HTTP API testing
  • JUnit 5 and Sling/AEM Mocks

Trending topics, outlook to coming features

  • Java9 and OSGi R7
  • Event driven, serverless solutions with Openwhisk
  • Blockchain
  • Feature model
  • Sling scripting reloaded

Leave a Reply

Your email address will not be published. Required fields are marked *

Pin It on Pinterest