Proposal Summary ----------------- Maven 4 is approaching release and brings substantial architectural changes (new provisioning model, resolver/model changes, revised extension and plugin APIs, and a distinct runtime layout from Maven 3). m2e, the Eclipse IDE's Maven integration, embeds and drives the Maven runtime directly, and its correct operation depends on deep, version-specific integration with Maven internals rather than only its public APIs. A working, in-progress effort already exists (eclipse-m2e/m2e-core PR #2053, "Use Maven 4 as the runtime for m2eclipse"), which demonstrates both the feasibility and the scope of the task: m2e needs to run on Maven 4 as its default embedded runtime going forward, while still offering Maven 3.9 as an optional, separately installable runtime for users who are not yet ready to migrate (as already done for the 3.9.6 runtime). Why This Cannot Rely on Volunteer Effort Alone ----------------------------------------------- - Depth of integration: m2e's core (project configuration, workspace resolution, incremental builds, launching, embedder lifecycle) is tightly coupled to Maven internals. Every internal change in Maven 4 potentially ripples through m2e's build path, dependency resolution, and IDE tooling. - Breadth of impact: The change touches nearly every subsystem of m2e: the embedded Maven distribution, dependency/model resolution, project configurators, connectors (m2e-extension) API compatibility, and regression testing across both Maven 3 and 4 runtimes simultaneously. - Compatibility risk: m2e must keep supporting existing Maven 3 projects and third-party m2e connectors while introducing Maven 4 support, requiring careful abstraction work and non-trivial testing across two runtime generations. - Sustained availability: This is not a one-off patch but a multi-month effort requiring continuous attention as Maven 4 stabilizes toward its final release, along with follow-up fixes as real-world projects and connectors surface issues. This level of sustained, predictable commitment is very hard to obtain from unpaid volunteer contributions, especially given the complexity and the risk of regressions for the entire m2e user base. - Ecosystem-wide benefit: Every Eclipse IDE user working with Maven depends on m2e. Without a properly funded, coordinated migration, the community risks either a delayed, poor-quality transition to Maven 4, or prolonged fragmentation between Maven 3 and Maven 4 tooling support. Proposed Scope of Funded Work ------------------------------ 1. Complete and stabilize the Maven 4 runtime integration started in eclipse-m2e/m2e-core#2053, including embedder lifecycle, dependency resolution, and project configuration paths. 2. Ensure continued support for Maven 3.9.x as an optional runtime, preserving backward compatibility for existing users and connectors. 3. Update and validate the m2e connector/extension API surface against Maven 4 so third-party m2e extensions continue to work or receive clear migration guidance. 4. Extend automated test coverage (unit/integration/build) to run against both Maven 3 and Maven 4 runtimes. 5. Address regressions and compatibility issues reported by the community during the Maven 4 stabilization period. Expected Outcome ----------------- A production-ready m2e release that runs on Maven 4 by default, with Maven 3.9 available as a supported fallback runtime, ensuring the Eclipse IDE remains a first-class, up-to-date environment for Maven-based development and avoiding a prolonged, unfunded, best-effort migration that could degrade the experience for the entire Eclipse Maven user base. Reference --------- - Work-in-progress PR: https://github.com/eclipse-m2e/m2e-core/pull/2053