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
