Thanks Carsten, I'm not sure if I want/need to strip it down or not. What we want is a "normal" web site that can also display JSR-168 portlets. We'd like a common layout across all the pages though. I've just started looking at this, but it looks like most of the portlet functionality is handled by the PortalGenerator, so it would appear that this should be fairly easy to do. The PortalGenerator calls a PortalManager, which I haven't really looked at yet. I assume the PortalManager needs the portal configuration to do its work.
We also have the case where a single webapp will be hosting multiple portal sites. From what I can tell this should also work since the portal configuration looks like it uses cocoon pipelines. Here, the issue would be how to do personalization differently. The portal documentation says that you can use your own persistence layer but doesn't explain how. So again, any advice would be helpful. Thanks Carsten Ziegeler said: > > >> > If I understand you correctly, you want to strip down the portal > engine and remove the unused classes? > For using Pluto in Cocoon you need all classes in > org.apache.cocoon.portal.pluto(.*) - this is the implementation > required by Pluto to connect Cocoon and Pluto. > > Carsten > >
