Project

General

Profile

Actions

bug #5967

closed

Adapt default update site to production update site.

Added by Andreas Müller almost 6 years ago. Updated 4 months ago.

Status:
Closed
Priority:
Highest
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Severity:
normal
Found in Version:

Description

Adapt default update site to http://cybertaxonomy.eu/download/taxeditor/update/stable/. Currently it is http://cybertaxonomy.eu/download/taxeditor/update/nightly/

Generally this information should be stored together with the installed instance, NOT in .cdmLibrary or any other shared folder so that 2 different versions of the Editor should not influence each other, which currently seems to be the case.


Related issues

Related to EDIT - bug #9851: Problems during search for updates when network delay is too bigIn ProgressKatja Luther

Actions
Actions #1

Updated by Patrick Plitzner almost 6 years ago

  • Description updated (diff)
  • Assignee changed from Patrick Plitzner to Andreas Müller

to check if it works you have to delete eu.etaxonomy.taxeditor.store.prefs in folder .cdmLibrary/.metadata/.plugins/org.eclipse.core.runtime/.settings
to get rid of stored preferences

Actions #2

Updated by Andreas Müller almost 6 years ago

  • Status changed from New to Resolved
Actions #3

Updated by Andreas Müller almost 6 years ago

  • % Done changed from 0 to 80

This ticket is difficult to review before the release so we will do the review afterwards.

Actions #4

Updated by Andreas Müller over 5 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Patrick Plitzner

If no entry exists in eu.etaxonomy.taxeditor.store.prefs everything works as expected as far as I can see. Meaning, that stable versions use ..\stable as update site, nightly versions use ..\nightly.

Remaining problem is that if this value is changed for some reason it is still stored in a user wide location instead of being instance dependent. If one has >1 instances and both stable and nightly versions this may create problems.

However, the problem is small as usually one may not need to change the value of the preference at all so except for users who have already installed old versions on there machine it is not expected that anybody is explicitly setting this value anymore.

We may create a new ticket for this remaining issue with low priority - or just leave it as it is and mentioning here that the second part of the ticket was not implemented - on purpose at it is not relevant enough.

Actions #5

Updated by Patrick Plitzner over 5 years ago

  • Assignee changed from Patrick Plitzner to Andreas Müller

I vote for not adding a new issue. I think the standard user only runs one instance which usually is the stable release. So once the update site is correctly configured (either the user already has some pref files which he/she deletes or it is correctly set up by first installation) the updates should always work for new releases.

Actions #6

Updated by Andreas Müller 4 months ago

  • Private changed from Yes to No
Actions #7

Updated by Andreas Müller 4 months ago

  • Related to bug #9851: Problems during search for updates when network delay is too big added
Actions #8

Updated by Andreas Müller 4 months ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

I agree that we can close the ticket as the remaining issue is small and since than most users will have reinstalled there instances.

Actions

Also available in: Atom PDF