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?
Joe
--kevan
