Kepler

Block the Kepler-2.3.0 bug#5459

Use Target Milestone 2.3.0

In linux installer, I got this error by type "./kepler.sh":
[null] Copying 1 file to /home/tao/KeplerData/kepler.modules/build-area
[null] Copying 1 file to /home/tao/KeplerData/kepler.modules/build-area
JVM Memory = 5m 512m
Error: The following modules are missing:
kepler-2.2.0

As Christopher suggested, I had to remove ~/KeplerData to make it work.

Christopher was moving from kepler-2.2 to kepler-2.3, however, I already has configuration-2.3 in my KeplerData directory since I already ran 2.3 from svn. I still got the issue.

A complete solution would allow users to move between 2.2 and 2.3.
A partial solution would be to allow users to move once from 2.2 to 2.3.
I agree that we need to keep the ability for users who don't have
write permission to run Kepler.

Derik writes:
I believe I've created a solution to this bug locally, but the solution is not
backwards compatible in so far as 2.2's kepler.sh, Kepler.app, and kepler.exe
will fail to start once 2.3 has been installed and started once. We could
recommend people uninstall 2.2 so they're not tempted to try this. Switching
back and forth between 2.2 and 2.3 using 2.3's Module Manager will work. Let me
know if this doesn't sound acceptable to you. Clearly it's not ideal. The bug
here is to do with keeping modules and files used by the build system to start
kepler in two places, the Kepler application folder of course, and
KeplerData/kepler.modules/. The issue is that the files in
KeplerData/kepler.modules are not overwritten during a new install, or when
switching between versions, and so start up can fail when incompatible
KeplerData/kepler.modules/ files exist.

Another solution is to simply not include use.keplerdata in the installers, but
this takes away our ability to let users without write permission to the
application area download and use different modules.

Personally I don't think we should be storing the application in 2 places, it
complicates things and uses extra space. I believe the original intent of using
KeplerData/kepler.modules for module downloads was to allow users to download
different modules and change suites when they don't have write access to the
application area. However I think we should probably just behave like other
apps. If a user wants to download add-ons, they should have to get admin
access. Or the app should just be entirely in their own space from install. But
this may have to wait for 2.4.

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.

• 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.

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.

I concluded fixing the issue of 2.3.0 being unable to start if 2.2.0 had been run before at r28454 . current-suite.txt was not being copied into KeplerData/kepler.modules/build-area nor initialized. Additionally, I believe I also found it was possible to get into situations where the copy attempts failed when the destination files already exist. I fixed that at r28365 with use of copy.setoverwrite(true).

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.

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.

This should no longer happen.
If 2.3 fails to start due to missing modules, the MM GUI is now started.
The plan is to ask users uninstall old versions of kepler before installing 2.3 to avoid that from even happening.
If they don't, the other thing that can happen is 2.2 can fail to start from the 2.2 icon, and 2.2 will not start its MM GUI -- the user has to figure out to do this on their own. We could consider looking into patching to take care of this if we think it's worthwhile.

I'll leave this open for others to test.

Under Mac OS X, I ran Kepler-2.3 and now Kepler-2.2 won't start for me.
Clicking on Kepler does not do anything.

The Console says:
10/5/11 5:39:22.515 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: JVM Memory = 5m 512m
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: Error: The following modules are missing:
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: kepler-2.3.0
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: r-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: loader-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: actors-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: dataturbine-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: ecogrid-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: authentication-gui-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: gui-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: module-manager-gui-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: authentication-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: repository-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: component-library-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: core-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: common-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: module-manager-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: configuration-manager-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: kepler-tasks-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: ptolemy-kepler-2.3.^

I started up the Module Manager and it shows that the current suite is
"module-manager-gui-2.2.0"

Also, the following appeared on the Console:

10/5/11 5:41:36.126 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: JVM Memory = 5m 512m
10/5/11 5:41:36.188 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: setting dock icon to Xdock:icon=/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/resources/icons/kepler-dock-icon.png
10/5/11 5:41:36.227 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Set environment variable: PATH = /usr/bin:/bin:/usr/sbin:/sbin:/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/lib/ptolemy/matlab:/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/lib
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] Exception in thread "main" java.lang.NoClassDefFoundError: org/kepler/Kepler
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] Caused by: java.lang.ClassNotFoundException: org.kepler.Kepler
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at java.security.AccessController.doPrivileged(Native Method)
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [null] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: [LaunchRunner Error] org.kepler.build.runner.Kepler.main(String[]) threw an exception:
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java returned: 1
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by: Java returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 8 more
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by: Java returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 10 more
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: -- Nested Exception ---
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by: Java returned: 1
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 10 more
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: --- Nested Exception ---
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java returned: 1
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

What should I do if I want to start up 2.2 after starting 2.3?

After I removed my ~/.kepler and ~/KeplerData files, I started up
Kepler-2.2, then Kepler-2.3 and then Kepler-2.2.
Kepler-2.2 did not start up, so I started the Module Manager and
selected the kepler-2.2 suite. I was then able to start up Kepler-2.2.

