You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2007/11/30 23:59:14 UTC
Our 2.1 assemblies are nearly 2x the size of 2.0.2
It looks like the size of our images is increasing dramatically (nearly 2x).
For example, the geronimo-jetty6-minimal snapshots have been growing
like this (these image sizes are from the snapshot repo):
16604006 Jul 26 18:54
geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
22310769 Nov 1 03:19
geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
30812531 Nov 30 22:45
geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
The javaee5 images have also grown significantly.
57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
55113050 Nov 1 03:28
geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
71313050 Nov 30 22:54
geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
I haven't looked into the cause yet ... but does anybody have some ideas
on the culprit?
Joe
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jeff Genender <jg...@apache.org>.
AWESOME!!!!
Gianny Damour wrote:
> Hi,
>
> Some heads-up.
>
> 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
> command.
>
> 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 servers.
>
> Thanks,
> Gianny
>
>
> 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.
>>
>> --jason
>>
>>
>> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>>
>>> Damn gshell...WTF?
>>>
>>> :-)
>>>
>>> I couldn't resist ;-)
>>>
>>> Jeff
>>>
>>> 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...
>>>>
>>>> --jason
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: "Bruce Snyder" <br...@gmail.com>
>>>>
>>>> Date: Sat, 1 Dec 2007 14:52:44
>>>> To:dev@geronimo.apache.org
>>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>>>
>>>>
>>>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>>>> It looks like the size of our images is increasing dramatically
>>>>> (nearly 2x).
>>>>>
>>>>> For example, the geronimo-jetty6-minimal snapshots have been growing
>>>>> like this (these image sizes are from the snapshot repo):
>>>>>
>>>>> 16604006 Jul 26 18:54
>>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>>>> 17086729 Jul 26 18:53
>>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>>>>>
>>>>> 22310769 Nov 1 03:19
>>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>>>> 22744083 Nov 1 03:18
>>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>>>>>
>>>>> 30812531 Nov 30 22:45
>>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>>>> 31248864 Nov 30 22:43
>>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>>>>>
>>>>>
>>>>> The javaee5 images have also grown significantly.
>>>>>
>>>>> 57099671 Jul 26 18:39
>>>>> geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
>>>>> 58685668 Jul 26 18:36
>>>>> geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>>>>>
>>>>> 55113050 Nov 1 03:28
>>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>>>> 56827820 Nov 1 03:25
>>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>>>>>
>>>>> 71313050 Nov 30 22:54
>>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>>>> 73094816 Nov 30 22:50
>>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Bruce
>>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 02/12/2007, at 1:12 PM, Jason Dillon wrote:
> 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 idea is to be able to create aliases with options and arguments.
For instance, I should be able to do that:
> alias startServer1 'start-server -G server.name=yellow -D
otherProperty=otherValue'
then
> execute-alias startServer1
Currently, people could create external files and source them to do
the same thing. However, I think that the above approach may be more
handy.
>
> 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.
I observed couple of problems in here and there; however, I believe
the rsh stuff works sufficiently well at the moment to be enabled in
2.1. This could be flagged as a feature preview planned to be
completed for 2.2. This way we could start to collect user feedback
and re-adjust the feature for 2.2.
What do you think? If you do not like it, then I am happy to commit
this change after 2.1.
Thanks,
Gianny
>
> 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?
>
> --jason
>
>
> -----Original Message-----
> From: Gianny Damour <gi...@optusnet.com.au>
>
> Date: Sun, 2 Dec 2007 12:40:41
> To:dev@geronimo.apache.org
> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>
>
> Hi,
>
> Some heads-up.
>
> 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
> command.
>
> 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
> servers.
>
> Thanks,
> Gianny
>
>
> 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.
>>
>> --jason
>>
>>
>> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>>
>>> Damn gshell...WTF?
>>>
>>> :-)
>>>
>>> I couldn't resist ;-)
>>>
>>> Jeff
>>>
>>> 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...
>>>>
>>>> --jason
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: "Bruce Snyder" <br...@gmail.com>
>>>>
>>>> Date: Sat, 1 Dec 2007 14:52:44
>>>> To:dev@geronimo.apache.org
>>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>>>
>>>>
>>>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>>>> It looks like the size of our images is increasing dramatically
>>>>> (nearly 2x).
>>>>>
>>>>> For example, the geronimo-jetty6-minimal snapshots have been
>>>>> growing
>>>>> like this (these image sizes are from the snapshot repo):
>>>>>
>>>>> 16604006 Jul 26 18:54
>>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>>>> minimal-2.1-20070726.182538-1-bin.zip
>>>>>
>>>>> 22310769 Nov 1 03:19
>>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>>>> minimal-2.1-20071101.014839-2-bin.zip
>>>>>
>>>>> 30812531 Nov 30 22:45
>>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>>>> minimal-2.1-20071130.211933-3-bin.zip
>>>>>
>>>>>
>>>>> The javaee5 images have also grown significantly.
>>>>>
>>>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>>> bin.tar.gz
>>>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>>> bin.zip
>>>>>
>>>>> 55113050 Nov 1 03:28
>>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>>>> 56827820 Nov 1 03:25 geronimo-jetty6-
>>>>> javaee5-2.1-20071101.014839-1-bin.zip
>>>>>
>>>>> 71313050 Nov 30 22:54
>>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>>>> 73094816 Nov 30 22:50 geronimo-jetty6-
>>>>> javaee5-2.1-20071130.211933-2-bin.zip
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Bruce
>>
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Warner <ja...@gmail.com>.
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.
~Jason Warner
On Dec 1, 2007 9:12 PM, Jason Dillon <ja...@planet57.com> wrote:
> 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?
>
> --jason
>
>
> -----Original Message-----
> From: Gianny Damour <gi...@optusnet.com.au>
>
> Date: Sun, 2 Dec 2007 12:40:41
> To:dev@geronimo.apache.org
> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>
>
> Hi,
>
> Some heads-up.
>
> 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
> command.
>
> 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
> servers.
>
> Thanks,
> Gianny
>
>
> 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.
> >
> > --jason
> >
> >
> > On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
> >
> >> Damn gshell...WTF?
> >>
> >> :-)
> >>
> >> I couldn't resist ;-)
> >>
> >> Jeff
> >>
> >> 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...
> >>>
> >>> --jason
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: "Bruce Snyder" <br...@gmail.com>
> >>>
> >>> Date: Sat, 1 Dec 2007 14:52:44
> >>> To:dev@geronimo.apache.org
> >>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
> >>>
> >>>
> >>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
> >>>> It looks like the size of our images is increasing dramatically
> >>>> (nearly 2x).
> >>>>
> >>>> For example, the geronimo-jetty6-minimal snapshots have been
> >>>> growing
> >>>> like this (these image sizes are from the snapshot repo):
> >>>>
> >>>> 16604006 Jul 26 18:54
> >>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> >>>> 17086729 Jul 26 18:53 geronimo-jetty6-
> >>>> minimal-2.1-20070726.182538-1-bin.zip
> >>>>
> >>>> 22310769 Nov 1 03:19
> >>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> >>>> 22744083 Nov 1 03:18 geronimo-jetty6-
> >>>> minimal-2.1-20071101.014839-2-bin.zip
> >>>>
> >>>> 30812531 Nov 30 22:45
> >>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> >>>> 31248864 Nov 30 22:43 geronimo-jetty6-
> >>>> minimal-2.1-20071130.211933-3-bin.zip
> >>>>
> >>>>
> >>>> The javaee5 images have also grown significantly.
> >>>>
> >>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
> >>>> bin.tar.gz
> >>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
> >>>> bin.zip
> >>>>
> >>>> 55113050 Nov 1 03:28
> >>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
> >>>> 56827820 Nov 1 03:25 geronimo-jetty6-
> >>>> javaee5-2.1-20071101.014839-1-bin.zip
> >>>>
> >>>> 71313050 Nov 30 22:54
> >>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
> >>>> 73094816 Nov 30 22:50 geronimo-jetty6-
> >>>> javaee5-2.1-20071130.211933-2-bin.zip
> >>>>
> >>>>
> >>>> 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.
> >>>
> >>> Bruce
> >
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Dillon <ja...@planet57.com>.
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?
--jason
-----Original Message-----
From: Gianny Damour <gi...@optusnet.com.au>
Date: Sun, 2 Dec 2007 12:40:41
To:dev@geronimo.apache.org
Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Hi,
Some heads-up.
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
command.
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
servers.
Thanks,
Gianny
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.
>
> --jason
>
>
> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>
>> Damn gshell...WTF?
>>
>> :-)
>>
>> I couldn't resist ;-)
>>
>> Jeff
>>
>> 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...
>>>
>>> --jason
>>>
>>>
>>> -----Original Message-----
>>> From: "Bruce Snyder" <br...@gmail.com>
>>>
>>> Date: Sat, 1 Dec 2007 14:52:44
>>> To:dev@geronimo.apache.org
>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>>
>>>
>>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>>> It looks like the size of our images is increasing dramatically
>>>> (nearly 2x).
>>>>
>>>> For example, the geronimo-jetty6-minimal snapshots have been
>>>> growing
>>>> like this (these image sizes are from the snapshot repo):
>>>>
>>>> 16604006 Jul 26 18:54
>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>>> minimal-2.1-20070726.182538-1-bin.zip
>>>>
>>>> 22310769 Nov 1 03:19
>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>>> minimal-2.1-20071101.014839-2-bin.zip
>>>>
>>>> 30812531 Nov 30 22:45
>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>>> minimal-2.1-20071130.211933-3-bin.zip
>>>>
>>>>
>>>> The javaee5 images have also grown significantly.
>>>>
>>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> bin.tar.gz
>>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> bin.zip
>>>>
>>>> 55113050 Nov 1 03:28
>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>>> 56827820 Nov 1 03:25 geronimo-jetty6-
>>>> javaee5-2.1-20071101.014839-1-bin.zip
>>>>
>>>> 71313050 Nov 30 22:54
>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>>> 73094816 Nov 30 22:50 geronimo-jetty6-
>>>> javaee5-2.1-20071130.211933-2-bin.zip
>>>>
>>>>
>>>> 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.
>>>
>>> Bruce
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
Some heads-up.
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
command.
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
servers.
Thanks,
Gianny
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.
>
> --jason
>
>
> On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
>
>> Damn gshell...WTF?
>>
>> :-)
>>
>> I couldn't resist ;-)
>>
>> Jeff
>>
>> 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...
>>>
>>> --jason
>>>
>>>
>>> -----Original Message-----
>>> From: "Bruce Snyder" <br...@gmail.com>
>>>
>>> Date: Sat, 1 Dec 2007 14:52:44
>>> To:dev@geronimo.apache.org
>>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>>
>>>
>>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>>> It looks like the size of our images is increasing dramatically
>>>> (nearly 2x).
>>>>
>>>> For example, the geronimo-jetty6-minimal snapshots have been
>>>> growing
>>>> like this (these image sizes are from the snapshot repo):
>>>>
>>>> 16604006 Jul 26 18:54
>>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>>> minimal-2.1-20070726.182538-1-bin.zip
>>>>
>>>> 22310769 Nov 1 03:19
>>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>>> minimal-2.1-20071101.014839-2-bin.zip
>>>>
>>>> 30812531 Nov 30 22:45
>>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>>> minimal-2.1-20071130.211933-3-bin.zip
>>>>
>>>>
>>>> The javaee5 images have also grown significantly.
>>>>
>>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> bin.tar.gz
>>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>>> bin.zip
>>>>
>>>> 55113050 Nov 1 03:28
>>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>>> 56827820 Nov 1 03:25 geronimo-jetty6-
>>>> javaee5-2.1-20071101.014839-1-bin.zip
>>>>
>>>> 71313050 Nov 30 22:54
>>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>>> 73094816 Nov 30 22:50 geronimo-jetty6-
>>>> javaee5-2.1-20071130.211933-2-bin.zip
>>>>
>>>>
>>>> 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.
>>>
>>> Bruce
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Dillon <ja...@planet57.com>.
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.
--jason
On Dec 1, 2007, at 5:16 PM, Jeff Genender wrote:
> Damn gshell...WTF?
>
> :-)
>
> I couldn't resist ;-)
>
> Jeff
>
> 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...
>>
>> --jason
>>
>>
>> -----Original Message-----
>> From: "Bruce Snyder" <br...@gmail.com>
>>
>> Date: Sat, 1 Dec 2007 14:52:44
>> To:dev@geronimo.apache.org
>> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>>
>>
>> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>> It looks like the size of our images is increasing dramatically
>>> (nearly 2x).
>>>
>>> For example, the geronimo-jetty6-minimal snapshots have been growing
>>> like this (these image sizes are from the snapshot repo):
>>>
>>> 16604006 Jul 26 18:54
>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>> minimal-2.1-20070726.182538-1-bin.zip
>>>
>>> 22310769 Nov 1 03:19
>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>> minimal-2.1-20071101.014839-2-bin.zip
>>>
>>> 30812531 Nov 30 22:45
>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>> minimal-2.1-20071130.211933-3-bin.zip
>>>
>>>
>>> The javaee5 images have also grown significantly.
>>>
>>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>> bin.tar.gz
>>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>>> bin.zip
>>>
>>> 55113050 Nov 1 03:28
>>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>>> 56827820 Nov 1 03:25 geronimo-jetty6-
>>> javaee5-2.1-20071101.014839-1-bin.zip
>>>
>>> 71313050 Nov 30 22:54
>>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>>> 73094816 Nov 30 22:50 geronimo-jetty6-
>>> javaee5-2.1-20071130.211933-2-bin.zip
>>>
>>>
>>> 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.
>>
>> Bruce
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jeff Genender <jg...@apache.org>.
Damn gshell...WTF?
:-)
I couldn't resist ;-)
Jeff
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...
>
> --jason
>
>
> -----Original Message-----
> From: "Bruce Snyder" <br...@gmail.com>
>
> Date: Sat, 1 Dec 2007 14:52:44
> To:dev@geronimo.apache.org
> Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
>
>
> On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>> It looks like the size of our images is increasing dramatically (nearly 2x).
>>
>> For example, the geronimo-jetty6-minimal snapshots have been growing
>> like this (these image sizes are from the snapshot repo):
>>
>> 16604006 Jul 26 18:54
>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>>
>> 22310769 Nov 1 03:19
>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>>
>> 30812531 Nov 30 22:45
>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>>
>>
>> The javaee5 images have also grown significantly.
>>
>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>>
>> 55113050 Nov 1 03:28
>> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
>> 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>>
>> 71313050 Nov 30 22:54
>> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
>> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>>
>>
>> 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.
>
> Bruce
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Dillon <ja...@planet57.com>.
No doubt some increase is from the gshell libs. We can probably optimize them a little and use repository references and such...
--jason
-----Original Message-----
From: "Bruce Snyder" <br...@gmail.com>
Date: Sat, 1 Dec 2007 14:52:44
To:dev@geronimo.apache.org
Subject: Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>
> It looks like the size of our images is increasing dramatically (nearly 2x).
>
> For example, the geronimo-jetty6-minimal snapshots have been growing
> like this (these image sizes are from the snapshot repo):
>
> 16604006 Jul 26 18:54
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>
> 22310769 Nov 1 03:19
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>
> 30812531 Nov 30 22:45
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>
>
> The javaee5 images have also grown significantly.
>
> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>
> 55113050 Nov 1 03:28
> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
> 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>
> 71313050 Nov 30 22:54
> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>
>
> 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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Bruce Snyder <br...@gmail.com>.
On Nov 30, 2007 3:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>
> It looks like the size of our images is increasing dramatically (nearly 2x).
>
> For example, the geronimo-jetty6-minimal snapshots have been growing
> like this (these image sizes are from the snapshot repo):
>
> 16604006 Jul 26 18:54
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>
> 22310769 Nov 1 03:19
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>
> 30812531 Nov 30 22:45
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>
>
> The javaee5 images have also grown significantly.
>
> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>
> 55113050 Nov 1 03:28
> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
> 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>
> 71313050 Nov 30 22:54
> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>
>
> 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.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Dillon <ja...@planet57.com>.
We can remove some of the gshell bloat by not using the gshell-
embedable jar which contains xstream, jexl, log4j-diet, jline and some
other bits which are already in the repository. Might drop things
down by 1 or 2m.
Also we can make a diet version of groovy and ant, containing on the
bits which are needed. Might drop another meg or 2.
The mina stuff... um, that might be because of the remote shell
stuff? That probably shouldn't be included...
--jason
On Dec 13, 2007, at 1:03 PM, Joe Bohn wrote:
>
>
> Joe Bohn wrote:
>> It looks like the size of our images is increasing dramatically
>> (nearly 2x).
>> For example, the geronimo-jetty6-minimal snapshots have been
>> growing like this (these image sizes are from the snapshot repo):
>> 16604006 Jul 26 18:54 geronimo-jetty6-minimal-2.1-20070726.182538-1-
>> bin.tar.gz
>> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-
>> bin.zip
>> 22310769 Nov 1 03:19 geronimo-jetty6-minimal-2.1-20071101.014839-2-
>> bin.tar.gz
>> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-
>> bin.zip
>> 30812531 Nov 30 22:45 geronimo-jetty6-minimal-2.1-20071130.211933-3-
>> bin.tar.gz
>> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-
>> bin.zip
>> The javaee5 images have also grown significantly.
>> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>> bin.tar.gz
>> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-
>> bin.zip
>> 55113050 Nov 1 03:28 geronimo-jetty6-javaee5-2.1-20071101.014839-1-
>> bin.tar.gz
>> 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-
>> bin.zip
>> 71313050 Nov 30 22:54 geronimo-jetty6-javaee5-2.1-20071130.211933-2-
>> bin.tar.gz
>> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-
>> bin.zip
>
>
>
>
> Here are the latest image sizes from a build this morning (12/13/07
> svn rev. 603936). While it appears that things have slightly
> improved, there isn't a substantial difference from earlier (esp. in
> the minimal assemblies).
>
>
> 23492694 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.zip
> 23187538 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.tar.gz
>
> 29732445 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.tar.gz
> 30216770 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.zip
>
> 31206202 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.tar.gz
> 31695270 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.zip
>
> 68474964 Dec 13 15:15 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.tar.gz
> 70303613 Dec 13 15:16 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.zip
>
> 69713173 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.tar.gz
> 71559684 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.zip
>
> As you can see, the framework itself is now larger than the minimal
> assemblies used to be. Some of the growth in the framework assembly
> (I'm not intending to imply that these should or should not included
> in framework ... just pointing out the new additions to framework):
>
> - boilerplate minimal assembly (3.6M)
> - ant (1.2M)
> - G-Shell (1.5M)
> - yoko (1.8M)
> - groovy (2.4M)
> - plexus (.5M)
> - woodstox (.5M)
> - cglib (.33M)
> - xstream (.36M)
> - mina (.33M)
>
> That accounts for nearly all of the growth since 2.0.2.
>
>
> Joe
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Joe Bohn <jo...@earthlink.net>.
Joe Bohn wrote:
>
> It looks like the size of our images is increasing dramatically (nearly
> 2x).
>
> For example, the geronimo-jetty6-minimal snapshots have been growing
> like this (these image sizes are from the snapshot repo):
>
> 16604006 Jul 26 18:54
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>
> 22310769 Nov 1 03:19
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>
> 30812531 Nov 30 22:45
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>
>
> The javaee5 images have also grown significantly.
>
> 57099671 Jul 26 18:39 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.tar.gz
> 58685668 Jul 26 18:36 geronimo-jetty6-jee5-2.1-20070726.182538-1-bin.zip
>
> 55113050 Nov 1 03:28
> geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.tar.gz
> 56827820 Nov 1 03:25 geronimo-jetty6-javaee5-2.1-20071101.014839-1-bin.zip
>
> 71313050 Nov 30 22:54
> geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.tar.gz
> 73094816 Nov 30 22:50 geronimo-jetty6-javaee5-2.1-20071130.211933-2-bin.zip
>
Here are the latest image sizes from a build this morning (12/13/07 svn
rev. 603936). While it appears that things have slightly improved,
there isn't a substantial difference from earlier (esp. in the minimal
assemblies).
23492694 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.zip
23187538 Dec 13 15:15 geronimo-framework-2.1-SNAPSHOT-bin.tar.gz
29732445 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.tar.gz
30216770 Dec 13 15:15 geronimo-jetty6-minimal-2.1-SNAPSHOT-bin.zip
31206202 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.tar.gz
31695270 Dec 13 15:16 geronimo-tomcat6-minimal-2.1-SNAPSHOT-bin.zip
68474964 Dec 13 15:15 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.tar.gz
70303613 Dec 13 15:16 geronimo-jetty6-javaee5-2.1-SNAPSHOT-bin.zip
69713173 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.tar.gz
71559684 Dec 13 15:17 geronimo-tomcat6-javaee5-2.1-SNAPSHOT-bin.zip
As you can see, the framework itself is now larger than the minimal
assemblies used to be. Some of the growth in the framework assembly
(I'm not intending to imply that these should or should not included in
framework ... just pointing out the new additions to framework):
- boilerplate minimal assembly (3.6M)
- ant (1.2M)
- G-Shell (1.5M)
- yoko (1.8M)
- groovy (2.4M)
- plexus (.5M)
- woodstox (.5M)
- cglib (.33M)
- xstream (.36M)
- mina (.33M)
That accounts for nearly all of the growth since 2.0.2.
Joe
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote:
>
>
> On Dec 2, 2007, at 6:14 PM, David Jencks <da...@yahoo.com>
> wrote:
>
>>
>> On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote:
>>
>>>
>>>
>>> On Nov 30, 2007 5:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>>
>>> It looks like the size of our images is increasing dramatically
>>> (nearly 2x).
>>>
>>> For example, the geronimo-jetty6-minimal snapshots have been growing
>>> like this (these image sizes are from the snapshot repo):
>>>
>>> 16604006 Jul 26 18:54
>>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>>> 17086729 Jul 26 18:53 geronimo-jetty6-
>>> minimal-2.1-20070726.182538-1-bin.zip
>>>
>>> 22310769 Nov 1 03:19
>>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>>> 22744083 Nov 1 03:18 geronimo-jetty6-
>>> minimal-2.1-20071101.014839-2-bin.zip
>>>
>>> 30812531 Nov 30 22:45
>>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>>> 31248864 Nov 30 22:43 geronimo-jetty6-
>>> minimal-2.1-20071130.211933-3-bin.zip
>>>
>>> Most of the recent jump (fyi my 27 Nov build is only 22 megs) is
>>> caused by boilerplate assembly in our repository (repository/org/
>>> apache/geronimo/assemblies/geronimo-boilerplate-minimal/2.1-
>>> SNAPSHOT/geronimo- boilerplate-minimal-2.1-SNAPSHOT.jar). I would
>>> assume it's caused by david j's http://svn.apache.org/viewvc?
>>> rev=598819&view=rev We should be able to get rid of that...
>>
>> I don't think this is practical if we want to be able to extract
>> servers. We need something that's the layout for the base server
>> with all the crud that isn't in the repo. The boilerplate config
>> is that crud all nicely packed up in a reusable form. I'm
>> certainly open to suggestions but I have no idea how to do
>> anything else for 2.1. To the extent we can get the lib (and
>> gshell) jars into the g. repo we will avoid duplicating these jars
>> and shrink the boilerplate plugin.
>
> Does it have to be included in the assemblies by default? Why not
> install the plugin, if you want to generate servers?
>
At the moment its treated like any other plugin and the base server
structure is installed by copying stuff out of it. I'd rather not
introduce a special case for this stuff but I'll think about whether
there's a reasonable way to do it. I kind of like the idea of
encouraging shrinking the non-repo stuff by duplicating it :-)
thanks
david jencks
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> 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...
>
> --kevan
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Prasad Kashyap <go...@gmail.com>.
I agree. We should make GShell flexible like our Geronimo server.
I don't know if this makes sense but I'll just think aloud. At it's
core should be the most basic features like start/stop and
deploy/undeploy. Since Groovy is the culprit, can Groovy sit this one
out ? I believe we use goals from g-m-p anyways to achieve those basic
features. Everything else should be optionally built up using G-shell
plugins. Groovy support can be one such optional plugin.
Cheers
Prasad
On Dec 5, 2007 9:50 PM, Kevan Miller <ke...@gmail.com> 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...
>
> --kevan
>
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by David Jencks <da...@yahoo.com>.
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
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Donald Woods <dw...@apache.org>.
Agree. We need a minimal runtime that doesn't include all of the
cloning and gshell support, but which can have it added via plugins if
someone wants it.
-Donald
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...
>
> --kevan
>
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Joe Bohn <jo...@earthlink.net>.
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
>
>
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Kevan Miller <ke...@gmail.com>.
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...
--kevan
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Gianny Damour <gi...@optusnet.com.au>.
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
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Jason Dillon <ja...@planet57.com>.
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.
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
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 2, 2007, at 6:14 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote:
>
>>
>>
>> On Nov 30, 2007 5:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>
>> It looks like the size of our images is increasing dramatically
>> (nearly 2x).
>>
>> For example, the geronimo-jetty6-minimal snapshots have been growing
>> like this (these image sizes are from the snapshot repo):
>>
>> 16604006 Jul 26 18:54
>> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
>> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-
>> bin.zip
>>
>> 22310769 Nov 1 03:19
>> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
>> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-
>> bin.zip
>>
>> 30812531 Nov 30 22:45
>> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
>> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-
>> bin.zip
>>
>> Most of the recent jump (fyi my 27 Nov build is only 22 megs) is
>> caused by boilerplate assembly in our repository (repository/org/
>> apache/geronimo/assemblies/geronimo-boilerplate-minimal/2.1-
>> SNAPSHOT/geronimo- boilerplate-minimal-2.1-SNAPSHOT.jar). I would
>> assume it's caused by david j's http://svn.apache.org/viewvc?rev=598819&view=rev
>> We should be able to get rid of that...
>
> I don't think this is practical if we want to be able to extract
> servers. We need something that's the layout for the base server
> with all the crud that isn't in the repo. The boilerplate config is
> that crud all nicely packed up in a reusable form. I'm certainly
> open to suggestions but I have no idea how to do anything else for
> 2.1. To the extent we can get the lib (and gshell) jars into the g.
> repo we will avoid duplicating these jars and shrink the boilerplate
> plugin.
Does it have to be included in the assemblies by default? Why not
install the plugin, if you want to generate servers?
>
> thanks
> david jencks
>
>
>>
>> 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...
--kevan
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by David Jencks <da...@yahoo.com>.
On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote:
>
>
> On Nov 30, 2007 5:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>
> It looks like the size of our images is increasing dramatically
> (nearly 2x).
>
> For example, the geronimo-jetty6-minimal snapshots have been growing
> like this (these image sizes are from the snapshot repo):
>
> 16604006 Jul 26 18:54
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> 17086729 Jul 26 18:53 geronimo-jetty6-minimal-2.1-20070726.182538-1-
> bin.zip
>
> 22310769 Nov 1 03:19
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> 22744083 Nov 1 03:18 geronimo-jetty6-minimal-2.1-20071101.014839-2-
> bin.zip
>
> 30812531 Nov 30 22:45
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> 31248864 Nov 30 22:43 geronimo-jetty6-minimal-2.1-20071130.211933-3-
> bin.zip
>
> Most of the recent jump (fyi my 27 Nov build is only 22 megs) is
> caused by boilerplate assembly in our repository (repository/org/
> apache/geronimo/assemblies/geronimo-boilerplate-minimal/2.1-
> SNAPSHOT/geronimo- boilerplate-minimal-2.1-SNAPSHOT.jar). I would
> assume it's caused by david j's http://svn.apache.org/viewvc?
> rev=598819&view=rev We should be able to get rid of that...
I don't think this is practical if we want to be able to extract
servers. We need something that's the layout for the base server
with all the crud that isn't in the repo. The boilerplate config is
that crud all nicely packed up in a reusable form. I'm certainly
open to suggestions but I have no idea how to do anything else for
2.1. To the extent we can get the lib (and gshell) jars into the g.
repo we will avoid duplicating these jars and shrink the boilerplate
plugin.
thanks
david jencks
>
> 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...
>
> --kevan
>
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
Posted by Kevan Miller <ke...@gmail.com>.
On Nov 30, 2007 5:59 PM, Joe Bohn <jo...@earthlink.net> wrote:
>
> It looks like the size of our images is increasing dramatically (nearly
> 2x).
>
> For example, the geronimo-jetty6-minimal snapshots have been growing
> like this (these image sizes are from the snapshot repo):
>
> 16604006 Jul 26 18:54
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.tar.gz
> 17086729 Jul 26 18:53
> geronimo-jetty6-minimal-2.1-20070726.182538-1-bin.zip
>
> 22310769 Nov 1 03:19
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.tar.gz
> 22744083 Nov 1 03:18
> geronimo-jetty6-minimal-2.1-20071101.014839-2-bin.zip
>
> 30812531 Nov 30 22:45
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.tar.gz
> 31248864 Nov 30 22:43
> geronimo-jetty6-minimal-2.1-20071130.211933-3-bin.zip
>
Most of the recent jump (fyi my 27 Nov build is only 22 megs) is caused by
boilerplate assembly in our repository
(repository/org/apache/geronimo/assemblies/geronimo-boilerplate-minimal/2.1-SNAPSHOT/geronimo-
boilerplate-minimal-2.1-SNAPSHOT.jar). I would assume it's caused by david
j's http://svn.apache.org/viewvc?rev=598819&view=rev We should be able to
get rid of that...
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...
--kevan