Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Strategies for defining update site url

On 03/23/2016 12:32 AM, Mickael Istria wrote:
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 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.

I'm finally getting to the point where I need to focus on this, so I have some more specific questions.

I need to understand more about the Nexus unzip plugin and that part of the process.  I'll pursue other channels for that information.

So concerning your URLs suggestion, I assume that this means that if I'm releasing a version "2.0.1", say, then I'll assume that we'll prepare a folder where we're hosting the update site named "2.0.1" and configure Nexus to unzip the deployment there.  We would then advertise that "http://.../ourapp/2.0.1" is the update site for this release.  Is that correct?  Or can we have a "static" update site URL, and that when we deploy the new release to it, when users attempt to update an existing installation, they'll get the new release?  I would think something closer to the latter is more reasonable.

Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top