I tried to start up Kepler-2.3 and got this window.

I went to the Available Suites and Modules tab and kepler-2.3 was
not listed? I'll upload a screen shot of that window momentarily.

How do I move from Kepler-2.2 to 2.3?

Here's the Available Suites and Modules tab that occurs after I run 2.2
and then run 2.3

Please see comment#11.
To reiterate, trying to launch kepler 2.2 from the kepler 2.2 icon after running 2.3 will fail with a missing modules error. The way to get the kepler-2.2 app icon working again at that point is to use it's associated standalone MM GUI icon to change to 2.2.
We can consider trying to patch 2.2 to launch the MM GUI if kepler-2.2 fails to start due to missing modules (as I've done in 2.3), but as I mention, the current plan is to ask users to uninstall old versions of kepler before installing 2.3, so we should consider if it's worthwhile. I'm also not entirely sure if it's possible at the moment (hopefully, but I didn't get that far).

(In reply to comment #12)

Created attachment 384 [details]
Module Manager After Kepler 2.2 Fails To Start

Under Mac OS X, I ran Kepler-2.3 and now Kepler-2.2 won't start for me.
Clicking on Kepler does not do anything.

The Console says:
10/5/11 5:39:22.515 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: JVM Memory = 5m 512m
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: Error: The
following modules are missing:
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
kepler-2.3.0
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler: r-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
loader-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
actors-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
dataturbine-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
ecogrid-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
authentication-gui-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
gui-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
module-manager-gui-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
authentication-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
repository-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
component-library-2.2.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
core-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
common-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
module-manager-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
configuration-manager-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
kepler-tasks-2.3.^
10/5/11 5:39:22.516 PM [0x0-0xce0ce].org.kepler.build.runner.Kepler:
ptolemy-kepler-2.3.^

I started up the Module Manager and it shows that the current suite is
"module-manager-gui-2.2.0"

Also, the following appeared on the Console:

10/5/11 5:41:36.126 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: JVM Memory = 5m 512m
10/5/11 5:41:36.188 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: setting
dock icon to
Xdock:icon=/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/resources/icons/kepler-dock-icon.png
10/5/11 5:41:36.227 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Set
environment variable: PATH =
/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/lib/ptolemy/matlab:/Applications/Kepler-2.2/Kepler.app/Contents/Resources/Java/common-2.2.0/lib
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] Exception in thread "main" java.lang.NoClassDefFoundError:
org/kepler/Kepler
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] Caused by: java.lang.ClassNotFoundException: org.kepler.Kepler
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at java.security.AccessController.doPrivileged(Native Method)
10/5/11 5:41:36.536 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
10/5/11 5:41:36.537 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[null] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler:
[LaunchRunner Error] org.kepler.build.runner.Kepler.main(String[]) threw an
exception:
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java
returned: 1
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.555 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by:
Java returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 8
more
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by:
Java returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 10
more
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: -- Nested
Exception ---
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java
returned: 1
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:106)
10/5/11 5:41:36.556 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Caused by:
Java returned: 1
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: ... 10
more
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: --- Nested
Exception ---
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: Java
returned: 1
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
10/5/11 5:41:36.557 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.runSuite(Run.java:309)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.Run.run(Run.java:213)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.run(Kepler.java:218)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.modules.ModulesTask.execute(ModulesTask.java:102)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
org.kepler.build.runner.Kepler.main(Kepler.java:94)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
java.lang.reflect.Method.invoke(Method.java:597)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.run(LaunchRunner.java:116)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.LaunchRunner.callMain(LaunchRunner.java:51)
10/5/11 5:41:36.558 PM [0x0-0xd60d6].org.kepler.build.runner.Kepler: at
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)

What should I do if I want to start up 2.2 after starting 2.3?

As I mentioned in the RC email, the branches that make up kepler-2.3.0 are only published to the test area, so they're only visible in a kepler in which you've hacked this file to point at the test area:
module-manager/resources/configurations/configuration.xml

