http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5458
--- Comment #6 from Derik Barseghian <[email protected]> 2011-08-25 18:13:28 PDT --- 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
