I absolutely agree that we should do something like this. Now, for example - as you mentioned - Cocoon and J2 have both an autodeploy feature. Now, actually I grapped the code from J2, removed everything J2 specific, improved it... :) ...and then added it to Cocoon. There are only small differences in the end that could be abstracted. And i think there are other areas where such a synergy would make sense. Another one could be some kind of ajax support for portlets (don't know what exactly this could be, but I think this sounds cool, or?)
Personally, I see no problem doing this in subprojects of Pluto, but I would be fine with a commons project as well. Carsten David H. DeWolf wrote: > ********************************* > I am copying this email to multiple lists to make sure that all > portals projects are aware of the discussion. Please *only reply* to > the [email protected] address to reduce traffic. > ********************************* > > We had some great discussions tonight at ApacheCon concerning gaining > momentum and synergy between the portals (and related) projects. > Specifically, we addressed the need to determine where the line is > between pluto and enterprise portal implementations (specifically, > jetspeed and cocoon) . > > There seems to be a need for a "lightweight" portal implementation > which provides standard aggregation services, but does not include all > of the bells and whistles (value added services such as cms, sso, etc. > . .). Pluto has been moving towards this point, but it isn't > necessarily the place for this (the portlet container should be the > primary need). Additionally, other common functions (i.e. autodeploy > - which both jetspeed and cocoon have implemented) may be beyond the > scope of pluto, but do not have a common home - thus duplicating work. > > I'd like to open the discussion of a new portals project. This > project would be a very lightweight portal implementation which > provides more than the testbed which pluto provides (in fact, pluto > would probably be greatly trimmed down or refactored out into this > project) but no more than the core aggregation services (portlet > registry, page management, deployment). The hope would be for portals > such as jetspeed and cocoon to build on top of these core services. > Additionally, this lightweight portal could be used for developing > portlets, testing portlets, embedding within web applications which > need to aggregate content, etc. . . > > Another idea we discussed was placing some of these facilities into a > portal-commons project. > > Thoughts? > > I'm looking forward to hearing suggestions on how we can address these > concerns and start working more closely together across portals > projects. . . > > David > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
