On 25 March 2010 17:40, David Jencks <[email protected]> wrote: > I already said this on march 1 but there was more stuff in that email so > maybe everyone missed it and I could be considerably more explicit. > > DON"T try to use the root pom to release anything and don't try to release > it. It's only there for convenience. Judging by the recent posts I think it > causes a lot more trouble than it is worth and should be removed.
Agreed - we discussed not releasing every top level module anyway. spi-fly is one. In addition there are four modules in samples ariestrader-sample, blog, transation-sample and blueprint-sample-idverifier - but only ariestrader-sample and blog have instructions on the wiki so I think we should only release those two. Does this cause an issue? Is it a case of release the whole of the top level module or none of it, or can we release a subset of the modules under samples? > > I don't know the exact order to release subprojects in. Someone will have to > figure it out. You can't release in the wrong order because there will be > snapshots which will fail the build. I'm pretty sure it starts: > > - parent > -eba-maven-plugin > > For each subproject run: > > mvn versions:use-releases > svn commit -m "updated to latest releases" > mvn release:prepare -Papache-release > mvn release:perform -Papache-release so you prefer doing the first two steps manually - it seems the mvn release:prepare will handle this interactively. Is there a hidden dragon in allowing mvn release:prepare doing the versions:use-releases under the covers? It's a trivial difference, but just something I'd like to know. > > The first two steps should be unnecessary for the parent pom. > > The versions plugin will find the release candidates from earlier subprojects > and update the poms to use them instead of the snapshots. Presumably it's finding these in the local .m2 repo rather than on the nexus staging area? Thanks, Jeremy > > > thanks > david jencks > >
