Conversation
WalkthroughReorganizes Maven build configuration across root and submodule POMs: moves deploy plugin into build/plugins with skip, adds central publishing, signing, source-attachment and javadoc/reporting configuration, and introduces a central profile that controls central-publishing execution and related plugins. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant Maven as Maven Build
participant Root as Root POM (build/plugins)
participant Module as Module POM (dat-cli / dat-servers)
participant Central as Central Publishing Plugin
Dev->>Maven: mvn clean deploy (-Pcentral?)
Maven->>Root: load top-level build/plugins & reporting
Maven->>Module: load module build/plugins
alt Profile: central active
Module->>Central: execute central-publishing-maven-plugin (sign, source attach, publish)
Central-->>Maven: publish artifacts to Central
else Profile: central inactive
Module->>Central: central-publishing execution phase = none (no-op)
note right of Module #D3F6D8: deploy plugin present but<br/>configured with <skip>true</skip>
end
Maven->>Dev: build result
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
dat-cli/pom.xml (1)
259-279: Consider using<skip>true</skip>instead of<phase>none</phase>to disable central-publishing-maven-plugin.Setting the execution phase to "none" works but is unconventional. The more idiomatic Maven approach is to use
<skip>true</skip>configuration, which is clearer and aligns with how the deploy plugin is disabled elsewhere in this PR.Consider applying this refactor if you want to standardize the disabling strategy:
- <plugin> - <groupId>org.sonatype.central</groupId> - <artifactId>central-publishing-maven-plugin</artifactId> - <version>0.9.0</version> - <executions> - <execution> - <id>injected-central-publishing</id> - <phase>none</phase> - </execution> - </executions> - </plugin> + <plugin> + <groupId>org.sonatype.central</groupId> + <artifactId>central-publishing-maven-plugin</artifactId> + <version>0.9.0</version> + <configuration> + <skip>true</skip> + </configuration> + </plugin>dat-servers/pom.xml (1)
33-54: Consider using<skip>true</skip>instead of<phase>none</phase>to disable central-publishing-maven-plugin.For consistency with dat-cli/pom.xml and the deploy plugin disabling strategy, consider using
<skip>true</skip>instead of<phase>none</phase>.pom.xml (2)
89-117: Javadoc configuration withdoclint=nonemay suppress important warnings.Setting
<doclint>none</doclint>disables Javadoc linting entirely. While this prevents build failures, it also hides potential documentation quality issues. Consider using selective lint targets (e.g.,<doclint>syntax,reference</doclint>) if you want stricter documentation checks.
202-223: GPG configuration withpinentry-mode loopbackis appropriate for CI/CD.This allows GPG to accept passphrases non-interactively, which is essential for unattended release automation. However, ensure that:
- The GPG key and passphrase are securely stored in CI/CD secrets (e.g., GitHub Secrets)
- The GPG private key is accessible in the build environment
- Only the
centralprofile uses this configuration (limiting signing exposure)If you need help setting up GPG keys or CI/CD secrets for the release pipeline, I can assist with guidance or scripts.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
dat-cli/pom.xml(1 hunks)dat-servers/pom.xml(1 hunks)pom.xml(4 hunks)
🔇 Additional comments (7)
dat-cli/pom.xml (1)
247-256: Verify parent pom.xml defines maven-deploy-plugin version in pluginManagement.The plugin configuration here omits the version tag, which relies on parent inheritance. Ensure the root
pom.xmlhasmaven-deploy-plugindeclared inpluginManagementwith an explicit version (this should be enforced by Maven best practices to avoid version conflicts).dat-servers/pom.xml (1)
20-31: Verify parent pom.xml defines maven-deploy-plugin version in pluginManagement.Same as dat-cli/pom.xml: this plugin configuration relies on parent inheritance for the version. Ensure consistency with the root
pom.xmlpluginManagement declaration.pom.xml (5)
41-41: SCM tag addition looks good for release automation.The
<tag>HEAD</tag>entry is appropriate for Git-based release workflows and will be used during Maven Release Plugin or similar tooling.
77-87: Maven Deploy Plugin version declaration is correctly placed in pluginManagement.This allows child modules to inherit the version (3.1.4) without re-declaring it, following Maven best practices. Ensure all child modules that reference
maven-deploy-pluginomit the version tag to use this inherited value.
120-145: Reporting section with dual javadoc report sets looks appropriate.The aggregate and default reportSets allow for both aggregated and module-level documentation generation, which is good for multi-module projects.
163-176: Maven Source Plugin configuration is correct for Maven Central.Attaching sources via
jar-no-forkgoal in the central profile is the standard requirement for Maven Central publishing. This ensures source JARs are generated alongside compiled artifacts.
224-237: Central Publishing Maven Plugin configuration aligns with new Maven Central publishing model.The use of
org.sonatype.central:central-publishing-maven-plugin(v0.9.0) withautoPublish=trueandwaitUntil=publishedis the recommended approach for modern Maven Central deployments (replacing the legacy Maven Deploy Plugin approach).Verify that the
publishingServerIdvaluecentralmatches the corresponding<server>entry in your Mavensettings.xmlor CI/CD credentials configuration (e.g., via GitHub Actions setup-java action).
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
pom.xml (1)
100-116: Consider whether javadoc attachment should apply to all modules.The
maven-javadoc-pluginis configured in the main build lifecycle with anattach-javadocsexecution (lines 108–115). This will attach javadoc JARs to all modules by default, which increases build time and artifact size.If javadoc attachments should only occur during central deployment, consider moving this execution into the
centralprofile, or verify that this behavior aligns with your project's requirements.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
pom.xml(3 hunks)
🔇 Additional comments (2)
pom.xml (2)
41-41: SCM tag metadata added for Maven Central.Adding
<tag>HEAD</tag>to the SCM section aligns with Maven Central repository requirements for proper release tracking.
147-241: Central profile configuration is well-structured for Maven Central deployment.The
centralprofile correctly isolates all central-specific plugins and configurations:
- maven-source-plugin: Attaches source JARs (required for central).
- flatten-maven-plugin v1.5.0: Resolves CI-friendly properties (
${revision}).- maven-gpg-plugin v3.2.8: Signs artifacts with GPG; pinentry-mode loopback configuration supports CI environments.
- central-publishing-maven-plugin v0.9.0: Handles publication with auto-publish and wait-for-published settings, appropriate for CI workflows.
The isolation via profile ensures these steps only execute when explicitly activated (
mvn -P central ...), which is the correct approach.
| <plugin> | ||
| <groupId>org.apache.maven.plugins</groupId> | ||
| <artifactId>maven-surefire-plugin</artifactId> | ||
| <version>3.5.3</version> | ||
| <configuration> | ||
| <skip>true</skip> | ||
| </configuration> | ||
| </plugin> |
There was a problem hiding this comment.
Configuring maven-surefire-plugin with <skip>true</skip> in the root pom's main build lifecycle will skip tests for all child modules unless they explicitly override this configuration. This breaks the standard Maven workflow where mvn clean package is expected to run tests.
This configuration should be moved to the central profile (lines 147–241) if tests should only be skipped during central deployment, or removed entirely if tests should always run.
Apply one of these fixes:
Option 1 (recommended): Move test skipping to the central profile only.
- <plugins>
- <!-- 打包时跳过测试 -->
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-surefire-plugin</artifactId>
- <version>3.5.3</version>
- <configuration>
- <skip>true</skip>
- </configuration>
- </plugin>Then add it inside the central profile's <build><plugins> section (around line 152):
+ <!-- 打包时跳过测试 -->
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-surefire-plugin</artifactId>
+ <version>3.5.3</version>
+ <configuration>
+ <skip>true</skip>
+ </configuration>
+ </plugin>Option 2: Remove test skipping entirely and ensure tests always run.
- <plugins>
- <!-- 打包时跳过测试 -->
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-surefire-plugin</artifactId>
- <version>3.5.3</version>
- <configuration>
- <skip>true</skip>
- </configuration>
- </plugin>Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In pom.xml around lines 91 to 98, the root build config sets
maven-surefire-plugin with <skip>true</skip>, which causes all modules to skip
tests; move this skip configuration into the existing central profile's
build->plugins section (around lines 147–241) so tests are only skipped during
central deployment, or remove the <skip>true</skip> entry entirely if tests
should always run; ensure child modules inherit the root pom behavior correctly
or explicitly override if needed.
Summary by CodeRabbit