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.

Thanks,
Gianny

>
> As I mentioned before, the size of the core of GShell is a little  
> more than a megabyte, and with out the XStream bits its just under  
> a megabyte, but again the custom XML parsing bits are not very  
> elegant so I'd rather just keep XStream around.
>
> There are a few optimizations that can be done for Geronimo  
> integration however.  Like for example GShell includes a _diet_  
> version of Log4j, which excludes all the ancillary muck that comes  
> with its arifact.  Since we already include the full log4j.jar we  
> can omit the diet version thin things down.  Also, as I mentioned  
> before I've not yet peeped at what is already included in the  
> repository and what is duplicated in the lib/gshell directory,  
> though I did try to re-sure bits from lib/*
>
> And lets also keep in mind that the next version of GShell will  
> behave a lot like Maven2 wrt dependency resolution for commands,  
> which means that we can configure commands and then GShell will re- 
> use bits from the repo or download them as needed from central.
>
> --jason