pom-ordering

motlin's avatarfrom motlin

Enforce Maven POM dependency ordering rules. This skill should be used when editing pom.xml files.

⭐0stars🔀1forks📁View on GitHub🕐Updated Dec 22, 2025
[Developer Tools]

When & Why to Use This Skill

The pom-ordering skill is a specialized utility for Java developers designed to automate and enforce strict Maven POM dependency ordering rules. It optimizes pom.xml files by grouping dependencies by scope (compile, runtime, test) and specific groupIds, while implementing a standardized XML region comment structure to significantly improve configuration readability and project maintainability.

Use Cases

  • Standardizing Project Structure: Automatically organize pom.xml files across multi-module Maven projects to ensure all team members follow a consistent dependency layout.
  • Refactoring Legacy Configurations: Quickly clean up disorganized or bloated Maven files by reordering dependencies into logical, commented regions.
  • Improving Code Reviews: Reduce noise in pull requests by maintaining a predictable order for third-party libraries and internal modules.
  • Dependency Management Efficiency: Use structured region comments to easily locate and manage specific groups of libraries like Liftwizard, Dropwizard, or Jakarta dependencies.
namepom-ordering
descriptionEnforce Maven POM dependency ordering rules. This skill should be used when editing pom.xml files.

Ordering Rules

First, group dependencies by scope (compile, runtime, test).

Within each scope, group by groupId in this order:

  1. First-party (${project.groupId} or modules within the project)
  2. cool.klass
  3. io.liftwizard
  4. org.eclipse.collections
  5. io.dropwizard
  6. Other third-party libraries
  7. Jakarta

Region Comment Structure

Use region comments for each groupId+scope combination:

  • <!--region Project compile dependencies -->
  • <!--region Project runtime dependencies -->
  • <!--region Klass compile dependencies -->
  • <!--region Klass runtime dependencies -->
  • <!--region Liftwizard compile dependencies -->
  • <!--region Liftwizard runtime dependencies -->
  • <!--region Compile dependencies --> (for other dependencies)
  • <!--region Runtime dependencies -->
  • <!--region Test dependencies -->

Close each region with <!--endregion [name] -->

Within some groups, use nested regions for further organization:

  • For io.liftwizard runtime: <!--region Liftwizard bundles --> then <!--region Liftwizard config-->
  • For io.dropwizard: core modules first, then specialized modules

Example Structure

<dependencies>

    <!--region Project compile dependencies -->
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>example-services</artifactId>
        <version>${project.version}</version>
    </dependency>
    <!--endregion-->

    <!--region Project runtime dependencies -->
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>example-domain-model</artifactId>
        <version>${project.version}</version>
        <scope>runtime</scope>
    </dependency>
    <!--endregion-->

    <!--region Liftwizard runtime dependencies -->
    <dependency>
        <groupId>io.liftwizard</groupId>
        <artifactId>liftwizard-graphql-reladomo-meta</artifactId>
        <scope>runtime</scope>
    </dependency>

    <!--region Liftwizard bundles -->
    <dependency>
        <groupId>io.liftwizard</groupId>
        <artifactId>liftwizard-bundle-cors</artifactId>
        <scope>runtime</scope>
    </dependency>
    <!--endregion-->

    <!--region Liftwizard config-->
    <dependency>
        <groupId>io.liftwizard</groupId>
        <artifactId>liftwizard-config-logging-logstash-console</artifactId>
        <scope>runtime</scope>
    </dependency>
    <!--endregion-->
    <!--endregion-->

    <!--region Test dependencies -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <scope>test</scope>
    </dependency>
    <!--endregion-->

</dependencies>