Marshall Schor wrote: > I agree this is an issue. > > I can see 2 paths forward. One makes multiple eclipse-update-sites. > The other moves the generation of the update site to a "deploy" step > taken after the release is approved. > > I would like to consider this latter way. It seems to me that the > update site is very similar to maven artifact deployment. In both > cases, the artifacts being deployed are being packaged with additional > meta-information about their versions, etc.. And, in both cases, there > is a kind of "merging" that is done. In the Maven case, there is a file > which is updated which contains all the versions of the artifact - this > is similar to the manual update of the site.xml, for the Eclipse update > site. > > In the Maven case, the deployment takes place after the release is voted > on. If we could do something similar, then we could remove the "build" > of the Eclipse update site and do it after the release had been voted on. > > Unless there are objections, I'll update the xxx-distr POMs to remove > the building of the Eclipse update site - that should fix our build for > the moment, I think. +1 for doing the eclipse update site building similar to the Maven repository upload and remove it from the automated Maven build for now.
-- Michael
