On Jun 28, 2007, at 10:38 AM, Kevan Miller wrote:
On Jun 28, 2007, at 12:35 PM, Jay D. McHugh wrote:
The page has been updated to move the contents of repository/
geronimo to repository/org/apache/geronimo.
I found a couple of other places where contents of the repository
moved (tranql -> org/tranql, etc) and fixed those as well.
If anyone sees a module that moved (that I missed) let me know and
I'll rework the table.
I already caught org/apache/geronimo/activemq-broker(1.2) s/b org/
apache/geronimo/configs/activemq-broker but haven't fixed it yet.
For sizing purposes, that will not affect the following results.
Here are the places that I am seeing that the repository has grown
(between 1.1.1 and 2.0):
Added (size rounded to nearest Meg)
com/sun/xml (5M)
commons-codec (1M)
commons-fileupload (1M)
commons-httpclient (1M)
commons-io (1M)
commons-jexl (1M)
commons-lang (1M)
commons-primitives (1M)
directory (1M)
directory-asn1 (1M)
directory-network (1M)
directory-protocols (1M)
directory-shared (1M)
dwr (1M)
javax (1M)
jaxen (1M)
jdbm (1M)
jline (1M)
jstl (1M)
net (1M)
ognl (1M)
org/apache/axis2 (3M)
org/apache/bcel (1M)
org/apache/cxf (2M)
org/apache/httpcomponents (1M)
org/apache/myfaces (1M)
org/apache/neethi (1M)
org/apache/openjpa (3M)
org/apache/ws/commons/axiom (1M)
org/apache/yoko (4M)
org/codehaus/castor (3M)
org/codehaus/swizzle (1M)
org/sl4j (1M)
org/springframework (1)
oro (1M)
regexp (1M)
woodstox (1M)
xml-resolver (1M)
Grew (growth rounded to nearest Meg)
org/apache/activemq (1M)
org/apache/geronimo (Some additions, some reductions: 8M overall -
~5M of this is dojo)
org/apache/tomcat (1M)
org/apache/xbean (1M) - We have 3.0 snapshot and 3.1 snapshot in 2.0
Those are only the increases. There may be more, but these were
the ones that I caught (there are still some moved module issues
yet to be found). As best as I could tell, upgrades between
versions of the same component did not significantly contribute to
the increase in footprint. Additional components is where we got
hit the hardest.
Nice. Thanks for doing this Jay and Prasad...
Nothing really jumps out at me as being unnecessary... Just
scanning that list for the big hitters...
com/sun (5M) is new
org/apache/yoko (4M) is new
org/apache/castor (3M) is new. OpenEJB is no longer dependent on
castor (IIRC) We could look to see who else is dependent on it...
org/apache/openjpa (3M) is new.
org/apache/axis2 (3M)
org/apache/cxf (2M) is new.
All, except perhaps castor, are needed...
If we really wanted to cut down on carbs, we could ask ourselves if
we really need to package Dojo. That would save 5 megs.
The only thing worth spending much time on, IMO, are Geronimo
configs. By my count, configs in 2.0 is 15 Meg. In 1.1.1 they were
3.5 Megs (repository/geronimo/geronimo-*)
Should definitely look at is moving jar files (especially the
redundant ones) out of org/apache/geronimo/configs. As in:
./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
activemq-core-4.1.1.jar
./activemq-ra/2.0-SNAPSHOT/activemq-ra-2.0-SNAPSHOT.car/rar/
activemq-ra-4.1.1.jar
./ca-helper-jetty/2.0-SNAPSHOT/ca-helper-jetty-2.0-SNAPSHOT.car/WEB-
INF/lib/geronimo-ca-helper-2.0-SNAPSHOT.jar
./dojo-jetty6/2.0-SNAPSHOT/dojo-jetty6-2.0-SNAPSHOT.car/WEB-INF/lib/
geronimo-dojo-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-commons-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/asm-tree-2.2.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/cglib-nodep-2.1_3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/geronimo-kernel-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/geronimo-remote-deploy-2.0-SNAPSHOT.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/log4j-1.2.14.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/xpp3-1.1.3.3.jar
./remote-deploy-jetty/2.0-SNAPSHOT/remote-deploy-jetty-2.0-
SNAPSHOT.car/WEB-INF/lib/xstream-1.1.3.jar
./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
tranql-connector-1.3.jar
./system-database/2.0-SNAPSHOT/system-database-2.0-SNAPSHOT.car/rar/
tranql-connector-derby-common-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
tranql-connector-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-db/
tranql-connector-derby-common-1.3.jar
./uddi-jetty6/2.0-SNAPSHOT/uddi-jetty6-2.0-SNAPSHOT.car/uddi-jetty/
WEB-INF/lib/geronimo-uddi-server-2.0-SNAPSHOT.jar
./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
framework.war/WEB-INF/lib/geronimo-console-framework-2.0-SNAPSHOT.jar
./webconsole-jetty6/2.0-SNAPSHOT/webconsole-jetty6-2.0-SNAPSHOT.car/
standard.war/WEB-INF/lib/geronimo-console-standard-2.0-SNAPSHOT.jar
./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
lib/geronimo-servlet_2.5_spec-1.1-20070613.151247-4.jar
./welcome-jetty/2.0-SNAPSHOT/welcome-jetty-2.0-SNAPSHOT.car/WEB-INF/
lib/geronimo-welcome-2.0-SNAPSHOT.jar
I suspect a lot of these are due to m2 war plugin pulling in stuff we
don't expect: this should be easy and a good idea to fix.
The connectors (and maybe amq) are a bit trickier. The standard war
packaging results in pulling copies of the jars in each time you
deploy another instance of a connector. I wonder if it would be
worthwhile to create tranql rars with no jars inside, just the
ra.xmls, and have configurations with the classes (and driver
classes). So we'd have a derby-connector car with the tranql
connector and tranql-derby-connector jar and the derby jars and that
would be a parent of system-database (which would use the no-classes
tranql derby connector rar). Especially with embedded drivers its
pretty much necessary to make sure everyone is loading derby classes
from the same classloader so this would mean we no longer have to use
system-database as a parent, we could use the "classes only" module
instead.
Not sure how much space this would save...
thanks
david jencks
--kevan
