Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Wait no more, here comes Maven 4!

Wait no more, here comes Maven 4!

You may feel that Apache Maven is done by now. For many people, Maven 3 is the only version of Maven they have ever used, and it has never seen large breaking changes. Those who have been using Maven 2 before may remember that transitioning to Maven 3 was a fairly painless journey.

Did you know it’s been roughly ten years since the first steps were made on the road to Maven 4? Yet it was only this year that the first beta releases of Maven 4 were published. What a release Maven 4 will be! In the last years, there have been numerous blogs, videos and talks about things that the Maven team has been working on. In this talk, we will bring everything together to give you a thorough review of the things that are ahead.

We will cover both internal changes and external changes, highlighting the impact it will have on you as a user of Maven. Whatever your role, if you use Maven you can’t miss this session.

Maarten Mulders

October 07, 2024
Tweet

More Decks by Maarten Mulders

Other Decks in Technology

Transcript

  1. Apache Maven History 2004 2005 2024 2010 1.0 (jul. ‘04)

    2.0 (oct. ‘05) 1.1 (jun. ‘07) 2.2.1 (nov. ‘09) 3.0 (oct. ‘10) 3.9.9 (aug. ‘24)
  2. TL;DR: With Maven 4… …your existing projects should (still) be

    buildable… …except some warnings you may have ignored about things you’re probably doing wrong… …that will become an error in this major release.
  3. Birds’ Eye View of Apache Maven 1. A Java application

    2. A plugin execution framework, targeted at building software 3. The “Core” plugins maintained by the Maven team
  4. Birds’ Eye View of Apache Maven Input • command-line arguments:

    plugin:goal or lifecycle phase + flags • system properties & environment variables • pom.xml • settings.xml Output • “it depends” (on all the inputs)
  5. Changes in Command Line Arguments 1. Success/failure conditions 2. Elvis-like

    operator for profiles and modules 3. Reactor 4. Old & New
  6. (1) Fail on Severity Plugin developer: public void execute() throws

    MojoException { log.error("Not enough coffee"); } [ERROR] Not enough coffee [INFO] ----------------------------------------------------------------------------- [INFO] BUILD SUCCESS [INFO] ----------------------------------------------------------------------------- [INFO] Total time: 2.557 s [INFO] Finished at: 2024-09-20T21:09:38+02:00 [INFO] ----------------------------------------------------------------------------- Maven:
  7. (1) Fail on Severity Two motivations: 1. By default, only

    Exceptions make the build fail → error messages do not! 2. “A warning is a failure in the making” → you want a warningless build. --fail-on-severity <LOGLEVEL>
  8. (1) Change in checksum verification • Maven verifies checksums of

    project dependencies. • In Maven 2 and 3, if that verification failed, it would be logged as a warning. • Corrupted artifacts should not, by default, be used for builds. • Maven 4 will by default fail the build in this case ◦ Suppress with -c or --lax-checksums if you really must.
  9. (2) Optional Profiles and Modules Using non-existing modules and profiles

    will fail the build… • -Pcodecoverage versus -P!codecoverage Unless... • -P?codecoverage versus -P!?codecoverage The ? prefix means “[de]activate if exists, but don’t fail if it doesn’t” Now logged twice (at start and at end): The requested optional profiles [codecoverage] could not be activated or deactivated because they do not exist.
  10. (3) The Reactor • All modules in a multi-module project

    that will be built. • Dependencies determine the order in which they will be built. • Maven 3’s --resume-from reduces the graph too aggressively.
  11. (3) Project Root Awareness With Maven 3, the Reactor would

    1. apply --resume-from (pruning the project graph) 2. attempt to build remaining modules
  12. (3) Project Root Awareness And this is how mvn clean

    install was born: a work-around for a bug! --resume-from can work* with previous mvn install.
  13. (3) Project Root Awareness With Maven 4, the Reactor will

    1. remembers the original project structure 2. apply --resume, --resume-from, or --projects 3. build remaining modules with the original project structure in mind
  14. (4) “Time to say goodbye” “Ineffective, only kept for backward

    compatibility” in Maven 3: • -cpu • -npr • -npu • -up
  15. Spot the SPOD Maven 2 and above is based on

    a Single Point Of Definition: pom.xml The pom.xml loaded during build is EXACTLY the same as the pom.xml that is installed or deployed 📃→📃
  16. What’s missing - Encoding (sourceEncoding, resourceEncoding, reportEncoding) * - Global

    dependency exclusion - Scope import in pluginManagement - Mixin POM fragments - QualityManagement section - Codeformatting section - Advanced control over plugin goal execution order - Separate site distributionManagement for release and snapshot - XML Attribute support - …
  17. Workarounds without changing the XSD (2) <dependency> ... <exclusions> <exclusion>

    <groupId>*</groupId> <artifactId>*</artifactId> </exclusion> </exclusion> <dependency>
  18. POM readers It is not just Maven itself - Artifact

    Repository Managers - Build tools - CI Servers - Dependency Updaters (e.g. Dependabot and Renovate) - Editors and IDEs - Further… POM consumers
  19. Build/Consumer POM Separation Build POM: The pom.xml in the source

    repository / codebase Configuration file for building a project Consumer POM: The pom.xml in the artifact repository Accessible via a Maven Coordinate (groupId:artifactId:version) e.g used as dependency, maven-plugin, maven-extension
  20. The new flow of a POM 1 Build POM This

    is pom .xm l in your codebase 2 Enriched POM (internal) Resolve required elem ents 3 Consum er POM (generated) Reduce to m odelVersion 4.0.0
  21. Parent and redundancy <parent/> Local system Artifact Repository groupId resolvable

    via relativePath* required artifactId version relativePath useful useless [maven-release-plugin] prepare release maven-3.9.9 · apache/maven@8e8579a (github.com)
  22. Dependencies and redundancy <dependency/> Local system Artifact Repository groupId required

    artifactId required version required In case of multimodule dependencies
  23. Dependencies and redundancy <dependency/> Local system Artifact Repository groupId required

    required artifactId required required version required In case of multimodule dependencies
  24. Dependencies and redundancy <dependency/> Local system Artifact Repository groupId required

    required artifactId required required version resolvable via reactor (via modules) required maven/pom.xml at 8e8579a9e76f7d015ee5ec7bfcdc97d260186937 · apache/maven (github.com) In case of multimodule dependencies
  25. CI Friendly versions … Externalize value of project version Introduced

    in Maven 3.5.0 3 placeholders: ${revision} ${sha1} ${changelist}
  26. The new flow of a POM 1 Build POM This

    is pom .xm l in your codebase 2 Enriched POM (internal, in m em ory) Add versions: m odelVersion, parent, CI-friendly, reactor dependencies 3 Consum er POM (generated) Rem ove local system entries: relativePath, m odules
  27. Will a consumer POM only contain dependencies? No, we don’t

    know what consumers read from the pom.xml When the build/consumer pom separation mechanism fully works, it will open the possibility for such a file (with explicit dependencies)
  28. The new flow of a POM 1 Build POM This

    is pom .xm l in your codebase 2 Enriched POM (internal, in m em ory) Add versions: m odelVersion, parent, CI-friendly, reactor dependencies 3 Consum er POM (generated) Rem ove local system entries: relativePath, m odules Rem ove/transform new er m odelVersion features
  29. Introduce "bom" packaging • A BOM should only contain the

    (public) modules of a multi-module project. These are the versions that MUST be in sync within another Maven project. • "bom" packaging rewrites the dependencyManagement applying the parents version • Details are at MNG-7879
  30. Application Lifecycle Management ❏ Cleanup of dependencies, both on Core

    and Plugins ❏ Lots of upgrades to external dependencies ❏ Introduction of a few new ones ❏ More fine-grained modularity inside Maven Dependency count Total age Average age 3.9.9 35 24479 days (~ 67 years) 699 days (~ 1,9 years) 4.0.0-beta-4 40 23864 days (~ 65 years) 568 days (~ 1,5 years)
  31. New lifecycle phases: pre-* and post-* • Makes it easier

    to hook executions into a precise point of the default lifecycles • Even more fine-grained ordering by using the [xxx] ordering: after:compile[100] after:compile[200]
  32. A project-local repository • Further prevents “polluting” the user repository

    ◦ Unless, of course, you still use mvn install - but you don’t do that anymore, do you? • Only contains the produced artifacts for that project, not the consumed ones.
  33. ${pom.*} expressions no longer work • ${pom.*} expressions were already

    deprecated in Maven 3 • You had 10+ years to remove them… Now we “help” you a bit 🦹 • Simply doesn’t work anymore → it has become a literal value now.
  34. Runtime requirement: Java 17 Why? • Unlocks new language features.

    • Require a more secure runtime. Maven 2.0 2005 Java 1.4 Maven 2.2.1 2009 Java 5 Maven 3.0 2010 Java 5 Maven 3.9.9 2024 Java 8 Maven 4.0 ? Java 17
  35. Runtime requirement: Java 17 😡 So My Java 8 Project

    Has To Migrate To Java 17 All Of A Sudden?! 😌 Relax! • If your runtime supports the desired target, ◦ define maven.compiler.source and maven.compiler.target properties as 1.8. ◦ define maven.compiler.release property for 11 and up. • Otherwise, use Toolchains: “A toolchains is a way to specify the path to the JDK to use for all of those plugins in a centralised manner, independent from the one running Maven itself.”
  36. Cosmetics: use those (ultra) wide screens! • Maven 3 was

    still in 80’s mode and cropped most output at 80 chars per line • Maven 4 catches up and uses full width or falls back to 130 chars
  37. Default plugin versions upgraded • Super POM (the java.lang.Object of

    any project) declares default versions for maven-*-plugin • Subject to change with every release of Maven • Better explicitly specify the versions you use • Maven will now issue a warning if you rely on Super POMs values