David H. DeWolf wrote: >> >> Ate Douma wrote: > >>>> David H. DeWolf wrote: >> >>>>>> On 12/17/05, David Sean Taylor <[EMAIL PROTECTED]> wrote: >>>>>> >>> >>>>>>>> Raphael Luta wrote: >>> >>>>>> <snip> >>>>>> I find this statement a little misleading. No one is suggesting we >>>>>> start something completely new. In fact, what I've continually said >>>>>> is that we need to take a look at what allready exists (between >>>>>> jetspeed, cocoon, and pluto) and refactor it into a basic portal >>>>>> which >>>>>> is distributed and developed seperately. >> >>>> Now, I really can't agree with the usage of the term "misleading" >>>> here. >>>> Didn't you start this discussion asking for a new portals project? > >> >> Ok, fair enough. Perhaps misleading was a bad choice of words. I >> appologize if it was offensive. Maybe misinformed is a better >> choise. While I'm suggesting that we consider a new project, I've >> also said several times that I think it can be based off of code >> that allready exists. To me, that is totally different than >> "completely new". Completely new implies brand new code. >> <snip> > >>>> Up until now, I haven't heard any valid reason why the Jetspeed >>>> project and its community would be >>>> unable or not fit to provide a light-weight/base portal solution. > >> >> 1) Currently no light weight implementation exists. The codebase >> is rather complex and goes way beyond the requirements of a simple >> embedded aggregation server. >> >> 2) Some parts of jetspeed overlap with components needed in pluto >> and cocoon. IMHO We should find a way to develop these as a team >> and not in isolation of each other. >> >> 3) Jetspeed does not currently support users that are brand new to >> portals and want to start learning, testing, developing portlets. >> I'd like to see something that a brand new portlet developer can >> get up and running in (literally) 3 mintues. >> >> 4) The jetspeed codebase and build are very complex. In fact, I >> heard many complaints about the build system at ApacheCon. One of >> the ways I like to simplify things is to break things into core and >> value added services. By breaking out the the core components of >> jetspeed into a seperate project upon which jetspeed builds upon, >> developers will be able to more clearly see the line between core >> components of the portal and value added services, and jetspeed as >> a whole will become easier to maintain. >> >> 5) Because this solution which we are discussing should support >> jetspeed, cocoon, and pluto, creating a new project from the best >> components of each of the projects will help encourage a community >> atmosphere where developers aren't defensive about ownership, >> design, etc. . .By picking a single project and using it, I'm >> affraid only that projects needs will be met. >> >> > >>>> On the contrary, David, myself, and at least all the other >>>> Jetspeed team members which were at ApacheCon, >>>> are very open to discuss such a solution and see how (not "if") we >>>> can provide it from within our >>>> project and community. > >> >> I guess that's my point. I don't understand why the default answer >> is from "within jetspeed". I think we should make an objective >> descision based on what's best for the community, cocoon, pluto, >> and jetspeed. It's VERY possible that the answer to this descision >> is that the solution is housed within jetpeed, however, I think >> that all solutions should be considered. >> >> Why has the jetspeed team has taken this suggestion as a challenge? >> The comments all seem to be defensive and suggesting that jetspeed >> is the only viable solution. I'd like to hear REAL REASONS as to >> why this simple portal solution should be provided within jetspeed >> just as you'd like to hear reasons for placing it elsewhere. >> >> I appologize if that's a controversial statement. >>
I completey agree with David here, there's no need to be so defensive of Jetspeed that we don't even allow not-Jetspeed people the right to make up their mind. We're currently looking for a consensus on whether and how best provide a light portal solution. No option should be dismissed before being considered. What I'd like to see is a technical debate where we can each explain our preferred way forward and rather than a "my solution is better than yours" contest. David has raised some concerns about Jetspeed that need to be addressed and at the same time I think the best starting point for talking about the technology is to start listing the features we want in this lightweight portal and based on that list, look at which of the 2 current options makes most sense to get there. I'll comment David's feature list in another reply. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
