Ate Douma wrote: >Sorry David, I'm at a loss here how to respond to all of this. >> >> You are now accusing me of being overly protective of Jetspeed >> while you are >> suggesting we should split it up and refactor in a way Jetspeed >> itself will be not much >> more than a thin little shell around some "generic" portal framework? >> >> I see *no* merit in that. >>
I really don't see that in David statements. he'd like to build a lightweight portal, sees some issues in the current state of Jetspeed but still wants to have common shared solution instead of simply building a competing portal in Pluto as it could have been done. Please don't read a conclusion into a simple question. The answer may very well be Jetspeed, it's just a matter of *explaining* to all people not intimately familiar with it how it can serve this function. >> But, this doesn't mean I or other Jetspeed team members are not =20 >> willing to discuss and work together with >> the other Apache Portals and Cocoon Portals team to see how we can =20 >> help out with concrete needs from end-users and/or other projects =20 >> like Cocoon or Pluto. >> If you or others are interested in some (or even a lot) of our =20 >> components I'm more than willing to help out integrating them. Or =20 >> we can further generalize them so they can be used fully independent. >> There I see community merit. >> Good. Then would you agree to a possible conclusion of this discussion that would be to create a set of shared components coming for either Jetspeed or Pluto driver or Cocoon portal, and then build three different Apache Portals "products" ? - Pluto driver for basic developer testing - Jetspeed for medium/high-end deployments - Portal light for small scale/medium deployments In the end, it's just a matter of creating a product line that can address most needs while sharing as much as possible to reduce duplication of efforts. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
