I agree. We should make GShell flexible like our Geronimo server. I don't know if this makes sense but I'll just think aloud. At it's core should be the most basic features like start/stop and deploy/undeploy. Since Groovy is the culprit, can Groovy sit this one out ? I believe we use goals from g-m-p anyways to achieve those basic features. Everything else should be optionally built up using G-shell plugins. Groovy support can be one such optional plugin.
Cheers Prasad On Dec 5, 2007 9:50 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > On Dec 3, 2007, at 8:04 PM, Gianny Damour wrote: > > > On 04/12/2007, at 11:45 AM, Jason Dillon wrote: > > > >> On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote: > >>>>> A bit harder to apples-to-apples compare the longer term growth. > >>>>> lib/gshell accounts for a 5 meg growth (unpacked). So, that > >>>>> would help account for most of the growth in the minimal > >>>>> assembly... > >>> > >>> I wonder if we should consider allowing gshell to be optional... > >> > >> I'd recommend *not*, though if we aren't happy with the additional > >> bloat from the current impl, we can re-implement in pure-java and > >> remove the dependency on Groovy. Its possible, though not very > >> elegant IMO, as the AntBuilder syntax is ideal for launching new > >> processes. > > Hi, > > > > I am actually quite a fan of Groovy commands and really would like > > Groovy to stick around. Beside the fact that the AntBuilder syntax > > is neat, Groovy commands could provide a very neat and simple way to > > dynamically introduce new commands w/o going through a compile > > cycle. I believe many Geronimo users are Java savvy enough, and > > hence also Groovy savvy enough to directly implement their commands > > in Groovy. It is in my understanding that gshell provides a gsh-bsf > > command (not tried, just read the code) and this is a first way to > > launch Groovy scripts; however, it would be great to directly map > > commands to groovy scripts out-of-the-box. > > Understood. Playing a bit of the devil's advocate here... > > A high percentage of Geronimo users will never create a custom > Geronimo command, nor create or use GShell scripting capabilities. > They'll want to start/stop Geronimo and deploy/undeploy applications. > > For these capabilities, geronimo-boilerplate-minimal-2.1.jar has grown > by nearly 200% (3.0 meg -> 8.3 meg). > > Also, most users will never generate new server assemblies. Yet, for > this capability, we're increasing the minimal server size by 8.3 megs > (essentially including the boilerplate-minimal jar twice). At the > moment, minimal assembly has grown from 16 megs to 31 megs. > > IMO one of Geronimo's major advantages is that it's lightweight and > flexible. We're still flexible, but we seem to have put on a few > holiday pounds... I'd like to think about how we can slim things back > down... > > --kevan > > >
