portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: a diet...
Date Thu, 17 Nov 2005 15:41:29 GMT
We may want to look at using Jetty, http://jetty.mortbay.org/jetty/, in our
binary installer version as it is much smaller than Tomcat. 

Regards,
-Scott

> -----Original Message-----
> From: Chris Schaefer [mailto:chris@bluesunrise.com]
> Sent: Wednesday, November 16, 2005 9:50 PM
> To: Jetspeed Developers List
> Subject: a diet...
> 
> 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



---------------------------------------------------------------------
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