Ralph Goers wrote:
I agree with most of your post but I would add one more use case for the
Cocoon Portal.
- Web sites which have a desire to incorporate portlets of various types
(JSR-168, WSRP, bridges, cocoon pipelines, etc) without looking like or
behaving like a portal.
As for what I am most interested in, all the portals will share some
commonality in that they all need to deploy portlets, they all require
security, they all want to provide personalization features, etc.
Ideally, many of these features could be extracted into a set of
frameworks that all the various portals could leverage. However, I
would expect that when integrated into Jetspeed the variety of choices
or set of features would be more extensive than with some of the other
portals.
I'm not really as interested in creating a "light portal" as I am in
sharing as much between the projects as possible. However, at
ApacheCon, the Geronimo team spoke about incorporating Pluto as its
admin console and perhaps into Geronimo itself. If this is done I think
it would make sense that if a Geronimo customer decided to use Jetspeed
instead that they would just get an enhanced portal - ideally, all of
Geronimo's documented procedures would still work.
Likewise, in Cocoon we would prefer to leverage a common code base than
go "borrowing" from other projects.
So what I would like to see is a "portal common" project rather than a
"portal light" project.
This sounds great. It would be great if we could share common
components. I'd like to help Cocoon in this process.
Jetspeed-2 provides a set of components that you can use in your portal
such as a registry component, aggregator component, and page manager
component for example.
These components are downloadable in the 2.0 release at Apache's maven
site under the org.apache.portals.jetspeed-2 group. You can download
them as is, although there are other support component dependencies that
will get drawn in.
As for a "portal common" project, could be interesting, although it may
already exist...
The Jetspeed-2 components already serves this purpose. The components
are ready to use as is. If it helps to build collaboration on these
components, we could consider factoring out, from a project POV, into a
"Jetspeed Components" project that builds alone, without the portal,
although its not really clear what that leaves to the portal, since the
entire Jetspeed portal is built of components. So I guess this idea of
"commons" is somewhat redundant to us, since we already consider
Jetspeed-2 to be the portal component architecture at Apache Portals. I
just want to be careful that we don't factor everything out of Jetspeed
and leave it with nothing.
