Ate Douma wrote: > Raphaël Luta wrote: >> David H. DeWolf wrote: >>>> Ate Douma wrote: >>>>>> 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. >>>> >>>> <snip> >> >> 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. > > I find this thread now starts to degrade to a level I'm losing my > motivation to continue. > > How did you come to that conclusion? I really am shocked as this is > unjustified and unfair. >
I think the statement that made me think that you were defensive and willing to look only within Jetspeed is : Ate Douma wrote: > A new, independent "basic" portal project within Portals, *will* compete with > Jetspeed and its community. > We certainly aren't the biggest project within Apache to say the least. > As such, I'd suggest we look at finding a solution within Jetspeed first we > all can support and work on. If I misunderstood your opinion, then I apologize. I didn't want to shock you or unfairly treat your opinion and would really appreciate that you continue to take the time to express your opinion in this thread. > <snip> > On the other hand, I do think that all the proposals up to now for: > - creating a new project, and/or > - creating a separate repository, and/or > - splitting up the J2 codebase in two, and/or > - have Cocoon, J2 etc. rebuild/refactored to only extend the new > light-weight portal > - etc. > all dismiss upfront J2 and its community as being capable of providing a > solution which might > not need all this refactoring/splitting/breaking up. > I think we have a very different understanding of the current debate here. If I understand correctly David D's concern, he has a need for a more powerful portal than the current Pluto driver but without all the features of Jetspeed. I believe there's a consensus that neither the current Pluto driver nor Jetspeed 2 really fits the "lightweight production portal" goal. So the answer we're looking for is how to make it happen with minimum disruptions to the existing communities (Jetspeed and Pluto) and at the same time how can we increase the links between the different Portals communities (extended to Cocoon Portals). The argument I've seen so far from David T and yourself are : - Jetspeed 2 has been designed to be embedded and stripped down so we should use it for the lightweight portal and David D (and myself) are just saying that maybe we could also have look at what's in the current Pluto driver and see if it makes a better platform as a lightweight portal. I proposed that we use a targetted feature list as a way to compare the existing codebases and decide which is the best one. I think it would also be incredibly helpful if you or David T would explain here the basic architecture of Jetspeed 2 to help those not familiar with it how it can be easily embedded. It would also be very useful that Craig or David D do the same for Pluto driver. As a separate concern, there seems to be a real demand to provide an easier access to some of the Jetspeed 2 components so that these components can be reused in Pluto or Cocoon Portals without having to deal with the full Jetspeed 2 repository. This has led David D to propose the creation of a portals-commons repository as a mechanism for easy sharing of some code. That summarizes the current state of the debate for me. If I misunderstood any of the issues at hand or the arguments being given, please correct me. > <snip> >> 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. > > I, nor DST, have been doing that, we just don't like it seeing a J2 > solution being disqualified upfront. > I actually would like to see a REAL (yeah I can shout too) list of > technical reasons why we would > need a separate project and/or repository so desperately. > Please, nobody ever said J2 was disqualified upfront. David D has listed some of his concerns with Jetspeed as is (I kept them in the beginning of the mail). Some of them may be real while other a simple misconception, but I think they should be addressed. > <snip> > > And, I'm used to investigate a problem first before providing a solution. > So, before presenting and freezing a feature list for some new > "light-weight" portal which might or might > not be really all needed, shouldn't we talk about which use cases it is > supposed to address and have some > substance (e.g. concrete community/users/clients wishes) for that? > As far as I understand, the needs come from the Pluto community to have a portal targetted at portals beginners that could still be used in a simple production environment. The feature list is my attempt to frame the scope of the problem so that we can work on the solution. I guess what I'm contemplating here is to have a Java equivalent of PHP-Nuke, inadequate for enterprise integration but useful to set up small scale Internet portal sites and very easy to get up and running. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/
