Le 18 dec. 05 =E0 00:03, David Sean Taylor a ecrit : >> Raphael Luta wrote: > >>>> [Warning: *long* email...] >>>> Looking back at these statements we can see we already try to >>>> cover a lot >>>> of ground from the basic container (Pluto, WSRP) to full-blown >>>> portal engines >>>> (Jetspeed, Cocoon Portal) through middleware (Bridges) and portal >>>> application >>>> level stuff (Graffito). >>>> However we miss a "simple" production level portal engine and >>>> indeed a >>>> whole portal applications suite. > >> >> Now this (portal application suite) is interesting. Didn't we have >> this >> conversation before? :-)
I didn't say I was in favor, just something we don't do right now and that we could provide. You know my concerns about this but I'm OK to rediscuss this in another dedicated thread... >> > >>>> I'll keave the issue of the application suite to another thread, >>>> but to get back >>>> to the portal-light issue, my take is the following: >>>> There are 2 basic approaches to have portal light implementation: >>>> - evolve the Pluto portal driver to add enough features to reach >>>> production >>>> level >>>> - have a Jetspeed light release with a simplified assembly file >>>> with minimum >>>> dependencies >>>> - I don't believe Cocoon can be stripped down enough for this >>>> purpose. >>>> I'm not familiar enough with the current feature level of Pluto >>>> portal driver >>>> to have a definite idea but the best technical foundation. >>>> I know Jetspeed spreing based architecture and pipeline processing >>>> is supposed >>>> to allow us to scale it down easily, but until somebody actually >>>> tries it's >>>> more a theoretical possibility than a reality. >>>> > >> That is exactly what we are proposing to do. >> We believe it is possible. Give us a chance to prove it first before >> diving into something completely new, which might end up >> conflicting with and competing with the existing Jetspeed project >> and community. >> >> We have a 2.01 release to put out next week. We will then start >> work on >> a lightweight assembly of Jetspeed-2. Additionally, we will start >> writing light-weight implementations of most of the database >> components. >> >> We are a small team at Apache Portals. It is essential that we all >> work >> together towards the same vision. This is what Apache is all about. >> I think you're overreacting somewhat, we're simply discussing alternatives and trying to come to a common vision and how to fulfill that need. Nobody has ever suggested starting a new codebase from scratch. >>>> In the end, I think the critical issue will be community: Pluto >>>> currently has >>>> a real stake in providing a light portal since it's required for >>>> it to deliver >>>> its second main use case (portlet development testbed) whereas >>>> Jetspeed has >>>> less an incentive to do it (the community rather tends to add >>>> feature than >>>> keeping it small and simple). > >> We are adding new features all the time, true, however, features are >> added within the context of pluggable component solutions. >> >> One of the most distinguishing features of Jetspeed is the component >> model with ISVs in mind. It is the basis of the Jetspeed philosophy to >> be able to assemble and plug-in components to specific target, be it a >> heavy-weight full featured enterprise portal or a light-weight >> embedded >> portal. >> >> Examples of embedding and specialized solutions: >> >> * Jetspeed-2 running embedded inside Jetspeed 1.6 >> * Jetspeed-2 running embedded inside Jahia Portal >> * Jetspeed-2 running on top of JBoss dedicated for a specific purpose >> (http://wfmopen.sourceforge.net/) >> Thank you for providing some specific embedding examples (I guess IT Groundwork would qualify too) it will help those not familiar with the codebase get an idea of the capabilities of the Jetspeed project. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
