On Jun 12, 2007, at 8:23 PM, David Jencks wrote:
Sure, but if you are planning to use this for the admin console
you'll probably need separate modules for jetty and tomcat anyway,
so 2 plans is more or less required even if they are identical.
Not sure I follow you on this. Do you mean that we might create two
separate collections of portlets based on which web container is in
use? Today the admin console the same collection of portlets built
from a single codebase for both containers -- the webconatiner
administration jsps just render differently when running in tomcat
vs. jetty. The only thing I know of that's really different between
the tomcat and jetty admin console modules is their deployment plans,
and I think those could be consolidated.
Or are there other reasons why you think separate modules might be
required, perhaps the security configuration?
Whether or not separate modules are needed for the admin console, if
we want the portal to be extensible by geronimo applications then it
would be best if they can provide a single extension module that
works in both containers. Hopefully the <container-config> technique
that Jeff pointed out will allow them to accomplish that (it worked
for me).
Is pluto 1.2 actually functional as a real portal, or is it just
way easier to deploy portlets to than 1.0 was? My impression was
that it was not really intended to be a jetspeed or liferay
replacement.
No it does not provide equivalent functionality to jetspeed or
liferay. In fact their FAQ says:
Is Pluto an Enterprise Portal?
No, the Pluto project aims to provide a Java Specification
compliant Portlet Container. In order to support the container, the
Pluto project provides a simple portal, however, this does not
provides optional services such as single sign on. If you are
looking for an Open Source enterprise Portal implementation, there
are several available. Apache Jetspeed is an enterprise portal
hosted by the Apache Software Foundation. Sakai and uPortal are
both educational portals which utilize Pluto as their container.
There are many other open source portals.
http://portals.apache.org/pluto/faq.html
So for an enterprise class portal Geronimo users should be encouraged
to look into one of those solutions.
For simple a portal application like the admin console, and for
portlet development and testing purposes I think pluto's portal
driver provides an ideal lightweight solution. And technically
speaking there's nothing that prevents a geronimo user from
installing multiple portal solutions alongside pluto.
I've been hoping that now that jetspeed has m2-ized their build we
might be able to pursue jetspeed integration again.
As mentioned above pluto doesn't claim to provide an enterprise class
solution. It's very lightweight and really intended for simple
portal apps and for portlet development / testing. As long as the
portlets are written against the JSR 168 api they should be portable
across the portal containers. So by all means let's continue to
pursue integration with jetspeed, liferay, etc. We can put all these
goodies into sandbox/portals for now and then later decide if we want
to migrate the useful parts into server/trunk or create a new
subproject.
Best wishes,
Paul
