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: Reorganizing Jetspeed repository
Date Sun, 08 Jan 2006 19:48:33 GMT
David Jencks wrote:
> After working on the geronimo integration for a bit I have an opinion  
> on what the most important reorganization step is :-)
> The current jetspeed.war is basically a tomcat-specific artifact.  In  
> order to work in geronimo, I had to build a jetspeed war without any  
> classes or lib entries. I think the current war should be built in a  
> module inside app-servers rather than as the top level artifact.  I  
> also think there needs to be either separate builds for including  
> different amounts of lib jars or a way of customizing the build to  
> include different jars.  (In M2 I think profiles give you some  control 
> like this).

Just curious, where did you put the jar files if not in WEB-INF/lib?

But yes, I agree with you - we need to assemble the distribution as 
different configurations. Its always more or less the same jars and 
classes, but just a different way of packaging for different app 
servers. This sounds very much like Raphael's suggestion to have a 
different configurations. Here is my interpretation:

  	(all the components go here)


So if someone wanted to build geronimo with configuratoin-2, they would 
build the project under /configuration/geronimo/configruation-2

> I'm also not exactly sure what the meaning of most of the stuff in  
> jetspeed.war is.  My uneducated impression is that there are at least  
> one skin and a site layout. Assuming this bears some relationship to  
> the actual contents, I think that having these as separate modules  that 
> are unpacked into the jetspeed war would make it much easier for  
> someone to either construct additional skins or assemble a portal  with 
> exactly the parts they want to use.

the Skins are called decorators, and they are really CSS styles for 
pages and portlets
decorators can be re-used by different configurations
they could be stored in a separate project


Layouts are descriptions of how pages are aggregated such as two column, 
  three-column, one-column, nested. Layouts could also be stored as a 


A configuration can define its own decorators and layouts (I dont really 
see a use case for that though), or include in a decorator or layout in 
the configuration

The site is made up of pages, folders and subsites
Im thinking that a configuration needs to have a default site with it, 
although  a big part of customizing your own portal is defining your own 
site layout (pages, folders).

A custom portal configuration is really the combination of all of the 
above, including the application server destination

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

View raw message