when to generate pack.gz for Eclipse plugin projects

[Marshall Schor <ms...@schor.com>]

With m2e and Eclipse 4, it is possible to have a development / test cycle that
uses incremental Eclipse builds for changes to plugin projects, and uses the
class files (without building into Jars) for the plugins during debug/testing. 
(This, of course, relies on not hitting "bugs" in the current levels of Eclipse 4).

Given this, I'm wondering if it would be a good idea to move the generation of
pack.gz forms of the jars up one level.  Currently pack.gz forms are generated
when building plugins for the update-site.  The update site build for plugins
involves copying the jars from Maven repositories, and then running the "pack"
operation on each of them.  There can be a lot of Jars - one for each plugin *
the number of versions for each plugin.  For instance, right now we have for the
uimaj project, 2 versions of each plugin - 2.4 0 and 2.3.1.  Moving forward,
we'll likely keep the older versions for quite a while, and add newer versions.

It is possible to add the pack.gz creation step to the step that produces the
Jars.  This has the drawback that running the build for that takes longer.  I
think with the 4.2 support incremental builds in Eclipse, this may not matter as
much.

We might also do a process where the pack.gz isn't done until the update site is
built, but when it's done there, it's only done for the current version; older
versions are obtained from Maven repositories. 

In both these cases, the release of the plugin artifacts would be part of the
release process, and the plugins (and their pack.gz forms) would be uploaded to
Maven central.

This contrasts with today's process, where pack.gz files are regenerated
whenever update sites are built, and never "saved" for reuse.

-----------

A major alternative to uploading artifacts like the pack.gz to Maven central
(where they exist only to allow the maven-dependency-plugin to copy them into
new update sites using "Maven coordinates" of group-id, artifact-id, and
version): would be to instead pull the older version artifacts from the
release-spot SVN.  This is possible because of the new release process, where
the Eclipse update site is now in the "release" svn
(https://dist.apache.org/repos/dist/release/uima/eclipse-update-site.  The build
of update sites could split the work around current and previous versions of
features and plugins; for the previous ones, it could copy artifacts from the
dist svn site, including the pack.gz files, and for the new versions, it could
get them from the Maven coordiates (.m2 and/or Maven Central) and generate the
pack.gz on every build, rather than saving it alongside the jar in Maven repos.

Any opinions on what the best practice would be here?

My own slight preference is to set things up so that the update site fetches
previous versions from the distribution release SVN, and rebuilds pack.gz's
every time.

-Marshall