another small breakthrough in my understanding of Maven

[Marshall Schor <ms...@schor.com>]

 Yesterday, when releasing the small update to parent-pom-top, I had to release
also, the other build projects which depend on it, and recursively, those that
depended on those build build projects.

For instance:

parent-pom-top
  parent-pom-docbook (yes, I know, released anyways)
    parent-pom-eclipse-plugins
      parent-pom-eclipse-plugins-ibm-notice

etc.

In the diagram above, each indented item has as its parent, the one above.

So, when parent-pom-eclipse-plugins was released, it was first updated so its
parent went from

version 3 of parent-pom-docbook to
version 4 of parent-pom-docbook,

and its own version, updated because its <parent> changed, went from
 
version 4-SNAPSHOT to
version 4 (in the tag) to
version 5-SNAPSHOT (next version in trunk)

So the release process went something like this:

1) update parent-pom-top, release it (to the staging repo)
2) update the direct descendants of parent-pom-top, changing their <parent> to
refer to the just tagged level of the parent-pom-top (the <parent> element has a
version without the SNAPSHOT).
3) release the direct descendants.
4) recurse 2) and 3) ...

I realize now that the release plugin can do all of this for me, automatically
(much less room for silly mistakes).

Here's what I think will work (I'll try this out, the *next* ( :-) ) time
there's an update to the parent-poms).

1) Change the parent poms, to make them, in addition to being parents,
aggregators of just those other parent poms that are direct descendants that
need updating when the parent changes.  So, parent-pom-top would have a
<modules> section containing parent-pom-docbook, parent-pom-distr, and maybe the
5 resource bundles uima-assembly-single-project, uima-build-helper-maven-plugin,
uima-docbook-resource-bundle, uimaj-jar-resource-bundle, and
uima-docbook-olink.  This last is a maybe because it's not clear that these need
rebuilding always when the parent-pom-top changes - so I would tend to leave
them out until they're needed...

The <modules> section in a parent-pom is *not* inherited by child-poms, so
anything using these as parents should see no change.

2) Change the <parent> links of these, from having versions that are not
-SNAPSHOTs, to having the current -SNAPSHOT version in the trunk.

Now, imagine we release some part of this build tree (it doesn't have to be the
parent-pom-top).  Let's pick on parent-pom-docbook.  The release plugin will put
all of its <modules> descendants (recursively) into the reactor, and switch all
of the versons from XX-SNAPSHOT to XX, and tag that, and then update the trunk
with (XX+1)-SNAPSHOT versions.

Then it will check out the tag, and deploy that to the staging repository.

So - it does everything I've been doing manually, automatically, I think.

With this process, we have a choice of keeping the versions all tied together
(e.g., all the parent-pom-xxx versions the same) or not - I think it works fine
both ways.

If anyone sees holes in this, please let me know.

-Marshall (slowly climbing the learning curve on getting the most out of Maven)