portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: a diet...
Date Thu, 17 Nov 2005 12:24:48 GMT
Chris Schaefer wrote:
> 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.  

We can't move the common jars into jetspeed.war because of the 
classloader, the portlet apps won't see them there.

However, I think we could *try* refactoring common stuff into shared/lib
I know in the past, this created classloader bugs, so we should be careful

A proposed quick diet solution:

* combine security, pam, palm into one jetspeed-admin webapp
* combine 2 JSF webapps into one, move the combined project to Bridges
* combine 2 Struts webapps into one, move combined project into Bridges
* combine RSS, demo into demo portlet (stays in Jetspeed)
* move Perl, PHP apps into Bridges, do not load them as default part  of 
Jetspeed deployment

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

View raw message