Maybe a wiki page of some sort laying out the goals for any upcoming GShell release where people can tag their name next to areas their tooling around in. It'd by no means be some sort of gold rush claim to parts of gshell. It would just let people know what areas they might need to tread softly in, for fear of mucking up someone's work. It would also help to draw light to what areas of gshell are getting ignored. Those sad, lonely little areas.
Cool! A few comments though...
Right now aliases are defined in layout.xml, I'd like to not have morew config for this. What is the point of execute-alias?
The rsh bits are still on the experimental side and subject to change. I think we'd be better off lea?ing them for 2.2 integration, which was what I had intended.
But overall... Cool beans that other folks are starting to help with GShell!!! Perhaps we need a little more discussion on who is doing what for now and the next release?
From: Gianny Damour <email@example.com >
Date: Sun, 2 Dec 2007 12:40:41
Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
I will soon add gshell-remote-client/common/server, gshell-whisper
and mina dependencies so that we can remote control servers. In other
words, it will increase a little bit more.
This may still change, however here is a list of the new commands:
* alias: to create an alias;
* unalias: to remove an alias;
* execute-alias: to execute an alias;
* remote/rsh: rsh client;
* remote-rsh-server: rsh server;
* remote-control/server-control: to execute a control operation start/
stop, for a remote server. This command rsh to a gshell instance
where the server is to be started or stopped and execute the proper
Aliases will be stored in etc/aliases.xml and users will be able to
alter that if they want via CLI option. remote-control/server-control
uses a hierarchical tree to defined hosts along with how to remote
login to a gshell running on this instance and commands to control
On 02/12/2007, at 12:29 PM, Jason Dillon wrote:
> The core muck is a little over 1m, but for the G integration we are
> using Groovy for commands, which adds about 2.5m for the core
> runtime and then its got a few deps too. I can work on optimizing
> this a bit, have not really paid much attention, aside from trying
> to keep the GShell core size as small as possible.
> I think we can put most of its deps in the repo and just hardcode
> them in the classworlds conf for now. Next version will
> dynamically pull them out of the repo in the same way that mvn
> plugins do.
> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>> Damn gshell...WTF?
>> I couldn't resist ;-)
>> Jason Dillon wrote:
>>> No doubt some increase is from the gshell libs. We can probably
>>> optimize them a little and use repository references and such...
>>> -----Original Message-----
>>> From: "Bruce Snyder" <firstname.lastname@example.org >
>>> Date: Sat, 1 Dec 2007 14:52:44
>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>> On Nov 30, 2007 3:59 PM, Joe Bohn <email@example.com> wrote:
>>>> It looks like the size of our images is increasing dramatically
>>>> (nearly 2x).
>>>> For example, the geronimo-jetty6-minimal snapshots have been
>>>> like this (these image sizes are from the snapshot repo):
>>>> 16604006 Jul 26 18:54
>>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>>> 22310769 Nov 1 03:19
>>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>>> 30812531 Nov 30 22:45
>>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>>> The javaee5 images have also grown significantly.
>>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> 55113050 Nov 1 03:28
>>>> 56827820 Nov 1 03:25 geronimo-jetty6-
>>>> 71313050 Nov 30 22:54
>>>> 73094816 Nov 30 22:50 geronimo-jetty6-
>>>> I haven't looked into the cause yet ... but does anybody have
>>>> some ideas
>>>> on the culprit?
>>> FWIW, we've experienced the same thing with ServiceMix. I think it
>>> might be a problem with Maven and how it's resolving and including
>>> transitive dependencies.