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 M1111/ 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 M1111/ 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 M1111/ 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. trunk/ M1/ pom.xml M11/ pom.xml M111/ pom.xml M1111 M1112 M12 and M1 can reference M11 as submodule with "<module>../M11</module>" in modules section. I knew before that M11 could reference M1 as parent using "<relativePath>../M1/pom.xml</relativePath>". Modules which are always released together are on same scm tree and this is in line with Maven assumptions. With this structure aggregation works and using -N switch could be enough to limit release process to current module (tree) only, with only downside being that maven module and scm hierarchy do not match, but that's a minor anyway, mitigated with module naming strategy. Any other known downsides of this flat structure organization? Hopefully there will be no issues with plugins and this structure. Regards, Stevo. On Fri, Sep 9, 2011 at 4:53 PM, Stephen Connolly <[email protected]> wrote: > no. > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 9 Sep 2011 04:15, "Stevo Slavić" <[email protected]> wrote: >> Hello Maven users, >> >> Can prepare-mojo of maven-release-plugin be configured which files >> and/or directories to include and/or exclude from the (svn) tag? Just >> like with -N submodules can be excluded from the release build, I'd >> like to exclude them from the tag as well, or in other words include >> only current module files in the tag. >> >> Regards, >> Stevo. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
