how do i get off this
list
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 14 December 2005 11:00 PM
To: Portals Discussion
Subject: Re: Synergy In Portals
Hi David,
While Pluto was started as (and continues to be) the Reference Implementation of a JSR-168 container, its users have primarily been developers who want to learn the Portlet API and make sure that their custom portlets conform to it. Therefore, a usable Pluto portal has always been first in users mind and the reason why I created an Ant build for deploying portlets and later the admin portlets. Therefore, I still believe that portlet deployment features (contained in the admin portlets, maven and Ant builds) should remain part of Pluto. They include:
1. Deployment, redeployment and undeployment functions.
2. Portlet application layout modification functions.
All other advanced functions are the purview of an enterprise portal.
I believe that by being affiliated with JSR-168 (and soon JSR-286), Pluto will always be the entry point and verification point for portlet developers, so we need to facilitate that role. That will benefit Cocoon, Jetspeed and other enterprise portals as developers 'graduate' from their Pluto apprenticeship.
I also believe the Portals-Bridges needs to be reorganized. I suggest something like:
1. Portals-Commons containing the Common Utilities and Interfaces, Portlet Filter and Frameworks subproject now in Portals-Bridges. David Sean Taylor has also suggested this. I believe there is a need for a native JSR-168-based development framework (like Struts, JSF or Tapestry) and this project is the place for that. This project should also contain common portal code as has been suggested by others.
2. Portals-Bridges for the JSF, Struts, PHP, Velocity, and Perl Bridges.
3. Portals-Applications to hold JSR-168 compliant portlet applications as David Sean Taylor has suggested. Since not every open source and commercial portlet app will be in this project, I would also like to see some sort of portlet application wiki page or matrix be part of this project that would point to other JSR-168 compliant portlets available on the web.
Perhaps Portals-Commons should contain Portals-Bridges and Portals-Applications as subprojects, but that is open to debate.
/Craig
----------------------------------------------------
Craig Doremus
Pluto Committer
----------------------------------------------------
| "David H. DeWolf"
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 12/13/2005 12:26 PM
|
|
oops, the general list didn't recognize my gmail account the first go-around.
---------- Forwarded message ----------
From: David H. DeWolf <[EMAIL PROTECTED]>
Date: Dec 13, 2005 12:29 AM
Subject: Synergy In Portals
To: [email protected]
Cc: [email protected], Jetspeed Developers List
<[email protected]>
*********************************
I am copying this email to multiple lists to make sure that all
portals projects are aware of the discussion. Please *only reply* to
the [email protected] address to reduce traffic.
*********************************
We had some great discussions tonight at ApacheCon concerning gaining
momentum and synergy between the portals (and related) projects.
Specifically, we addressed the need to determine where the line is
between pluto and enterprise portal implementations (specifically,
jetspeed and cocoon) .
There seems to be a need for a "lightweight" portal implementation
which provides standard aggregation services, but does not include all
of the bells and whistles (value added services such as cms, sso, etc.
. .). Pluto has been moving towards this point, but it isn't
necessarily the place for this (the portlet container should be the
primary need). Additionally, other common functions (i.e. autodeploy
- which both jetspeed and cocoon have implemented) may be beyond the
scope of pluto, but do not have a common home - thus duplicating work.
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?
I'm looking forward to hearing suggestions on how we can address these
concerns and start working more closely together across portals
projects. . .
David
