David Sean Taylor wrote:
David,
I would like to suggest that, before even considering an entirely new
Java portal project at Apache Portals, that we first explore the
existing portal's capabilities in providing a light weight portal
deployment. Jetspeed-2, as a Spring component architecture, is capable
of assembling together both full-featured and stripped down portal
deployments. Just a matter of assembling the pieces that you want.
I believe there are some improvements we can make, such as 2nd
non-database implementations of many of the components.
I can't agree more that we should look at the existing portals to see if
they meet our requirements. In fact that's what I'm suggesting - that we
find a way to refactor out just the simplist components of a portal
(from cocoon, pluto, or jetspeed) - those things related to the portlet
registry and the aggregation of those portlets - and make them their own
stand along project. A "simple light weight portal".
The difference between this approach and the one you suggest is simply
how things are organized. I'd like for these components to be building
blocks for jetspeed that exist in a stand along project while you'd like
them to be a part of jetspeed which can be seperated out from the whole.
IMHO creating a simple distribution off of a complex code base does not
really simplify things - in fact, it may make things much more difficult
to maintain.
Have you considered Jetspeed-2 to meet these needs?
I would be interested in hearing your reasons for why not.
If not, I would also like to invite you to working with us as a team
effort in assembling a lightweight Jetspeed portal.
To answer your question directly, yes, I have considered using jetspeed
but have found that it's so much more than I need in some circumstances
that it (up until now) hasn't been worth my time to scale it down. What
I'm suggesting is that we take the time to do that effort now - as a
team - and give it a name.
My vision is to provide:
1) A portal that the average web developer (perhaps with no portlet
experience) can get up and running in a matter of minutes on any
compliant app server.
2) A portal that is lightweight enough to be embedded within any web
application to provide aggregation support. (I find the Geronimo use
case very intruiging and have heard similar discussions associated with
OSGi).
3) A portal that can be used to develop and test portlets
The side effects of this is a starting point upon which other
implementations can be built. It helps us to standardize accross
jetspeed and cocoon.
David
Im +1 on a portal-commons project going thru incubator.
Jetspeed-2 could provide quite a few components to bootstrap that
project. Additionally, to address some of the perceived bloat in
Jetspeed-2, I would like to (re)propose to move all of the Jetspeed-2
sample and admin applications out to another portals sub-project:
Portals Applications.
I'm all for portals applications project and am open to a portals-common
if there are really components that are true "portal utilities" that
don't belong within a simple portal implementation (perhaps the portlet
registry?).
David
