[Warning: *long* email...]
David H. DeWolf wrote:
> <snip>
>
> I'd like to open the discussion of a new portals project. This
> project would be a very lightweight portal implementation which
> provides more than the testbed which pluto provides (in fact, pluto
> would probably be greatly trimmed down or refactored out into this
> project) but no more than the core aggregation services (portlet
> registry, page management, deployment). The hope would be for portals
> such as jetspeed and cocoon to build on top of these core services.
> Additionally, this lightweight portal could be used for developing
> portlets, testing portlets, embedding within web applications which
> need to aggregate content, etc. . .
>
> Another idea we discussed was placing some of these facilities into a
> portal-commons project.
>
> Thoughts?
>
Interesting question, you're actually touching two different subjects here:
- organisation of Apache portals and goals of the various subprojects and
the possible need to restructure the project (portal commons, portal
applications, portal light...)
- core/target features of the different subprojects, mainly Pluto and Jetspeed
To address point one, we need to a have a common vision of the current org
and mission of the different subprojects.
To address point two, we need to take into account the wishes of the
different communities and the technical merits of the current solutions.
To help with point one, I'll provide my personal definitions/vision of the
different Portals efforts..
First, the mandate of Apache Portals: promote portal related technologies
in general and more specifically anything related to JSR-168.
Pluto
-----
Mission:
Provide the RI for a JSR-168 compliant container
Main Use Cases:
- Provide JSR-168 capabilities to an existing system
(container embedding)
- Provide a convenient testbed for JSR-168 portlet developpers
WSRP-4J (is that part of Portals or WS in the end ?)
-------
Mission:
Provide a "reference" WSRP Consumer and Producer implementation
Main use cases:
- Provide WSRP capabilities to an existing portal system
(container embedding)
- Provide a testbed for WSRP interactions
Jetspeed
--------
Mission:
Provide a full-featured, reliable entreprise portal
Main Use Cases:
- Base portal for an ISV product
- Corporate intranet portals
Cocoon Portal (not really Portals project but closely related)
-------------
Mission:
Provide a full-featured, reliable entreprise portal
Main Use Cases:
- Corporate intranet portals
- Internet portals
Bridges
-------
Mission:
Provide development tools and middleware to transform web
applications as portal applications.
Main use cases:
- Port existing web applications as portal applications
- Develop new portal applications with existing well-known
web development framework
Graffito
--------
Mission:
Provide a portal oriented content management system
Main use cases:
- Portal content publishing engine
- Corporate document management
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.
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.
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).
If we can agree on the best technological basis for the portal "light", we
can bootstrap this effort with whatever codebase is selected and have any
of the current committers maintain it in a separate repository.
(as a reminder, all portals committers have access to the complete portals
repository, so it's perfectly possible to reorganise the repository to create
a shared component system without a dedicated community support infra (like
ML, websites, etc...)
OK, enough for now...
--
Raphaël Luta - [EMAIL PROTECTED]
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
