+1 as this would provide a common schema for other vendor implementations (like MySQL, Oracle, DB2, ...)

-Donald

David Jencks wrote:

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




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to