David "Master Yoda" Jencks,

When you went through the list of artifacts in our G repo, did you see
any that looked like we may not need it but it may have been picked up
as a M2 transitive dep ?

Cheers
Prasad

On 7/1/07, David Jencks <[EMAIL PROTECTED]> 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
>


Reply via email to