OK, thanks! Just wanted to check if I'm missing something without
going into plugin code.
I'm aware of Maven philosophy and release assumptions (
http://www.sonatype.com/people/2011/01/using-the-maven-release-plugin-things-to-know/
) and it works for me really well. But now I'm practically maintaining
a project with project structure which does not follow/adhere to the
Maven release assumptions, and I'm trying if possible to automate the
release process using maven-release-plugin.
Project structure is basically following:
svn_repo_path/
M1/
pom.xml
M11/
pom.xml
M111/
trunk/
pom.xml
M/
M1112/
branches/
tags/
...
M12/
pom.xml
M121/
trunk/
pom.xml
M1211/
M1212/
branches/
tags/
...
M13/
...
This is just a tiny fragment, but one can see the pattern. Now imagine
100+ modules. Yes, odd structure, with deficiencies and bad practices
(M1, M11, M12, and M13 were manually released and there are neither
tags nor branches support for them - ouch!). Notice that Maven module
hierarchy and module hierarchy on svn match so that is more obvious
from just looking at svn without tools displaying Maven dependency
graph.
But anyway from this I tried to reason and saw a requirement behind
the structure
- there was obviously requirement for ability to version and release
submodules like M111 and M121 independently
-- they contain different deployables of same project/product
-- can be changed and evolve at different rate
-- they certainly change more frequently than poms
-- but also M111 and M121 are always deployed together and
depend on each other at runtime
- while still being able to perform aggregated build
-- comes handy when e.g. whole project has to be upgraded to a
new platform and one want's to build all the modules together
- and having maven module hierarchy visible and match module directory
hierarchy on version control.
Requirement to be able to independently version and release all
modules (including poms) of a single project, and still be able to
execute aggregated build of complete project, and that scm (svn) and
Maven module hierarchy match is somewhat in contradiction with
mentioned Maven release assumptions.
If all modules shared the same version and were always released
together structure would be:
trunk/
M1/
pom.xml
M11/
pom.xml
M111/
pom.xml
M/
M1112/
...
M12/
pom.xml
M121/
pom.xml
M1211/
M1212/
...
M13/
...
tags/
branches/
If release plugin supported specifying tag includes/excludes this
would be enough, with nested structure as shown above one could
perform aggregated builds, but also version and release modules
independently - e.g. 1) release M111 independently like before but
also 2) be able to do the same with M11 only (release:perform with -N
and tag restrictions to exclude submodules) and as consequence of
changed M11 do the change and release of all of its submodules but no
need to change and release M12, M13, etc.
Since release plugin does not support limiting tag scope, to still be
able to version and release submodules independently, I see two
options:
- perform part of the release (of parent modules) manually or
- change project structure so it's more flat as following
trunk/
M1/
pom.xml
M11/
pom.xml
M111/
pom.xml
M/
M1112/
M12/
pom.xml
M121/
pom.xml
M1211/
M1212/
M13/
...
tags/
branches/
but in this last solution aggregated build support is lost, as well as
sense of hierarchy (svn module hierarchy and maven module hierarchy of
a given project do not match). Latter deficiency can be mitigated to
some extent using appropriate module naming strategy.
P.S.
Just before sending the post I tried and found out that for
aggregation to work structure can be flat, e.g.
