Project

General

Profile

Actions

Bug #5494

closed

existence of remote 2.2 patches can cause 2.3 to fail to start 2.2 on first attempt

Added by Derik Barseghian about 13 years ago. Updated about 13 years ago.

Status:
Resolved
Priority:
Normal
Category:
module manager
Target version:
Start date:
09/19/2011
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5494

Description

Now two patches to 2.2 exist: loader-2.1.1 and module-manager-gui-2.2.1.
If you launch 2.3.0 from the 2.3 app and attempt to use it to switch back to kepler-2.2, if you have not previously downloaded the patches mentioned above from within 2.2, 2.2 will fail to start on this initial attempt. The error on console is:
9/19/11 4:34:20 PM [0x0-0xfdafda].org.kepler.build.runner.Kepler38570 [null] Error: The following modules are missing:
9/19/11 4:34:20 PM [0x0-0xfdafda].org.kepler.build.runner.Kepler38570 [null] loader-2.1.1
9/19/11 4:34:20 PM [0x0-0xfdafda].org.kepler.build.runner.Kepler38570 [null] module-manager-gui-2.2.1

A subsequent start up of the 2.3 app does what was supposed to happen the first time: start 2.2, immediately prompting you to download the two available patches.

During the Module Manager restart process something seems to have knowledge of remote patches and mistakenly assumes they've been downloaded.

Actions #1

Updated by Derik Barseghian about 13 years ago

Looks like the issue is that "present.txt" is not being updated when it should.
Also I notice UpdatePresentTxt is another place expecting getProjectDir to always return the app dir.
Hope to have a fix in place soon, and changes to UpdatePresentTxt to really always look in both places for modules.

Actions #2

Updated by Derik Barseghian about 13 years ago

Fixed by r28633-28635.

Actions #3

Updated by Derik Barseghian about 13 years ago

Forgot to paste info about fix from r28635 commit msg:

update present.txt and present list variable when downloading modules. Not knowing modules were present was causing problems. transformName would fall through to tranformArrowNameForGet, which utilizes the release list, which is not what you want when a module is present. This caused kepler 2.3.0 to fail to start on initial try after using it to move back to 2.2.0. http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5494

Actions #4

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 5494

Actions

Also available in: Atom PDF