On 03/23/2016 12:39 AM, David M. Karr
wrote:
I'm
working on an Eclipse plugin codebase, and I've gotten to the
point where the build server is producing the update site zip
file. I now need to think about reasonable strategies for
defining an update site URL. The simplest strategy would be a
single URL that I publish everything to, snapshots and releases.
That's probably not a good idea. Is it as simple as just defining
a "/release" url and a "/snapshot" url and leave it at that? Each
of these would just get the latest release or snapshot
respectively.
Obviously, I have to work with my infrastructure team to make the
URLs available, I just want to start with something that will be
maintainable.
If you use Nexus and the unzip plugin, then you have those
repositories available on simple "mvn deploy" of the p2 repository
artifact, and having a release is similar to "mvn deploy" but having
the -SNAPSHOT removed in the version of the p2 repository.
About specific URLs, here is my recommendation, used by some
Eclipse.org project. Those assumes you're maintaining a SINGLE
STREAM of your repo, ie there is master but you don't work on
branches.
* /snaphots : contain the latest build from master, can be published
by a Maven build step or CI
* /releases/ : publishing to releases is a manual step: take a
snapshot build, verify it's working and copy its content to the
named release folder
** 1.0.0/
** 1.0.1/
** 2.0.0/
** ...
** latest/ latest can either be a composite to the latest version,
or a simple copy of its contents.
Some other projects have set up different approach either because
they work on different streams simultaneously (so that there are
multiple "snapshots"), or because they have some intermediary
quality-level (staging, integration...). If you don't need those,
keep with the simplest approach possible for you, since over-design
on that part actually becomes boring and costly to maintain.
HTH
|