geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Date Thu, 06 Dec 2007 07:05:16 GMT

On Dec 5, 2007, at 6:50 PM, 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...

So I think there are 2 issues here:

1. duplication of stuff in the boilerplate plugin.

2. Inclusion of a couple hefty jars.

1:  We could remove all or almost all the code jars from lib and get  
them into the gshell classpath with explicit paths into the geronimo  
repository.  This would mean we'd only have one copy of groovy and  
ant, the 2 largest jars AFAIK.  I don't know how upgrade-proof we can  
make this with path wildcards, but it would work at least until  
someone wanted to upgrade groovy, ant, or one of the other jars.   
IIUC after a conversation with jdillon on IRC he's ok with this, so  
I'll see if I can get it to work.

2. a. groovy is cool but we could rewrite our current groovy code in  
java in, probably, a couple of days.  I'm inclined to support leaving  
the groovy stuff in there but if we can make groovy optional --  
"usable if present" -- then I wouldn't object if someone wanted to do  
this rewrite.  I definitely think we should make it possible to have  
groovy gshell commands, whether or not the ones we supply are in groovy.

2.b. I also wonder if we really need all of core ant to use the  
launcher.  Is there some way of maybe extracting the classes we  
actually need and just including them?

david jencks

> --kevan

View raw message