On 12/19/05, Ate Douma <[EMAIL PROTECTED]> 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?
My appologies again. We're apparently talking at different levels. I'll try to put more thought in my responses so this doesn't become a spiraling flame war. There's no doubt that I see great value in jetspeed being more than a thin shell. If in your opinion it's not in the community's best interest to create a new lightweight portal, what do you think about the possibility of reorganizing the jetspeed codebase into two source roots - one for core components which the portal can not run without and one for all of the value added services? > > I see *no* merit in that. Neither do I ;) And that's not what I'm trying to suggest. > > We've put years of work into creating a solid and truly component based > portal which already > can be assembled and configured almost anyway you like it: light-weight, > full-blown or whatever custom/embedded > setup you have in mind. I think one of the areas I'm lacking knowledge in is how all of this can be accomplished. Just because things are organized as components and are assembled with spring doesn't mean that an entire component can be removed with no consequence. In other words, in many cases at least SOME implementation of an interface must be provided and I would prefer to have a solution where the core components know nothing about such an interface. I'll work on providing concrete examples of this. > > Just ripping out some parts so we can have yet another portal setup won't > magically cut a better solution than Jetspeed > already provides today. > > On the contrary, you'll end up with just another component-based portal, but > less thought-through, and with less support > and/or community behind it. > And in the mean-time, it breaks down the merit and purpose of Jetspeed we and > the community have been creating and so > many of our own developers, end-users, ISV and clients depend upon. Let me just reaffirm the fact that I don't want to see the demise of jetspeed. I'm trying very hard to express my desire to have a lightweight portal implementation which fits ALONG SIDE jetspeed - whether this be within jetspeed or next to jetspeed is of no consequence for me. My entire purpose in bringing this up was that a couple of people hinted to me at ApacheCon that they didn't like this lightweight portal implementation being in pluto. This was the first time I had heard that (and is contrary to my understanding of pluto's mission to create a useable test driver). I'm simply opening this discussion to bridge the missing communication so that we can all get on the same page. I'm 100% willing to scrap EVERYTHING I have done in pluto in favor of jetspeed if that's the best solution for the community and I find that jetspeed can fill my needs. I'm just asking for real arguments to help me make that jump (or argue that it shouldn't be made). > > That I will not support: -1. > > But, this doesn't mean I or other Jetspeed team members are not willing to > discuss and work together with > the other Apache Portals and Cocoon Portals team to see how we can help out > with concrete needs from end-users and/or > other projects like Cocoon or Pluto. > If you or others are interested in some (or even a lot) of our components I'm > more than willing to help out integrating > them. Or we can further generalize them so they can be used fully independent. > There I see community merit. > > Ate > > > David H. DeWolf wrote > > > > > > Ate Douma wrote: > >> David H. DeWolf wrote: > >> > >>> On 12/17/05, David Sean Taylor <[EMAIL PROTECTED]> wrote: > >>> > >>>> Raphaël Luta wrote: > >>>> > >>>>> 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. > >>> > >>> > >>> 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. > > > >> > >> For me, to qualify something as a new Apache (Portals) project, it > >> should be something which isn't yet > >> provided for, or existing projects and their community can not or will > >> not provide. > > > > Well, I think that 3 different project allready provide what I'm > > suggesting. So perhaps I'm off base in proposing a new project. Maybe > > consolidation is a better approach???? > > > > My thought was that it would be great to combine what overlaps in those > > 3 projects into a single one which the other 3 can leverage. I guess to > > me, the new aspect that warrents a new project is the cooperation > > between the 3 projects. > > > >> > >> 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. > > > >> > >> We acknowledge that there is a usage for a light-weight portal. If > >> there are area's within Jetspeed > >> which needs to be improved (maybe trimmed down) in a way currently > >> provided for in the Pluto Portal Driver > >> or Cocoon Portal, then we can and will adapt that solution for > >> Jetspeed too. > > > > Again, why does this have to be the approach? Reasons? > > > >> Jetspeed 2 is all about pluggable components so I don't think that > >> will be much of a problem. > >> > >> Also note: this "problem" hasn't been discussed *ever* before with the > >> Jetspeed team. > >> It certainly would be unfair to say upfront Jetspeed won't be able or > >> is unfit to provide an good solution. > > > > No one is accusing jetspeed of anything. Why the defensive attitude? > > I'm suggestion synergy and cooperation, I'm NOT suggesting that jetspeed > > has done anything wrong. > > > >> > >> Right now, I really don't see a valid reason to create a new project > >> just to be able to distinguish from Jetspeed > >> and/or the Pluto Portal Driver or Cocoon Portal. > >> Why, with what purpose? > > > > See above. . . > > > >> > >> 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. > > > > Hmmm. I didn't realize competition was such a contoversial subject. I > > was thinking that by working together we could make more headway, I > > didn't see this as such a you vs. me thing. > > > >> > >> And thus, I fully support David Sean Taylor's proposal and not divide > >> our community up front. > > > > Fair enough. If that's the opinion, I'm all for it. I just wanted to > > see if there was a way we could find common ground and start working > > together. I will move forward in giving jetspeed a fair shake and will > > drop my suggestion of a common "base" portal. Apparently I'm one of the > > only people that thinks it's a valid approach. > > > >> > >> Regards, Ate > >> > >> (note: I've added a few comments more below) > >> > >>> > >>>> 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. > >>> > >>> > >>> +100 - but we need to find the same vision. It's fairly apparent that > >>> we're not on the same page yet. > >> > >> Well, which and whose page we're talking about isn't really clear, is it? > > > > I REALLY don't get why this is such a controversial proposal. It's not > > about me vs. you, it's about trying to create synergy. Why are you > > trying to pit this as you vs. me? > > > >> > >>> I think the first step is diving into > >>> the work that has been done in each project and begining to analyze > >>> what we have. > >> > >> > >> I'm confused. > >> Can you describe *what* this basic portal should contain/provide for? > >> Shouldn't we have a clear vision of its purpose before shopping around > >> for > >> possible features to attach to it? Otherwise it might end up not so > >> "lightweight" > >> any more after all. > > > > Yes, we should. I've stated a couple of times that my vision is: > > > > 1) Portlet Registry > > 2) Aggregation > > 3) Page Management > > 4) Simple installation and deployment > > > > NO VALUE ADDED SERVICES (sso, etc. . .) > > > >> > >> > I have begun to look into jetspeed in more depth (and > >> > >>> hopefully will have time in the near future to look into cocoon as > >>> well). Has anyone else had a chance to look at the changes that have > >>> occured in pluto? What are your thoughts? > >> > >> No, sorry. > >> > >> Getting Bridges 1.0 and Jetspeed 2.0 released just a week ago was a > >> enormous effort > >> the whole Jetspeed team invested all their available spare *and* > >> business time in. > > > > trust me, I understand. I just don't see how the jetspeed team can rule > > out other options before even looking at them. > > > >> > >> I personally intend to review it as soon as I'm back in the > >> Netherlands (next week) though. > >> > >>> > >>>>> 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/) > >>>> > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > > > > >
