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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