(In reply to comment #13)

Created attachment 385 [details]
Module Manager after trying to run 2.3 after running 2.2

After I removed my ~/.kepler and ~/KeplerData files, I started up
Kepler-2.2, then Kepler-2.3 and then Kepler-2.2.
Kepler-2.2 did not start up, so I started the Module Manager and
selected the kepler-2.2 suite. I was then able to start up Kepler-2.2.

I tried to start up Kepler-2.3 and got this window.

I went to the Available Suites and Modules tab and kepler-2.3 was
not listed? I'll upload a screen shot of that window momentarily.

How do I move from Kepler-2.2 to 2.3?

Right, comment 11 says:
"If they don't, the other thing that can happen is 2.2 can fail to start from
the 2.2 icon, and 2.2 will not start its MM GUI -- the user has to figure out
to do this on their own. "

I was able to start MM and select the kepler-2.2 suite. It was not at all
obvious.

I don't think we should go back and patch 2.2.

We should document how to move between the releases and be sure that it can be
done. I can't get back to 2.3 right now. Deleting ~/.kepler and ~/KeplerData
would probably do it.

About hacking the configuration because the files are only visible in test area,
I'm not so sure if that is such a good test to validate that the
problem has been fixed. It means that I'm not running what users will
be running.

Sorry to be a stick in the mud, but these failures are mysterious and
confusing to users.

I don't like having to edit the configuration.xml file either, but it's currently the only way that I know to allow us to test things without making rcs prematurely available to the world. I could change it in the rc, but then the problem is worse, you initially won't be testing what will actually go out. Apparently the test-area work was never completed to get around this issue.
Once you edit the configuration.xml, your last attachment, where the MM GUI tells you to select a valid suite will be a way to get back to 2.3.

Document how to switch releases for whom? For testers right now? I can do that (although maybe those few that will test know the situation at this point). I don't want to make such documentation for users if it turns out it's possible to patch 2.2 for the issue and we decide it's worthwhile to do so, because then hopefully there shouldn't be any documentation necessary. Because if you're keeping different copies of the kepler application around, and we patch 2.2, the MM GUI will come up as you see it here, telling you there was a problem, and you should switch to a valid suite.

(In reply to comment #17)

Right, comment 11 says:
"If they don't, the other thing that can happen is 2.2 can fail to start from
the 2.2 icon, and 2.2 will not start its MM GUI -- the user has to figure out
to do this on their own. "

I was able to start MM and select the kepler-2.2 suite. It was not at all
obvious.

I don't think we should go back and patch 2.2.

We should document how to move between the releases and be sure that it can be
done. I can't get back to 2.3 right now. Deleting ~/.kepler and ~/KeplerData
would probably do it.

About hacking the configuration because the files are only visible in test
area,
I'm not so sure if that is such a good test to validate that the
problem has been fixed. It means that I'm not running what users will
be running.

Sorry to be a stick in the mud, but these failures are mysterious and
confusing to users.

With respect to the editing the configuration.xml file, it should be noted that the methodology inherent in the significantly revised build system I have developed would address this issue. After the 2.3 release, I would suggest having a look at that.

The current plan is to suggest to users in the release announcement that they uninstall past versions of kepler, and that if they don't, those past versions may not start up when launched from their icons after having installed kepler 2.3.
Retargeting to 2.4.0.

It is fixed as of 2.3 and this will not happen between 2.3 & 2.4. What could still happen is if you start 2.3 and revert back to 2.2 it won't open.

Jianwu will test this behavior between 2.3 and 2.4. If there is no problem, the bug will be closed. Jianwu will also add this to the release process. (A new webpage need to be created for the release process.) The process should include adding bugs for release steps before each release.

My tests show Kepler 2.3 and 2.4 can switch correctly. Basically, users can switch to 2.4 from 2.3 (either Module Manager.app in 2.3 or Module Manager in Kepler.app). But if they want to switch back to 2.3, they can only do it in Kepler.app. Module Manager.app in 2.3 won't work (it won't quit).

The reason is probably at line 203 of org/kepler/modulemanager/gui/AvailableModulesPanel.java:
System.out.println("AvailableModulesPanel notifiying shutdown listeners " +
"of impending shutdown. Closing any open databases may take awhile...");
ShutdownNotifier.shutdown();

Class ShutdownNotifier is in core module, but suite module-manager-gui-2.3 doesn't have core module. Basically, if the 'current suite' tab in Module Manager shows the content of module-manager-gui-2.3, it won't quit.

Dan and I tried to have a patch (module-manager-gui-2.3.1) for module-manager-gui-2.3, Module Manager.app can download it and start from it. But when Manager.app exits and starts again, it goes back to module-manager-gui-2.3.0 again.

I think it is very rare that users want to go back to 2.3 after they update Kepler to be 2.4. If they really want it, the solution could be 1) using "module manager" in Kepler.app; 2) downloading kepler 2.3 installer; 3) adding line "core-2.3.^" at the beginning of the modules.txt in module-manager-gui-2.3.0. (e.g. vi /Applications/Kepler-2.3/Kepler.app/Contents/Resources/Java/module-manager-gui-2.3.0/module-info/modules.txt).

closing the bug.

I'm not that comfortable with closing this bug because:

But if they want to switch back to 2.3, they can only do it in Kepler.app.
Module Manager.app in 2.3 won't work (it won't quit).

It seems that this bug is partially fixed in that Kepler.app allows this.

So, I'm changing this to wontfix.

This limitation in the Module Manager should be documented and a separate bug opened for it.

We cannot apply patch for module-manager-gui-2.3, so I'm ok with "Won't fix". For module-manager-gui-2.4, it works well and can use patches if there are ones. So I don't think we need new bug open for it.

Original Bugzilla ID was 5458