Raphaël Luta wrote:
[Warning: *long* email...]
Looking back at these statements we can see we already try to cover a lot
of ground from the basic container (Pluto, WSRP) to full-blown portal engines
(Jetspeed, Cocoon Portal) through middleware (Bridges) and portal application
level stuff (Graffito).
However we miss a "simple" production level portal engine and indeed a
whole portal applications suite.
Now this (portal application suite) is interesting. Didn't we have this
conversation before? :-)
I'll keave the issue of the application suite to another thread, but to get back
to the portal-light issue, my take is the following:
There are 2 basic approaches to have portal light implementation:
- evolve the Pluto portal driver to add enough features to reach production
level
- have a Jetspeed light release with a simplified assembly file with minimum
dependencies
- I don't believe Cocoon can be stripped down enough for this purpose.
I'm not familiar enough with the current feature level of Pluto portal driver
to have a definite idea but the best technical foundation.
I know Jetspeed spreing based architecture and pipeline processing is supposed
to allow us to scale it down easily, but until somebody actually tries it's
more a theoretical possibility than a reality.
That is exactly what we are proposing to do.
We believe it is possible. Give us a chance to prove it first before
diving into something completely new, which might end up conflicting
with and competing with the existing Jetspeed project and community.
We have a 2.01 release to put out next week. We will then start work on
a lightweight assembly of Jetspeed-2. Additionally, we will start
writing light-weight implementations of most of the database components.
We are a small team at Apache Portals. It is essential that we all work
together towards the same vision. This is what Apache is all about.
In the end, I think the critical issue will be community: Pluto currently has
a real stake in providing a light portal since it's required for it to deliver
its second main use case (portlet development testbed) whereas Jetspeed has
less an incentive to do it (the community rather tends to add feature than
keeping it small and simple).
We are adding new features all the time, true, however, features are
added within the context of pluggable component solutions.
One of the most distinguishing features of Jetspeed is the component
model with ISVs in mind. It is the basis of the Jetspeed philosophy to
be able to assemble and plug-in components to specific target, be it a
heavy-weight full featured enterprise portal or a light-weight embedded
portal.
Examples of embedding and specialized solutions:
* Jetspeed-2 running embedded inside Jetspeed 1.6
* Jetspeed-2 running embedded inside Jahia Portal
* Jetspeed-2 running on top of JBoss dedicated for a specific purpose
(http://wfmopen.sourceforge.net/)
