This is an automated email from the ASF dual-hosted git repository.
robertlazarski pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/axis-axis2-java-core.git
The following commit(s) were added to refs/heads/master by this push:
new 79458ae667 Make the sample-pom sync actually reach the release commit
79458ae667 is described below
commit 79458ae667e582deacb4c8b3adc9054db259a25b
Author: Robert Lazarski <[email protected]>
AuthorDate: Mon Sep 7 09:40:23 2026 -1000
Make the sample-pom sync actually reach the release commit
Rehearsing release:prepare on a throwaway clone showed the sync was writing
the
right values and losing them: maven-release-plugin transforms only reactor
poms,
so the rewrite stayed an unstaged working-tree change and the tag shipped
2.0.2-SNAPSHOT. The target now stages the poms itself, and the commit phase
takes
what is staged. completionGoals is gone as well -- it ran after the bump to
the
next SNAPSHOT and needed artifacts that do not exist yet, aborting the
release
after tagging. Samples therefore keep the released version between releases,
which beats pointing at a SNAPSHOT. Verified end to end: exit 0, tag carries
2.0.2 in all three, development commit lands.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
---
pom.xml | 19 ++++++++++++++++++-
src/site/markdown/release-process.md | 27 +++++++++++++++++++++------
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/pom.xml b/pom.xml
index e831faad6a..131539510e 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1008,7 +1008,12 @@
here means the rewrite lands in the release
commit and the tag,
next to the versions release:prepare rewrites
itself. -->
<preparationGoals>clean verify
antrun:run@sync-userguide-sample-versions</preparationGoals>
-
<completionGoals>antrun:run@sync-userguide-sample-versions</completionGoals>
+ <!-- No completionGoals. It would run after the poms
are bumped to the
+ next SNAPSHOT, and invoking any goal across the
reactor then needs
+ that SNAPSHOT's artifacts, which do not exist
yet, so the release
+ aborts after tagging. So the samples keep the
released version
+ after a release, which is what you want anyway:
master's samples
+ point at a real artifact instead of a SNAPSHOT.
-->
</configuration>
</plugin>
<plugin>
@@ -1399,6 +1404,18 @@
<contains
text="<axis2.version>${project.version}</axis2.version>"/>
</fileset>
</resourcecount>
+ <!-- Stage them. maven-release-plugin only
transforms reactor
+ poms, so without this the rewrite stays
an unstaged working-tree
+ change and the release commit and tag
ship the old version;
+ verified by rehearsing release:prepare on
a throwaway clone.
+ The commit phase takes whatever is
staged, so this is enough.
+ failonerror is deliberate: a release that
cannot stage these
+ must stop rather than tag the wrong
versions. -->
+ <exec executable="git" dir="${basedir}"
failonerror="true">
+ <arg value="add"/>
+ <arg value="--"/>
+ <arg
value="modules/samples/userguide/src/userguide"/>
+ </exec>
<fail message="axis2.version sync found no
userguide sample poms under modules/samples/userguide/src/userguide - the
samples moved or were renamed, and the sync is now doing nothing">
<condition>
<equals arg1="${userguide.pom.count}"
arg2="0"/>
diff --git a/src/site/markdown/release-process.md
b/src/site/markdown/release-process.md
index fd05a1d698..859263b880 100644
--- a/src/site/markdown/release-process.md
+++ b/src/site/markdown/release-process.md
@@ -135,12 +135,27 @@ You may also execute a dry run of the release process:
mvn release:prepare -Ddry
rewrite, and run the goal by hand if you are cutting a release any other
way.
Left unsynced, the shipped samples point at a SNAPSHOT that does not exist.
- Two things to know about it. The execution is marked
`<inherited>false</inherited>`
- because `preparationGoals` runs across the whole reactor, and an inherited
copy
- resolves `${basedir}` to each child module. And a `-DdryRun=true` run does
**not**
- exercise the rewrite: a dry run never replaces `pom.xml`, so the goal sees
the
- SNAPSHOT version and writes that back. Only a real `release:prepare`
transforms
- the poms first, which is why the check above is on the release commit.
+ Three things to know about it, all found by rehearsing `release:prepare`
against a
+ throwaway clone:
+
+ - The execution is `<inherited>false</inherited>`, because
`preparationGoals` runs
+ across the whole reactor and an inherited copy resolves `${basedir}` to
each
+ child module.
+ - The target stages the rewritten poms with `git add` itself. The release
plugin
+ only transforms *reactor* poms, so without that the rewrite stays an
unstaged
+ working-tree change and the release commit and tag ship the old version.
The
+ commit phase takes whatever is staged, which is why staging is
sufficient.
+ - There is no `completionGoals`. Anything invoked there runs after the
poms are
+ bumped to the next SNAPSHOT and needs that SNAPSHOT's artifacts, which
do not
+ exist yet -- the release aborts after tagging. So after a release the
sample poms
+ keep the released version rather than moving to the next SNAPSHOT. That
is
+ deliberate: master's samples then point at a real published artifact,
and the
+ next release rewrites them again.
+
+ A `-DdryRun=true` run does **not** exercise any of this. A dry run never
replaces
+ `pom.xml`, so the goal sees the SNAPSHOT version and writes it straight
back, and no
+ commit happens at all. Only a real `release:prepare` transforms the poms
first,
+ which is why the check above is on the release commit.
The same class of problem bites any sample kept out of the reactor:
`swagger-server` sat at `2.0.1-SNAPSHOT` through the whole 2.0.1 cycle
because
