AGENT SKILL

update-sling-parent-pom

Use when the user asks to upgrade the Sling parent POM version in their project

License 许可
Apache-2.0
最近更新
2026-10-30
Stars
★ 0
Forks
2

01 前言 Front Matter

name
update-sling-parent-pom
description
Use when the user asks to upgrade the Sling parent POM version in their project

02 资源文件 16

03 SKILL.md 正文

Updating the Sling Parent POM

When to use

Use when the user asks to upgrade the Sling parent POM version in their project.

Instructions

  • record the current Java and Maven environment with java -version and mvn -version
  • run a baseline mvn clean verify if the current checkout is expected to support the current Java version
    • if the baseline build fails only because the current parent POM or project setup requires an older Java version, document that and continue
    • assume the unchanged project would pass with its required Java version; do not switch to version-specific Maven wrappers just to prove the baseline unless the user explicitly asks
    • if the baseline fails for a reason unrelated to the Java version, abort execution and inform the user of the root cause before changing the parent POM
  • check if any known workarounds exist, but do not remove them yet
  • if other repos in the same workspace/org use the same parent artifact and test patterns (e.g. pax-exam quickstart ITs), check whether one has already been migrated to the target parent version — its pinned test/IT dependency versions are a validated reference point and can save significant troubleshooting
  • identify the current version of the Sling parent POM in the user's project
  • determine the latest available Sling parent POM version for the applicable parent artifact
    • target the latest available version, not merely the next increment
  • check https://cwiki.apache.org/confluence/spaces/SLING/pages/284790344/Update+to+Parent+60for additional instructions. Follow any steps it documents that are not already covered by this skill's reference files
  • update the parent POM version
  • run mvn validate with the current Java version before running a full build
    • if mvn validate fails, fix any POM syntax issues first
    • if the new parent POM no longer manages some plugin versions, add explicit plugin versions for the affected plugins
    • if the new parent POM no longer manages some dependency versions, add explicit dependency versions for the affected dependencies
    • do not continue to clean verify until mvn validate succeeds
  • run a full mvn clean verify build with the current Java version
    • the goal is for the upgraded project to build successfully with the current Java version
    • if the build fails because Spotless formatting checks were introduced or changed by the new parent POM, run mvn spotless:apply, review the resulting formatting changes, and rerun mvn clean verify
  • if the project's CI runs a Java version matrix (check the Jenkinsfile or CI config; commonly includes versions newer than the one just used to verify), also verify with the highest JDK version in that matrix using the appropriate mvnNN wrapper (e.g. mvn21 clean verify for JDK 21 — see skills/README.md § Invoking Apache Maven with different Java versions) before considering the upgrade complete — some failures (e.g. felix-http-jetty-jdk21.md) only reproduce on newer JDKs and will not show up when verifying with the minimum required version alone
  • apply additional verification steps as needed if the specific version requires it
  • if workarounds were present before updating the parent POM version, check if they can be removed. If they are needed add them back

Do not touch the git repository state - no staging/unstaging, no commits, no pushes.

If the user separately commits and pushes the changes (e.g. to an open PR) and a CI build fails, fetch the raw log (e.g. a Jenkins job's consoleText endpoint) rather than a JS-rendered log viewer — rendered pipeline-explorer pages often don't expose the actual error text to a fetch tool. A "tests passed" summary alongside an overall build failure means the real failure is in a later stage (verify/IT/checks) — check the full log rather than stopping at the test summary.

Unsupported versions

The following historical versions are not supported and must be skipped:

  • 42
  • 50

Additional fixes

Use the following reference files when a matching migration issue or build failure appears.

Workarounds

04 同仓库更多 Skills