uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <pklu...@uni-wuerzburg.de>
Subject Re: a better way to do eclipse update site building / releasing
Date Tue, 04 Jun 2013 13:41:57 GMT
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



View raw message