Here are my thoughts on the switch to GShell: -1 for geronimo.sh, and client.sh - the GShell alternatives start two separate java processes: one for GShell env. and one for the server or client container. That's unnecessary in most cases and slower.
-1 for shutdown.sh - it's nice and small. No need for the entire GShell env. just to stop the server. +1 for deployer.sh - but only if 1) support for offline deployment is added, and 2) Windows paths are supported nicely (this might have been fixed already) +1 for jaxws-tools.sh - but but only if Windows paths are supported nicely. In general, I would view GShell as another plugin to Geronimo so IMHO it shouldn't be the main way to start/stop/deploy to Geronimo and it shouldn't be part of the geronimo-boilerplate assembly. However, if we are adding new functionality to Geronimo that needs CLI interface, that should be written as a GShell command. Also, things like Control-C on server started via start-server on Windows should be fixed before switching. To be more useful for Geronimo users, GShell should have better scripting capabilities (conditionals, loops, etc.) and we should write more and/or more interesting commands. Jarek On Thu, Sep 18, 2008 at 7:46 PM, David Jencks <[EMAIL PROTECTED]> wrote: > Lets change the scripts in bin that don't use gshell to use gshell. > > Then the helper scripts such as setjavaenv.sh will only be used for starting > gshell and I hopefully they won't need most of their current contents. > > As noted in GERONIMO-4093 I'm not OK with requiring JAVA_HOME to be defined > on systems that don't need it, and I took matters into my own hands and > restored the old behavior of using "java" if JAVA_HOME is not defined. I'm > barely literate in bash so there may well be a better solution. > > thanks > david jencks >
