portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Schaefer <ch...@bluesunrise.com>
Subject a diet...
Date Thu, 17 Nov 2005 02:50:24 GMT
Hi folks:
    I've been working on getting antinstaller to install jetspeed,  
working with derby, inside tomcat,  to a users computer.  it's going  
well.  but the finished product which is basically the jetspeed-2  
source allBuild  inside tomcat w/ derby is now pushing 200 MB.   This  
is ludicrous!!!

    Why?   well, we have over 200 jar files almost all of which are  
duplicated in the install.  Some, like log4j, have roughly 10 copies.  
Many have 8 copies of a particular jar ( BTW,  we have different  
versions of some of the jars as well ).

    Perhaps a diet is in order?    I don't have a plan for this, but  
I figured I'd launch the discussion.

    The root of the problem is that we package each of our sub- 
projects (applications/pam for example), as though they must stand  
alone.  Yet pam clearly cannot work outside of the context of  
jetspeed itself.  Look at these jars comtained in pam.war :

 >  jar tf /jetspeed/WEB-INF/deploy/pam.war | grep jar | sort
WEB-INF/lib/commons-beanutils-1.6.1.jar
WEB-INF/lib/commons-codec-1.2.jar
WEB-INF/lib/commons-collections-3.0.jar
WEB-INF/lib/commons-digester-1.5.jar
WEB-INF/lib/commons- 
el-1.0.jar                                           <not in  
jetspeed.war
WEB-INF/lib/commons-logging-1.0.3.jar
WEB-INF/lib/commons-validator-1.1.3.jar                          <not  
in jetspeed.war
WEB-INF/lib/jetspeed-statistics-2.0-dev.jar
WEB-INF/lib/jetspeed2-taglib-treecontrol-2.0-dev.jar           <not  
in jetspeed.war
WEB-INF/lib/jstl-1.0.6.jar
WEB-INF/lib/log4j-1.2.8.jar
WEB-INF/lib/myfaces- 
api-1.1.0.jar                                          <not in  
jetspeed.war
WEB-INF/lib/myfaces- 
impl-1.1.0.jar                                         <not in  
jetspeed.war
WEB-INF/lib/portals-bridges-common-0.4-dev.jar             <not in  
jetspeed.war
WEB-INF/lib/portals-bridges-frameworks-0.4-dev.jar             <not  
in jetspeed.war
WEB-INF/lib/portals-bridges-jsf-0.4- 
dev.jar                             <not in jetspeed.war
WEB-INF/lib/portals-bridges-velocity-0.4-dev.jar
WEB-INF/lib/portals-gems-2.0- 
dev.jar                                               <not in  
jetspeed.war
WEB-INF/lib/request-1.0.1.jar
WEB-INF/lib/spring-1.1.5.jar
WEB-INF/lib/standard-1.0.6.jar
WEB-INF/lib/ 
tomahawk-1.1.0.jar                                                 
<not in jetspeed.war
WEB-INF/lib/velocity-1.4.jar
WEB-INF/lib/velocity-tools-1.1.jar

As a first pass, I marked those jars which are already included in  
the jetspeed.jar .  Of the 24 jars, only 10 are not already in the  
jetspeed.jar   I'm pretty sure than many of  those 10 are shared with  
other "components" of our system.  My guess is that pam actually does  
not UNIQUELY depend on any these jars.

Now I know that classloaders will complicate the analysis, but can't  
we move towards putting many of these jars into the jetspeed war and  
leave them out of the various portlet wars?

-C-

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message