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?
thanks
david jencks
--kevan
