On Jul 8, 2007, at 1:14 PM, Elliot Metsger wrote:
General,
A thread has been started on pluto-dev [0] about adding some
functionality to the Pluto container which debatedly is "portal-like".
1) Encapsulating portlet assembly in the container, instead of
pushing that down to the portal and the portlet developer.
2) Implementing hot deployment in the container itself, allowing
portals embedding pluto 1.2 to leverage a common implementation of
deployment.
Both features would have callback interfaces delegating portal
specific functionality to the portal.
We'd like your reaction to the idea before moving forward.
[0] http://www.nabble.com/hot-deploy---auto-assembly-design-
tf4041191.html
I don't have a problem with Auto Deploy features in the Pluto Portal
If you are providing a value that is needed by your community now,
then by all means implement it
What does concern me is that we are saying on the PMC list that we
would like to work together as a common team, but then we all
(Jetspeed people included) continue to develop isolated
If you think about the size of our small community, and the fact that
we are developing everything blind of one another does not seem very
community minded or smart for that matter.
I can't help thinking Apache Portals ends up providing confusing
messages to the community to say the least
I strongly believe we, everyone at Apache Portals, should be on the
same team. That is what creating an open source project is all about.
How can the portals community work together in the future? A Portals
Commons project has been suggested. My feelings on that is that its
already been in place from day one. Its called the Jetspeed API.
The Pluto team has some good experience in developing light-weight
portals. Jetspeed tends to specialize more in the big-database
solutions.
I think if we can provide different implementations written to the
same APIs, that would be the best way for us to start working together
I don't see this as a silver bullet and there will be challenges.
For instance, we are not going to be thrilled about throwing away our
API set, and go with another compromised set of APIs. Im sure the
Pluto team feels the same way.
That is a challenge.
Another challenge to deal with: the Jetspeed API is stuck in the
object model classes of the old Pluto API. We will need to upgrade
our API and in doing so, will be forced to deprecate our old APIs
Not a good situation, as it may lead us to create adaptors for the
new container, or a large conversion project, either way undesirable
to say the least
The teams (and PMC) need to work out these issues, and be fair and
supportive to everyone involved. Or we can continue with business as
usual and stay in our "splintered" state.
My vote is to work together.
I don't want to make an example of this one feature that Elliot is
working on.
However, maybe its a good opportunity.
If I may suggest that Jetspeed already has autodeployment interfaces
and implementations. I saw the API discussions on the Pluto list and
no one suggested looking at Jetspeed's APIs.
I know our APIs are not perfect, but perhaps this is a good area to
give this common api concept a shot.
Sort of a practice run, see how it goes...
