Paul,
I've been an advocate of this approach as well so thanks for taking the
initiative on this. I'll take a look at what you've done later today.
There are probably a few issues we'll need to consider if we take this
"plugin" approach - splitting the console components from the underlying
portal infrastructure:
- Uniformity between various portal implementations for how to define
portlet page content, theme/skin definition, and any portal extensions
that we may use.
- Plugin dependencies based upon type - ie. the admin console plugin
would have a pre-req on a "portal" plugin but not necessarily a
particular "portal" plugin if we can pull manage to pull off this
separation.
Perhaps I'm taking this a bit farther than you intended at the moment.
We could certainly just split these components for now and have the
admin console tightly dependent upon a Pluto component. That does
provide some benefits such as in allowing a user to choose the portal
without the admin console and allowing the user to integrate their own
portlets with Geronimo admin functions. That's a good step forward.
Greater flexibility would be in allowing the user to choose the portal
they wish to use but I think this would require more portal standards
that do not yet exist.
Thanks for taking the first step here!
Joe
Paul McMahan wrote:
We have talked about upgrading the admin console to use a more recent
version of pluto. Now that geronimo 2.0 has taken shape I took a look
at pluto 1.2 and found that it has a lot of new features that we should
take advantage of, including the ability to make our admin console more
dynamic and customizable. It is not backwards compatible with the
version that we currently use so we can't just swap in the jars. But
that's OK since I think our goal to make the admin console more dynamic
probably warrants a bit of redesign anyway. I just committed some
stuff to sandbox that demonstrates one technique for integrating pluto
into geronimo, and I think it can serve as the basis for a more dynamic
admin console as well. You can try it out by following these steps:
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/portals
cd portals
mvn
geronimo/bin/deploy.sh install-plugin
pluto-container/target/pluto-container-1.0-SNAPSHOT.car
geronimo/bin/deploy.sh deploy
pluto-portal/target/pluto-portal-1.0-SNAPSHOT.war
geronimo/bin/deploy.sh deploy pluto-testsuite/target/pluto-testsuite.war
point your browser at http://localhost:8080/pluto/portal
This works in the minimal or jee5 assemblies, but right now it only
supports tomcat because the <cross-context> setting is required in
geronimo-web.xml. I was hoping to avoid a separate jetty module just
for that setting, but maybe that's unavoidable. The maven related
stuff could probably use some tuning as well.
While working on this it occurred to me that we could consider providing
a native general purpose portal in geronimo, and the admin console as we
know it today could just be a collection of portlets deployed into it
that are only visible to users with sufficient admin privileges. The
stuff in sandbox could also help us move things in that direction if we
like that idea. Thoughts?
Best wishes,
Paul
