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