| Re: [tycho-user] Strategies for defining update site url |
|
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.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 |