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