DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Two Engines, One Query: DuckDB Inside Neo4j
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Wasm Inside Neo4j: Building the Example That Didn't Exist
  • OpenAPI From Code With Spring and Java: A Recipe for Your CI

Trending

  • The Warning That Never Stops the Agent
  • Beyond HTTP Handoffs: Build Durable Agent-to-Agent Services With Temporal Nexus
  • Why Databricks and Snowflake Speak the Kafka Protocol: Ingestion vs Architecture
  • Android Application Security: Android Application Architecture

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Coding
  3. Java
  4. The Flatten Maven Plugin

The Flatten Maven Plugin

In this post, we will learn to separate between build and consumer POMs in Maven's current version with the help of the Maven Flatten plugin.

By 
Nicolas Fränkel
·
Feb. 01, 22 · Analysis
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
6.8K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

One of the Apache Maven committers recently wrote about their plans for Maven 5. I consider the following one of the most significant changes:

In summary, we need to make a distinction between two POM types:

  • The build POM, stored in the project source control, that uses v5 schema for build time, requiring a new Maven version able to use the new features associated to the new schema.
  • The consumer POM, that is published to Maven Central in the good old v4 schema, so every past or future build tool can continue to consume pre-built artifacts as usual for their dependencies.

It's an important dichotomy that escaped me for a long time:

  • Consumers of the POM require some data, e.g., users who have the project in their dependencies list
  • Binary(ies) builders require other data

There are additional concerns. For example, variables make sense for the project's developers to leverage the DRY. For consumers, it's an extra layer of indirection that makes understanding the POM harder.

On Reddit, user pmarschall mentioned they were already separating between the concerns in Maven's current version with the help of the Maven Flatten plugin. It got me interested, and I wanted to try it. For that, I used the Spring Pet Clinic project - commit a7439c7.

Usage is very straightforward. Just add the following snippet in the plugins section:

XML
 
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>flatten-maven-plugin</artifactId>
    <version>1.2.5</version>
    <configuration>
    </configuration>
    <executions>
        <execution>
            <id>flatten</id>
            <phase>process-resources</phase>
            <goals>
                <goal>flatten</goal>
            </goals>
        </execution>
        <execution>
            <id>flatten.clean</id>
            <phase>clean</phase>
            <goals>
                <goal>clean</goal>
            </goals>
        </execution>
    </executions>
</plugin>


Now, if you execute the Maven process-resources phase, the plugin will create a shortened version of the POM, named .flattened-pom.xml. Compared to the initial POM, the flattened POM has only three sections in addition to the coordinates: licenses, dependencies, and repositories. Additionally, Maven has resolved all variables. If you run the install phase and then check your local Maven repository, you'll notice the POM matches the flattened POM, not the main one. If you want to generate the flattened POM but not replace the main one, use -DupdatePomFile=false.

By default, the plugin keeps only the licenses, dependencies, and repositories sections. You can configure which sections you keep and don't via the POM. For example, the plugin removes name, but you can keep it easily if needed. Just add the relevant configuration:

XML
 
<configuration>
    <pomElements>
        <name>keep</name>
    </pomElements>
</configuration>


The above method gives you the most flexibility. However, developers of the plugins have already thought about which configuration bundles make sense and offer them out-of-the-box. Here's an excerpt from the documentation that describes them:

Mode Description
oss For Open-Source-Software projects that want to keep all FlattenDescriptor optional POM elements except for repositories and pluginRepositories.
ossrh Keeps all FlattenDescriptor optional POM elements that are required for OSS Repository-Hosting.
bom Like ossrh but additionally keeps dependencyManagement and properties. Especially it will keep the dependencyManagement as-is without resolving parent influences and import-scoped dependencies. This is useful if your POM represents a BOM and you do not want to deploy it as is (to remove parent and resolve version variables, etc.).
defaults The default mode that removes all FlattenDescriptor optional POM elements except repositories.
clean Removes all FlattenDescriptor optional POM elements.
fatjar Removes all FlattenDescriptor optional POM elements and all dependencies.
resolveCiFriendliesOnly Only resolves variables revision, sha1, and changelist. Keeps everything else. See Maven CI Friendly for further details.

Conclusion

The Maven Flatten plugin separates between build and consumer POMs. You don't need to wait until the release of Maven 5. It's a freebie, so if you're a library provider, you should probably consider using it.

To go further:

  • From Maven 3 to Maven 5
  • Flatten Maven Plugin
  • Flatten Mojo description and configuration
Apache Maven

Published at DZone with permission of Nicolas Fränkel. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Two Engines, One Query: DuckDB Inside Neo4j
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Wasm Inside Neo4j: Building the Example That Didn't Exist
  • OpenAPI From Code With Spring and Java: A Recipe for Your CI

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook