Adopt Maven Daemon (mvnd) as the default build engine in Cloud Manager pipelines | Community
Skip to main content
R
Adobe Employee
rwunsch-adobeAdobe Employee
Adobe Employee
May 26, 2025
New

Adopt Maven Daemon (mvnd) as the default build engine in Cloud Manager pipelines

  • May 26, 2025
  • 1 reply
  • 373 views

 

Request for Feature Enhancement (RFE) Summary: Introduce the Apache mvnd (Maven Daemon) wrapper in Adobe Cloud Manager so that the build step can reuse a long-lived JVM, parallelise module compilation, and dramatically cut cold-start overhead. This change targets only the build phase; the deploy phase likely remains untouched.
Use-case: Large, multi-module AEM as a Cloud Service projects (often 10 + modules) can spend several minutes just starting Maven and resolving plugins for every pipeline run. In busy CI/CD setups (feature branch builds, frequent merges, scheduled quality gates) these wasted minutes quickly accumulate, slowing feedback loops and consuming CI minutes.
Current/Experienced Behavior:

  • Cloud Manager invokes the stock mvn CLI in a fresh container for each build.

  • Each invocation spins up a new JVM, scans plugins, and builds modules sequentially.

  • Typical build duration for a representative 10-module project: 9–11 minutes, of which ~1-3 minutes are Maven start-up and plugin scanning.

  • Developers compensate by using mvnd locally, but must still wait for slower pipeline feedback.
Improved/Expected Behavior:

  • Cloud Manager containers start an mvnd daemon once, then execute build goals through the daemon for the lifetime of the build step.

  • Parallel module compilation (default --threads=auto) and reused class-loaders remove the repeated start-up cost (potentially the resources of the build-pod(s) need to be increased to provide more CPUs to work with in parallel).

  • Anticipated build-step time-savings: 25-40 % on typical AEM multi-module projects (confirmed in local benchmarks and community posts).

  • No impact on deployment logic; output artefacts (all-, ui.apps, ui.content) remain identical.
Environment Details (AEM version/service pack, any other specifics if applicable): ----
Customer-name/Organization name: ----
Screenshot (if applicable): ----
Code package (if applicable):

----

 

Maven-Deamon (mvnd):  https://github.com/apache/maven-mvnd

Article: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-blogs/speed-up-local-development-in-multi-module-aem-projects/ba-p/738507  

 

    1 reply

    R
    Adobe Employee
    rwunsch-adobeAdobe EmployeeAuthor
    Adobe Employee
    May 26, 2025

    Here are some comments I have received on the idea:

    Short answer: today Cloud Manager only invokes plain mvn (see the three hard-coded commands in the build container) and there is no supported switch to replace it with Apache Mvnd. Engineering has looked at it a few times, but because the build container is already single-use, dependency-cached, and runs each module in parallel with the -pl/reactor logic it hasn’t yet justified the footprint/risk of introducing another daemon process.

    What the build step does now
       • Every execution starts a fresh Ubuntu-based container and runs exactly these commands

    • mvn --batch-mode org.apache.maven.plugins:maven-dependency-plugin:3.1.2:resolve-plugins
    • mvn --batch-mode org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean -Dmaven.clean.failOnError=false
    • mvn --batch-mode org.jacoco:jacoco-maven-plugin:prepare-agent package

         (see https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/create-application-project/build-environment-details#build-environment-details ).
       • Artifacts and the Maven dependency cache persist between runs, so most of the wins Mvnd brings on a local laptop (warm JVM, plugin-classpath reuse) are already covered by the shared cache.

    Why Mvnd hasn’t been enabled so far
       • Daemons stay resident; our build containers are destroyed after the step, so the JVM startup cost returns every run.  
       • Parallelism: the container already allows parallel module builds with -T  - a limiting factor here is memory  - but memory cannot be increased unlimited on the pods.
       • Stability: the current build layer is used by hundreds of thousands of pipelines; changing the Maven engine needs extensive soak testing to avoid regressions in Surefire, JaCoCo, Oak index generation, etc.

    Terms & ConditionsAccessibility statement

    Loading footer...