geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Date Thu, 06 Dec 2007 15:32:41 GMT

Kevan Miller 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...

I agree 100% and that is why I started this thread.  Almost always, the 
initial question from users first looking at Geronimo is how big and 
complex is Geronimo.

I think we have to explore ways to make these features optional for at 
least the minimal assemblies or we will loose one of our value 
propositions.  Making them plugins would seem to fit our overall 
objectives of a customizable and configurable server.  What are the 
inhibitors to making these two features pure plugins and excluding them 
from the minimal assemblies?


> --kevan

View raw message