Ralph Goers wrote: >>Yes, agreed - there are several issues here discussed at once. I'll >>comment on some of them :) >>Cocoon Portal is currently part of Cocoon (obviously :) ). Now, it >>really lacks of committers and visibility. Noone knows that Cocoon has a >>nice portal solution. Ralph and myself are nearly the only developers on >>the portal. Now what do you guys think of moving the Cocoon portal to >>the portals project to create more visibility and hopefully to make >>collaboration between the various portals projects more efficient? >> >> > > Carsten and I disagree on whether this is a good idea. The cocoon portal > relies on Cocoon constructs and at this point it cannot be used without > the Cocoon framework. So it feels a little wierd to me to move it to > the portals project. However, it is just another Cocoon block and so it > can move to any part of the svn repository. But I'm not sure that > simply moving it to Portals will attract new committers to it. > The marketing would be different - it would not just be "another of the hundreds of blocks of Cocoon", but a portal solution "based on Cocoon". In the end, everything is marketing...
> Wow. It is rare that Carsten and I disagree on something. > :) (It really might be the time zone, I'm 9 hours ahead of you :) ) > Carsten is absolutely right that this idea scares me. While some parts > of the Cocoon portal should and could be the same as Jetspeed, I simply > don't see how it could replace Cocoon's portal. Cocoon as a whole uses > pipelines and source resolvers to leverage XML and XSLT. The Cocoon > portal does the same thing but at the portlet level. Furthermore, the > Portal allows Cocoon pipelines to be used as portlets and it uses > pipelines to obtain all of its configuration. Now, if the J2 portal can > be used and Cocoon just plugs in to the appropriate places to accomplish > the same thing then that would be fine. But I'm not sure that that is > possible which is why I'm suggesting looking for common components instead. > This is exactly what I want to find out when looking at J2. In Cocoon we have the coplet adapter abstraction. It's the interface between the portal and the portlets. For each portlet type (JSR 168, WSRP, Cocoon Pipeline) we use a different adapter - it's a simple interface, similar to the portlet interface but providing sax based xml support instead of writing to an output stream. Now, if j2 would provide this pluggability, I think we have everything we need. Raphael told me at ApacheCon Europe that j2 also has some pipelining mechanism, so it actually sounds not so hard. For the configuration part, I guess that can be pluggable as well. So it seems possible, the remaining question will be if it makes sense. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
