On Mar 25, 2010, at 12:58 PM, Jeremy Hughes wrote: > 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.
release:prepare will update the versions of the projects being released by mvn release:prepare versions:use-releases will update the versions of the other aries projects you have just built release candidates for in the projects you are about to try to release in steps 3 and 4. So these are different functions and it's not a trivial difference. > >> >> 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? > yes. I haven't actually checked that this works but have a hard time imagining how it could fail. thanks david jencks > Thanks, > Jeremy > >> >> >> thanks >> david jencks >> >>
