http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5458
--- Comment #10 from Derik Barseghian <[email protected]> 2011-09-19 14:28:18 PDT --- I've released the patch to 2.2 at r28582, loader-2.1.1. (In reply to comment #9) > Actually r28458 didn't work. Should really be fixed now at r28501. > > (In reply to comment #7) > > I've fixed the issue with sometimes being unable to find osextension.txt > > files > > and thus sometimes not loading os extensions at r28458. I plan to patch 2.2 > > to > > include this fix. > > > > (In reply to comment #6) > > > As of 2.2, when using the module manager modules are downloaded into > > > KeplerData/kepler.modules, and the build system starts kepler as a > > > combination > > > of modules in this folder(if they are present) and those in the Kepler app > > > folder. When you switch to a suite, if the suite needs a module the app > > > folder > > > already has, it is not downloaded into KeplerData/kepler.modules. I didn't > > > realize this is how it worked; I thought all modules utilized on a given > > > kepler > > > startup were all in one place or the other. There are parts of the build > > > system > > > that behave as if all modules can be found in one place or the other, as > > > I'll > > > mention at the bottom of this post. David, is starting up using a > > > combination > > > of modules in the app and the kepler.modules folder by design, or > > > accident? > > > > > > There's a file called use.keplerdata that when present (and it's always > > > included in the installers from 2.2 on), makes kepler download to > > > KeplerData/kepler.modules/ instead of the app folder. There's a file in > > > the > > > application's build-area folder called install-id.txt that contains a > > > value > > > like 2.2 or 2.3. When the value in this file is different from the copy in > > > KeplerData/kepler.modules/build-area/, the files from the kepler > > > application > > > build-area are copied into KeplerData/kepler.modules/build-area, unless > > > they > > > already exist there. > > > > > > If use.keplerdata is present, the files kept in > > > KeplerData/kepler.modules/build-area (like modules.txt, > > > current-suite.txt, etc) > > > are used for startup instead of those in the app build-area, e.g. to > > > determine > > > what suite to start. > > > > > > The current problem is that this system won't work when you have two > > > kepler > > > apps that both have a use.keplerdata file. > > > > > > Kepler-2.3 will fail to start if > > > KeplerData/kepler.modules/build-area/current-suite.txt (and/or > > > modules.txt, > > > i've never been clear on the different usages of these two) are set for > > > kepler-2.2.0. All of the modules needed by the kepler-2.2.0 suite would > > > have to > > > be included in the combination of the modules in the kepler 2.3 app and > > > KeplerData/kepler.modules/ for this to work. > > > > > > Similarly kepler-2.2 will fail to start if > > > KeplerData/kepler.modules/build-area/current-suite.txt (and/or > > > modules.txt) are > > > set for kepler-2.3.0. > > > > > > I don't think keeping separate KeplerData/kepler.modules/build-area/2.x > > > folders > > > is a solution. I tried this and failed. It also complicates things even > > > further. You can use the 2.3 app to change-to 2.2.0. The > > > KeplerData/kepler-modules/build-area/2.3/ files become set to 2.2. On > > > auto-restart, the 2.3 app build-area files will be copied into the > > > KeplerData/kepler.modules/build-area (the 2.2 location). The MM then > > > shows that > > > you're in 2.3, but the splash screen shows you're in 2.2. I'm not sure > > > what > > > you're in. On a subsequent attempt to start the 2.3 app, startup fails > > > with a > > > missing module message. A number of other problems also cropped up. > > > > > > 1) One way to not delay the 2.3.0 release too much longer is to not > > > include > > > use.keplerdata. This would mean dropping support for users being able to > > > download add-on modules when they don't have write support to the > > > application > > > area. I think this how most applications work. Do we have users that this > > > would > > > be a problem for? > > > 2) Another way is to not put out a 2.3 installer, and delay fixing the > > > build > > > system. Instead users would upgrade to 2.3 via MM. > > > > > > With option 2 there's at least one problem that itself isn't huge, but > > > points > > > to a larger issue. > > > * Possible problem: If you use 2.2 to move to 2.3, you don't get the > > > latest > > > build-area. I don't know if this will cause problems, probably not. > > > * Problem: In 2.3 on mac, the file menu items are back on each individual > > > kepler window (not mac style). 2.2 and 2.3 both use > > > apple-extensions-2.1.0. The > > > problem is fixed if you copy this module into KeplerData/kepler.modules/, > > > implying something is looking for this module in the wrong place. I > > > tracked > > > this down, the issue is that kepler.Kepler.main just looks in > > > KeplerData/kepler.modules/ for osextension.txt files. This is because > > > ProjectLocator.findKeplerModulesDir() determines that the projectLocation > > > is > > > KeplerData/kepler.modules/, even though it's actually a combination of > > > the app > > > folder and kepler.modules. Is there even a way to know which instances (on > > > disk) of Modules are in use? I'm not seeing one. Module.getDir() can > > > return the > > > wrong value. There are many directory variables that are set to > > > nonexistent-on-disk paths, and I wouldn't be surprised if there are > > > problems > > > lurking because of this. -- Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. _______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
