On Jun 13, 2007, at 8:20 AM, Paul McMahan wrote:
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).
module == car file (or plugin), i.e. "pre-deployed" application for
javaee apps, and you certainly can't run the same web "module" in
both the jetty and tomcat integrations. So, unless you are proposing
a really big redesign of what is in a module for a web app, you're
going to need separate modules for pluto on jetty and tomcat, the
base console on jetty and tomcat, each bit of additional console on
jetty and tomcat....
It's quite possible for the plans for the jetty and tomcat versions
to be identical (as long as the environment element is added by the
car plugin), but you still get 2 modules.
thanks
david jencks
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
