On 04.06.2013 15:34, Marshall Schor wrote: > I'd like to adjust the build / release process for Eclipse update sites > slightly > to achieve several goals: > 1) speedier builds > 2) more automation, reliability > 3) insuring minimal use of SVN space in dist.apache.org svn. > > The speedier builds would come from avoiding regenerating the pack.gz files on > older versions of plugins. > The more automation would come from having smaller update-site poms, not > having > to list every older version of plugins. > The insuring minimal svn use would come from automating the checkout - update > of > the eclipse update site in a manner to preserve old plugins, unmodified. > > The update site building requires running some eclipse tools to generate > metadata from a set of existing features and plugins. This process requires > access to all the features and plugins (both the new ones being released, and > all of the older versions). Today, this is accomplished by using the maven > dependency plugin to copy the release feature / plugin artifacts from maven > central to the target working area. > > Today, the build process is regenerating 7 more file for each old plugin - a > "pack.gz" format of the jar, plus 3 checksums/signings for the plain Jar and > pack.gz form. > > In the new process, rather than pull the existing plugin jar from maven > central, > I propose using svn checkout from the distribution svn (release) to get all > the > old features, plugins, their pack.gz forms, and their signings/checksums. The > update pom site would only need to call out specifically the new release being > added to the set. > > The existing build steps would be reduced by no longer generating pack.gz > forms > for older versions, or the signings/checksums for those (I haven't yet > investigated how to do this). > > When the build is complete, because the update site was previously checked-out > of the dist svn, to release, you would just commit the changes (which would be > only the new versions of features / plugins and the top level metadata, thus > saving svn space, and insuring older versions retain their original signings. > Although I haven't used it before, there's a Maven plugin for svn checkout > etc: > http://maven.apache.org/scm/maven-scm-plugin/ > > What do you think? Any ideas for improvement? > > -Marshall
+1, but ... You probably know what I gonna say... ;-) Why do we not create a new update site for each release? Then, we only have to handle the new subfolder and update metadata of the composite repository. Best, Peter
