Improving the Eclipse Update Site release process

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

The Eclipse update site project is unusual in that it covers multiple
releases, of multiple components; we have one update site for all UIMA
things, and it is possible to get older versions as well as current ones.

This is implemented by a strategy of keeping the update site on the
distribution mirrors, and adding new release components to it, and
*changing* the top-level site information there which is updated to
include reference to the new components.

It seems to me this is a needed deviation from the practice of never
updating things on the people.a.o distribution site; I don't know how to
do this otherwise, other than to not put the Eclipse Update Site into
the mirroring system.

The current build process for the update site expects the jars for the
features to be in the update site's features/ directory.  The jars here
need to be all of the jars for all projects, for all releases. 
Currently, we have a manual step after a release where the feature jars
just generated for the new release are checked into SVN in this folder. 
I don't like manual steps (I just realized, for instance, that I hadn't
done this step since our release, so I did it just now, using the actual
released jar artifacts).  In place of doing this, I think I can get the
POM to copy these jars from people.a.o/dist spot.  Or, if preferable, we
could get these jars from the Maven release repositories (currently not
possible, since they've never been uploaded to any Maven repo - but we
could change that).

I'm not sure which way is better; any opinions?

-Marshall

Re: Improving the Eclipse Update Site release process

[Tommaso Teofili <to...@gmail.com>]

2010/5/4 Marshall Schor <ms...@schor.com>

>  Or, if preferable, we could get these jars from the Maven release
> repositories (currently not
> possible, since they've never been uploaded to any Maven repo - but we
> could change that).
>
>
This would be the best solution in my opinion.
Tommaso