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

[#1]

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-devel... 

[#2]

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/usi... ).
   • 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.