Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Update Site URL for a feature
Update Site URL for a feature [message #332040] Wed, 01 October 2008 18:16 Go to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

Summary: we need to change the update site URL of a feature after the
product has shipped.

Details:
Our product (based on Eclipse 3.3) is available as both a
feature+plugins to be installed into an existing Eclipse, and as an RCP.
The RCP include the same "base" feature (call it base.feature) that is
used to install into existing Eclipse, plus another feature (call it
rcp.feature) and one additional plugin.
When we initially released the product, both the RCP and plugins updates
were included in one update site, meaning rcp.feature has specified the
same URL. Now we want to separate the two update sites (mainly because
it is very confusing to users to see both in the Update Manager UI). The
problem is, I'm concerned that if we change the current update site to
NOT include the RCP updates any more, that will prevent existing
installations of the RCP app from being able to update.
The only way forward I can think of is to temporarily keep the existing
site that contains both sets of updates (rcp.feature and base.feature)
for at least one full release, at which time "everyone" will have
updated to the new version of rcp.feature that specifies the new
(separate) update URL. Then we can safely turn off the old update site.
But that, too, has drawbacks, primarily the uncertainty about knowing
when "everyone" has updated and no longer need the old update site.

Are there any other alternatives to dealing with this problem of needing
to change the update site URL after a product has shipped?

Any help is appreciated,
Eric
Re: Update Site URL for a feature [message #332042 is a reply to message #332040] Wed, 01 October 2008 18:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

http://wiki.eclipse.org/Using_Policy_Files

Eric Rizzo wrote:
> Summary: we need to change the update site URL of a feature after the
> product has shipped.
>
> Details:
> Our product (based on Eclipse 3.3) is available as both a
> feature+plugins to be installed into an existing Eclipse, and as an RCP.
> The RCP include the same "base" feature (call it base.feature) that is
> used to install into existing Eclipse, plus another feature (call it
> rcp.feature) and one additional plugin.
> When we initially released the product, both the RCP and plugins updates
> were included in one update site, meaning rcp.feature has specified the
> same URL. Now we want to separate the two update sites (mainly because
> it is very confusing to users to see both in the Update Manager UI). The
> problem is, I'm concerned that if we change the current update site to
> NOT include the RCP updates any more, that will prevent existing
> installations of the RCP app from being able to update.
> The only way forward I can think of is to temporarily keep the existing
> site that contains both sets of updates (rcp.feature and base.feature)
> for at least one full release, at which time "everyone" will have
> updated to the new version of rcp.feature that specifies the new
> (separate) update URL. Then we can safely turn off the old update site.
> But that, too, has drawbacks, primarily the uncertainty about knowing
> when "everyone" has updated and no longer need the old update site.
>
> Are there any other alternatives to dealing with this problem of needing
> to change the update site URL after a product has shipped?
>
> Any help is appreciated,
> Eric

--
Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling :: http://www.eclipse.org/modeling
http://wiki.eclipse.org/index.php/User:Nickb
Re: Update Site URL for a feature [message #332044 is a reply to message #332042] Wed, 01 October 2008 18:55 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

Nick Boldt wrote:
> http://wiki.eclipse.org/Using_Policy_Files

Hmm, that looks promising. But it seems like it relies on being able to
specify the policy file in the user's Preferences (a luxury we don't
have). Is that correct? I can't really tell based on the wiki page, but
the online help
( http://help.eclipse.org/help33/topic/org.eclipse.platform.do c.user/tasks/tasks-37.htm)
sounds pretty certain that these files only work when set into the
Preferences (as opposed to being placed on the server). The wiki page is
a little ambiguous about it.

Guess I can try an experiment to find out, but this stuff is kind of
hard to debug and trace...

Eric


>
> Eric Rizzo wrote:
>> Summary: we need to change the update site URL of a feature after the
>> product has shipped.
>>
>> Details:
>> Our product (based on Eclipse 3.3) is available as both a
>> feature+plugins to be installed into an existing Eclipse, and as an
>> RCP. The RCP include the same "base" feature (call it base.feature)
>> that is used to install into existing Eclipse, plus another feature
>> (call it rcp.feature) and one additional plugin.
>> When we initially released the product, both the RCP and plugins
>> updates were included in one update site, meaning rcp.feature has
>> specified the same URL. Now we want to separate the two update sites
>> (mainly because it is very confusing to users to see both in the
>> Update Manager UI). The problem is, I'm concerned that if we change
>> the current update site to NOT include the RCP updates any more, that
>> will prevent existing installations of the RCP app from being able to
>> update.
>> The only way forward I can think of is to temporarily keep the
>> existing site that contains both sets of updates (rcp.feature and
>> base.feature) for at least one full release, at which time "everyone"
>> will have updated to the new version of rcp.feature that specifies the
>> new (separate) update URL. Then we can safely turn off the old update
>> site. But that, too, has drawbacks, primarily the uncertainty about
>> knowing when "everyone" has updated and no longer need the old update
>> site.
>>
>> Are there any other alternatives to dealing with this problem of
>> needing to change the update site URL after a product has shipped?
>>
>> Any help is appreciated,
>> Eric
>
Re: Update Site URL for a feature [message #332065 is a reply to message #332044] Wed, 01 October 2008 21:51 Go to previous message
Eclipse UserFriend
Originally posted by: codeslave.ca.ibm.com

Yes, AFAIK policy files are per-user implemented. You can post them on a
website for convenient access, but it's up to the users to use them to
get the updates from the new location.

You could, however, tell the old update site that its mirrors are
actually those of the new site, as suggested for the Eclipse 3.4
solution -- I can't say for sure if that works to redirect an old site
to a new site's mirror, but it too is worth a try.

Ultimately, you'll want to keep the old site around for a while and do
your best to educate users that they'll need to manually update features
from a new site, rather than automatic updates from the old site.
"Search for new features" vs. "Search for updates to existing features",
as it were.

Nick

Eric Rizzo wrote:
> Nick Boldt wrote:
>> http://wiki.eclipse.org/Using_Policy_Files
>
> Hmm, that looks promising. But it seems like it relies on being able to
> specify the policy file in the user's Preferences (a luxury we don't
> have). Is that correct? I can't really tell based on the wiki page, but
> the online help
> ( http://help.eclipse.org/help33/topic/org.eclipse.platform.do c.user/tasks/tasks-37.htm)
> sounds pretty certain that these files only work when set into the
> Preferences (as opposed to being placed on the server). The wiki page is
> a little ambiguous about it.
>
> Guess I can try an experiment to find out, but this stuff is kind of
> hard to debug and trace...
>
> Eric
>
>
>>
>> Eric Rizzo wrote:
>>> Summary: we need to change the update site URL of a feature after the
>>> product has shipped.
>>>
>>> Details:
>>> Our product (based on Eclipse 3.3) is available as both a
>>> feature+plugins to be installed into an existing Eclipse, and as an
>>> RCP. The RCP include the same "base" feature (call it base.feature)
>>> that is used to install into existing Eclipse, plus another feature
>>> (call it rcp.feature) and one additional plugin.
>>> When we initially released the product, both the RCP and plugins
>>> updates were included in one update site, meaning rcp.feature has
>>> specified the same URL. Now we want to separate the two update sites
>>> (mainly because it is very confusing to users to see both in the
>>> Update Manager UI). The problem is, I'm concerned that if we change
>>> the current update site to NOT include the RCP updates any more, that
>>> will prevent existing installations of the RCP app from being able to
>>> update.
>>> The only way forward I can think of is to temporarily keep the
>>> existing site that contains both sets of updates (rcp.feature and
>>> base.feature) for at least one full release, at which time "everyone"
>>> will have updated to the new version of rcp.feature that specifies
>>> the new (separate) update URL. Then we can safely turn off the old
>>> update site. But that, too, has drawbacks, primarily the uncertainty
>>> about knowing when "everyone" has updated and no longer need the old
>>> update site.
>>>
>>> Are there any other alternatives to dealing with this problem of
>>> needing to change the update site URL after a product has shipped?
>>>
>>> Any help is appreciated,
>>> Eric
>>

--
Nick Boldt :: Release Engineer, IBM Toronto Lab
Eclipse Modeling :: http://www.eclipse.org/modeling
http://wiki.eclipse.org/index.php/User:Nickb
Previous Topic:AutoComplete Combo is not working with DataBinding
Next Topic:Thread interrupt during Job execution
Goto Forum:
  


Current Time: Sat Dec 21 12:10:50 GMT 2024

Powered by FUDForum. Page generated in 0.03199 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top