portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Reorganizing Jetspeed repository
Date Sun, 08 Jan 2006 21:11:27 GMT

On Jan 8, 2006, at 11:48 AM, David Sean Taylor wrote:

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

A geronimo serve is constructed out of configurations, which consist  
of a classloader and some components.  The classloader can include  
classes packed in the configuration and some (external) jars (from  
the maven-like geronimo repository) and can have multiple parents.   
For example, a j2ee application (ear file, war file, etc etc) gets  
turned into a configuration.  We can include jars from the repository  
in the ear configuration rather than including them directly in the  
ear: this avoids duplication.

So, I have one (non-j2ee) base configuration that has the jars that  
in tomcat go into shared, and an ear that has jetspeed.war and all  
the portlet apps in it.  In order for this to work in geronimo, I  
have all the jars that for tomcat are packed into jetspeed.war listed  
as external dependencies of the ear.    I could not get the  
deployment of local portlet apps to work from inside jetspeed.war, so  
I hacked up the regular jetspeedComponentServlet to accept local wars  
and determine that they are local by whether they start with jetspeed-.

I'm more or less amazed at the number of jars included in  
jetspeed.war.  I strongly suspect that 90% of them are needed only  
for the portlet apps and wonder if there is some way to make that  
clearer.  In geronimo we can do that easily but that would not work  
for non-geronimo jetspeed setups.
>
> 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:
>
> /jetspeed-components
>  	(all the components go here)
>
> /configurations
> 	/tomcat
> 		/configuration-1
> 		/configuration-2
> 		...
> 	/geronimo
> 		/configuration-1
> 		/configuration-2
>
> 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
>
> /decorators
>
> Layouts are descriptions of how pages are aggregated such as two  
> column,  three-column, one-column, nested. Layouts could also be  
> stored as a project
>
>
> /layouts
>
> 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

Excellent, thanks for the explanation.  I think making this  
modularity clearer would really help newbies understand how to set up  
their own portal.

thanks
david jencks

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