Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
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
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
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
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 [EMAIL PROTECTED] 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
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
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
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
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
On Nov 30, 2007 5:59 PM, Joe Bohn [EMAIL PROTECTED] 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=598819view=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
Re: Our 2.1 assemblies are nearly 2x the size of 2.0.2
On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote: On Nov 30, 2007 5:59 PM, Joe Bohn [EMAIL PROTECTED] 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=598819view=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
On Dec 2, 2007, at 6:14 PM, David Jencks [EMAIL PROTECTED] wrote: On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote: On Nov 30, 2007 5:59 PM, Joe Bohn [EMAIL PROTECTED] 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=598819view=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
On Dec 2, 2007, at 5:10 PM, Kevan Miller wrote: On Dec 2, 2007, at 6:14 PM, David Jencks [EMAIL PROTECTED] wrote: On Dec 2, 2007, at 12:31 PM, Kevan Miller wrote: On Nov 30, 2007 5:59 PM, Joe Bohn [EMAIL PROTECTED] 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=598819view=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
On Nov 30, 2007 3:59 PM, Joe Bohn [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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
