You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "David H. DeWolf" <dd...@apache.org> on 2005/12/13 09:29:25 UTC
Synergy In Portals
*********************************
I am copying this email to multiple lists to make sure that all
portals projects are aware of the discussion. Please *only reply* to
the general@portals.apache.org address to reduce traffic.
*********************************
We had some great discussions tonight at ApacheCon concerning gaining
momentum and synergy between the portals (and related) projects.
Specifically, we addressed the need to determine where the line is
between pluto and enterprise portal implementations (specifically,
jetspeed and cocoon) .
There seems to be a need for a "lightweight" portal implementation
which provides standard aggregation services, but does not include all
of the bells and whistles (value added services such as cms, sso, etc.
. .). Pluto has been moving towards this point, but it isn't
necessarily the place for this (the portlet container should be the
primary need). Additionally, other common functions (i.e. autodeploy
- which both jetspeed and cocoon have implemented) may be beyond the
scope of pluto, but do not have a common home - thus duplicating work.
I'd like to open the discussion of a new portals project. This
project would be a very lightweight portal implementation which
provides more than the testbed which pluto provides (in fact, pluto
would probably be greatly trimmed down or refactored out into this
project) but no more than the core aggregation services (portlet
registry, page management, deployment). The hope would be for portals
such as jetspeed and cocoon to build on top of these core services.
Additionally, this lightweight portal could be used for developing
portlets, testing portlets, embedding within web applications which
need to aggregate content, etc. . .
Another idea we discussed was placing some of these facilities into a
portal-commons project.
Thoughts?
I'm looking forward to hearing suggestions on how we can address these
concerns and start working more closely together across portals
projects. . .
David
Re: Synergy In Portals
Posted by Carsten Ziegeler <cz...@apache.org>.
I absolutely agree that we should do something like this. Now, for
example - as you mentioned - Cocoon and J2 have both an autodeploy
feature. Now, actually I grapped the code from J2, removed everything J2
specific, improved it... :) ...and then added it to Cocoon. There are
only small differences in the end that could be abstracted.
And i think there are other areas where such a synergy would make sense.
Another one could be some kind of ajax support for portlets (don't know
what exactly this could be, but I think this sounds cool, or?)
Personally, I see no problem doing this in subprojects of Pluto, but I
would be fine with a commons project as well.
Carsten
David H. DeWolf wrote:
> *********************************
> I am copying this email to multiple lists to make sure that all
> portals projects are aware of the discussion. Please *only reply* to
> the general@portals.apache.org address to reduce traffic.
> *********************************
>
> We had some great discussions tonight at ApacheCon concerning gaining
> momentum and synergy between the portals (and related) projects.
> Specifically, we addressed the need to determine where the line is
> between pluto and enterprise portal implementations (specifically,
> jetspeed and cocoon) .
>
> There seems to be a need for a "lightweight" portal implementation
> which provides standard aggregation services, but does not include all
> of the bells and whistles (value added services such as cms, sso, etc.
> . .). Pluto has been moving towards this point, but it isn't
> necessarily the place for this (the portlet container should be the
> primary need). Additionally, other common functions (i.e. autodeploy
> - which both jetspeed and cocoon have implemented) may be beyond the
> scope of pluto, but do not have a common home - thus duplicating work.
>
> I'd like to open the discussion of a new portals project. This
> project would be a very lightweight portal implementation which
> provides more than the testbed which pluto provides (in fact, pluto
> would probably be greatly trimmed down or refactored out into this
> project) but no more than the core aggregation services (portlet
> registry, page management, deployment). The hope would be for portals
> such as jetspeed and cocoon to build on top of these core services.
> Additionally, this lightweight portal could be used for developing
> portlets, testing portlets, embedding within web applications which
> need to aggregate content, etc. . .
>
> Another idea we discussed was placing some of these facilities into a
> portal-commons project.
>
> Thoughts?
>
> I'm looking forward to hearing suggestions on how we can address these
> concerns and start working more closely together across portals
> projects. . .
>
> David
>
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Synergy In Portals
Posted by Carsten Ziegeler <cz...@apache.org>.
David Sean Taylor wrote:
>
> I would like to suggest that, before even considering an entirely new
> Java portal project at Apache Portals, that we first explore the
> existing portal's capabilities in providing a light weight portal
> deployment. Jetspeed-2, as a Spring component architecture, is capable
> of assembling together both full-featured and stripped down portal
> deployments. Just a matter of assembling the pieces that you want.
> I believe there are some improvements we can make, such as 2nd
> non-database implementations of many of the components.
>
> Have you considered Jetspeed-2 to meet these needs?
> I would be interested in hearing your reasons for why not.
> If not, I would also like to invite you to working with us as a team
> effort in assembling a lightweight Jetspeed portal.
>
Hmm, but doesn't this approach rule out other portal solutions, like
Cocoon? (perhaps I'm missinterpreting this)
What I really would like to approach is more synergy between the two
portal solutions at Apache, J2 and Cocoon. Unfortunately I don't know
that much about J2; but I could imagine that perhaps we could either use
a common base or at least share some components - or, which I would
prefer as a final result - merge those two solutions. I guess that both
solutions have some parts in common and I also guess that Cocoon might
be more flexible in some parts and we have the event mechanism. If we
would get all of this somehow into J2, we could just ditch the Cocoon
solution :( (Which would make me obsolete...)
As a first question, what do you think, would it be possible to run J2
inside of a web framework like Cocoon, where Cocoon is just kind of a proxy?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
David Sean Taylor wrote:
>>
> David,
>
>
> I would like to suggest that, before even considering an entirely new
> Java portal project at Apache Portals, that we first explore the
> existing portal's capabilities in providing a light weight portal
> deployment. Jetspeed-2, as a Spring component architecture, is capable
> of assembling together both full-featured and stripped down portal
> deployments. Just a matter of assembling the pieces that you want.
> I believe there are some improvements we can make, such as 2nd
> non-database implementations of many of the components.
I can't agree more that we should look at the existing portals to see if
they meet our requirements. In fact that's what I'm suggesting - that we
find a way to refactor out just the simplist components of a portal
(from cocoon, pluto, or jetspeed) - those things related to the portlet
registry and the aggregation of those portlets - and make them their own
stand along project. A "simple light weight portal".
The difference between this approach and the one you suggest is simply
how things are organized. I'd like for these components to be building
blocks for jetspeed that exist in a stand along project while you'd like
them to be a part of jetspeed which can be seperated out from the whole.
IMHO creating a simple distribution off of a complex code base does not
really simplify things - in fact, it may make things much more difficult
to maintain.
>
> Have you considered Jetspeed-2 to meet these needs?
> I would be interested in hearing your reasons for why not.
> If not, I would also like to invite you to working with us as a team
> effort in assembling a lightweight Jetspeed portal.
>
To answer your question directly, yes, I have considered using jetspeed
but have found that it's so much more than I need in some circumstances
that it (up until now) hasn't been worth my time to scale it down. What
I'm suggesting is that we take the time to do that effort now - as a
team - and give it a name.
My vision is to provide:
1) A portal that the average web developer (perhaps with no portlet
experience) can get up and running in a matter of minutes on any
compliant app server.
2) A portal that is lightweight enough to be embedded within any web
application to provide aggregation support. (I find the Geronimo use
case very intruiging and have heard similar discussions associated with
OSGi).
3) A portal that can be used to develop and test portlets
The side effects of this is a starting point upon which other
implementations can be built. It helps us to standardize accross
jetspeed and cocoon.
David
> Im +1 on a portal-commons project going thru incubator.
> Jetspeed-2 could provide quite a few components to bootstrap that
> project. Additionally, to address some of the perceived bloat in
> Jetspeed-2, I would like to (re)propose to move all of the Jetspeed-2
> sample and admin applications out to another portals sub-project:
> Portals Applications.
I'm all for portals applications project and am open to a portals-common
if there are really components that are true "portal utilities" that
don't belong within a simple portal implementation (perhaps the portlet
registry?).
David
>
>
>
Re: Synergy In Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
David H. DeWolf wrote:
>
> *********************************
> I am copying this email to multiple lists to make sure that all
> portals projects are aware of the discussion. Please *only reply* to
> the general@portals.apache.org address to reduce traffic.
> *********************************
>
> We had some great discussions tonight at ApacheCon concerning gaining
> momentum and synergy between the portals (and related) projects.
> Specifically, we addressed the need to determine where the line is
> between pluto and enterprise portal implementations (specifically,
> jetspeed and cocoon) .
>
> There seems to be a need for a "lightweight" portal implementation
> which provides standard aggregation services, but does not include all
> of the bells and whistles (value added services such as cms, sso, etc.
> . .). Pluto has been moving towards this point, but it isn't
> necessarily the place for this (the portlet container should be the
> primary need). Additionally, other common functions (i.e. autodeploy
> - which both jetspeed and cocoon have implemented) may be beyond the
> scope of pluto, but do not have a common home - thus duplicating work.
>
> I'd like to open the discussion of a new portals project. This
> project would be a very lightweight portal implementation which
> provides more than the testbed which pluto provides (in fact, pluto
> would probably be greatly trimmed down or refactored out into this
> project) but no more than the core aggregation services (portlet
> registry, page management, deployment). The hope would be for portals
> such as jetspeed and cocoon to build on top of these core services.
> Additionally, this lightweight portal could be used for developing
> portlets, testing portlets, embedding within web applications which
> need to aggregate content, etc. . .
>
> Another idea we discussed was placing some of these facilities into a
> portal-commons project.
>
> Thoughts?
>
> I'm looking forward to hearing suggestions on how we can address these
> concerns and start working more closely together across portals
> projects. . .
>
> David
>
>
David,
I would like to suggest that, before even considering an entirely new
Java portal project at Apache Portals, that we first explore the
existing portal's capabilities in providing a light weight portal
deployment. Jetspeed-2, as a Spring component architecture, is capable
of assembling together both full-featured and stripped down portal
deployments. Just a matter of assembling the pieces that you want.
I believe there are some improvements we can make, such as 2nd
non-database implementations of many of the components.
Have you considered Jetspeed-2 to meet these needs?
I would be interested in hearing your reasons for why not.
If not, I would also like to invite you to working with us as a team
effort in assembling a lightweight Jetspeed portal.
Im +1 on a portal-commons project going thru incubator.
Jetspeed-2 could provide quite a few components to bootstrap that
project. Additionally, to address some of the perceived bloat in
Jetspeed-2, I would like to (re)propose to move all of the Jetspeed-2
sample and admin applications out to another portals sub-project:
Portals Applications.
Re: Synergy In Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
David H. DeWolf wrote:
>
>
> Ate Douma wrote:
>
>> David H. DeWolf wrote:
>>
>>> On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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.
From your email to this list on Dec 13, 2005, you said
"I'd like to open the discussion of a new portals project."
Thanks for your public apology, but your new choice of words still
leaves some question in my mind.
Please clarify:
Are you trying to say I that I am "mis-informing" this list, or that I
was "mis-informed" on this list, i.e. that someone mis-informed me.
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
On 12/19/05, Ate Douma <at...@douma.nu> 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 <da...@bluesunrise.com> 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/)
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
Re: Synergy In Portals
Posted by Ate Douma <at...@douma.nu>.
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.
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.
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.
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 <da...@bluesunrise.com> 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/)
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
David H. DeWolf wrote:
>>>> 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 would go a bit further than that for a production level portal, no
matter how lightweight it is.
Features required:
--------------------
1- Ease of install
2- Auto-deployment of Portlet applications
3- Ability to integrate page fragments in portlet WAR
4- Declarative page structure
5- Aggregation engine
6- Basic time based caching mechanism
7- Stand-alone user management
8- Declarative security
9- Admin GUI for managing user, security, pages
and portlet deployment
10- Support for major servlet containers: tomcat, jetty, jboss
11- Portal admin manual
Feature *not* required:
------------------------
- user level interactive layout customization
- integration with external user database or authentication service
- advanced caching facilities
- clustering support
I'll let others add their own feature list here before commenting on
the technical aspect.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
>
> I'm open to starting afresh though in a new thread. I think we should
> finish
> this thread soon now too so we can leave our "misunderstandings" behind.
>
+1
Re: Synergy In Portals
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta wrote:
> 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.
Alright, I won't back out :-)
To clear this up: as you can read in my sentence you quoted, I *suggest* looking for a solution
within Jetspeed *first*. I didn't say or mean I'm not open to other solutions.
I do think however a new independent portal project will compete with J2 (certainly for attention
and dev. effort), and thus I don't very much like the idea.
But, once again: I wouldn't be against it if it turned out to be the best solution for a real problem
our community needs or wants to solve.
>
>> <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.
Agreed :-)
>
> 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.
Well, maybe, maybe not. One of the problems I have with this part of the
discussion is the abstract notion of such a "lightweight production portal".
What exactly is it, what does it provide Pluto doesn't and what currently
provided by Jetpeed should it *not* provide?
You know, up until this discussion, I never, ever heart anyone complain about
Jetspeed being too heavy. On the contrary, usually we are compared to JBoss Portal,
Liferay or Exo and found still lacking in features (we *are* catching up though).
I honestly don't get it what is so "heavy" about Jetspeed that it is getting
in the way or blocking usage for "light-weight" purposes.
I guess that is one of the things I'd like to see cleared up.
>
> 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).
+1
>
> 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
I, and I think David T too, say "could" not "should".
>
> 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.
As i already brought up before, I rather would like to see a description
of the actual problem we are trying to solve here and what might be
needed to solve it first instead of jumping into a feature comparison of our
codebases.
> 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.
True. And we already have some of that in place for J2 online. Maybe not
enough yet for the purpose at hand here, but its a start.
I'd surely like to provide more concrete descriptions where needed for J2
but that can take a lot of time none of us has plenty of.
Having a clear target (.e.g. a good problem description) might make that a
much easier task...
>
> 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.
Well, there have been several slightly different proposals on this now,
most of which I would support including a portals-apps.
As always, the devil will be in the details, and we haven't gotten that far yet.
Also, Cocoon Portal, Ralf and Carsten, are not (yet) fully in agreement on this
either. But I think we're going to have a separate discussion about that on the
Jetspeed dev list in the new year.
>
> 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.
I think we are getting much closer now ;-)
>
>> <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.
My time to apologize. I agree this hasn't been said explicitly, but the
repeated proposals for a solution outside J2 did make me see it that way.
>
> 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.
Well, to be honest, I still don't think those are a fair set of arguments
and I've not much interest in responding to them as such...
I'm open to starting afresh though in a new thread. I think we should finish
this thread soon now too so we can leave our "misunderstandings" behind.
>
>> <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.
Clearly, I see J2 as a perfect fit for that purpose too ;-)
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
>>Yes, agreed - there are several issues here discussed at once. I'll
>>comment on some of them :)
>>Cocoon Portal is currently part of Cocoon (obviously :) ). Now, it
>>really lacks of committers and visibility. Noone knows that Cocoon has a
>>nice portal solution. Ralph and myself are nearly the only developers on
>>the portal. Now what do you guys think of moving the Cocoon portal to
>>the portals project to create more visibility and hopefully to make
>>collaboration between the various portals projects more efficient?
>>
>>
>
> Carsten and I disagree on whether this is a good idea. The cocoon portal
> relies on Cocoon constructs and at this point it cannot be used without
> the Cocoon framework. So it feels a little wierd to me to move it to
> the portals project. However, it is just another Cocoon block and so it
> can move to any part of the svn repository. But I'm not sure that
> simply moving it to Portals will attract new committers to it.
>
The marketing would be different - it would not just be "another of the
hundreds of blocks of Cocoon", but a portal solution "based on Cocoon".
In the end, everything is marketing...
> Wow. It is rare that Carsten and I disagree on something.
>
:) (It really might be the time zone, I'm 9 hours ahead of you :) )
> Carsten is absolutely right that this idea scares me. While some parts
> of the Cocoon portal should and could be the same as Jetspeed, I simply
> don't see how it could replace Cocoon's portal. Cocoon as a whole uses
> pipelines and source resolvers to leverage XML and XSLT. The Cocoon
> portal does the same thing but at the portlet level. Furthermore, the
> Portal allows Cocoon pipelines to be used as portlets and it uses
> pipelines to obtain all of its configuration. Now, if the J2 portal can
> be used and Cocoon just plugs in to the appropriate places to accomplish
> the same thing then that would be fine. But I'm not sure that that is
> possible which is why I'm suggesting looking for common components instead.
>
This is exactly what I want to find out when looking at J2. In Cocoon we
have the coplet adapter abstraction. It's the interface between the
portal and the portlets. For each portlet type (JSR 168, WSRP, Cocoon
Pipeline) we use a different adapter - it's a simple interface, similar
to the portlet interface but providing sax based xml support instead of
writing to an output stream. Now, if j2 would provide this pluggability,
I think we have everything we need. Raphael told me at ApacheCon Europe
that j2 also has some pipelining mechanism, so it actually sounds not so
hard. For the configuration part, I guess that can be pluggable as well.
So it seems possible, the remaining question will be if it makes sense.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Synergy In Portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>Yes, agreed - there are several issues here discussed at once. I'll
>comment on some of them :)
>Cocoon Portal is currently part of Cocoon (obviously :) ). Now, it
>really lacks of committers and visibility. Noone knows that Cocoon has a
>nice portal solution. Ralph and myself are nearly the only developers on
>the portal. Now what do you guys think of moving the Cocoon portal to
>the portals project to create more visibility and hopefully to make
>collaboration between the various portals projects more efficient?
>
>
Carsten and I disagree on whether this is a good idea. The cocoon portal
relies on Cocoon constructs and at this point it cannot be used without
the Cocoon framework. So it feels a little wierd to me to move it to
the portals project. However, it is just another Cocoon block and so it
can move to any part of the svn repository. But I'm not sure that
simply moving it to Portals will attract new committers to it.
>Now, although I wrote more than 90% of the Cocoon portal code (and this
>fact shows the community problem of the portal), I don't care what
>happens with it over the long term. I think, in the end we should try to
>have only one portal solution at Apache - being this Jetspeed 2, Cocoon
>or something different is imho not that important. Now, I don't know J2
>that much, but from what I understand so far, it seems similar to the
>Cocoon solution in most areas, so I might be possible to add some things
>from the Cocoon portal to J2 and then ditch the Cocoon code (I guess
>this now scares Ralph :) ) - But I see this more as a long term goal
>which we can start addressing when I know more about J2 - I'm, planning
>to look into J2 in the next weeks and then see, if it's possible to add
>some ideas from Cocoon there. I'll start a thread at the J2 list by then.
>
>
Wow. It is rare that Carsten and I disagree on something.
Carsten is absolutely right that this idea scares me. While some parts
of the Cocoon portal should and could be the same as Jetspeed, I simply
don't see how it could replace Cocoon's portal. Cocoon as a whole uses
pipelines and source resolvers to leverage XML and XSLT. The Cocoon
portal does the same thing but at the portlet level. Furthermore, the
Portal allows Cocoon pipelines to be used as portlets and it uses
pipelines to obtain all of its configuration. Now, if the J2 portal can
be used and Cocoon just plugs in to the appropriate places to accomplish
the same thing then that would be fine. But I'm not sure that that is
possible which is why I'm suggesting looking for common components instead.
Ralph
Re: Synergy In Portals
Posted by Carsten Ziegeler <cz...@apache.org>.
Sorry for stepping this late, but my laptop broke down on the last day
of the ApacheCon and as I packed it into my luggage, the luggage had
some extra security treatment on the flight back, so I received the
laptop last night, then had to repair the hard drive and now everything
seems to work again...(ok, this is totally ot, but I thought starting
with a little story makes everything more interesting). Back to the topic:
>
> Maybe part of the problem with this thread is that several issues
> are at play here.
> - a proposal for a new light-weight portal
> - a proposal for a separate portals-commons
> - a proposal for maybe even a "Portals Suite" whatever that might be
> - Cocoon Portal not being part of Apache Portals
>
Yes, agreed - there are several issues here discussed at once. I'll
comment on some of them :)
Cocoon Portal is currently part of Cocoon (obviously :) ). Now, it
really lacks of committers and visibility. Noone knows that Cocoon has a
nice portal solution. Ralph and myself are nearly the only developers on
the portal. Now what do you guys think of moving the Cocoon portal to
the portals project to create more visibility and hopefully to make
collaboration between the various portals projects more efficient?
Now, although I wrote more than 90% of the Cocoon portal code (and this
fact shows the community problem of the portal), I don't care what
happens with it over the long term. I think, in the end we should try to
have only one portal solution at Apache - being this Jetspeed 2, Cocoon
or something different is imho not that important. Now, I don't know J2
that much, but from what I understand so far, it seems similar to the
Cocoon solution in most areas, so I might be possible to add some things
from the Cocoon portal to J2 and then ditch the Cocoon code (I guess
this now scares Ralph :) ) - But I see this more as a long term goal
which we can start addressing when I know more about J2 - I'm, planning
to look into J2 in the next weeks and then see, if it's possible to add
some ideas from Cocoon there. I'll start a thread at the J2 list by then.
> Anyways, I did *not* say the solution *must* be tailored around J2. I only asked
> for looking into that as a possible solution.
> Note: this specifically concerns the issue of a new light-weight portal which I think
> might less of interest to Cocoon (please correct me if I'm wrong here).
Yup - I have not thought about this light-weight portal stuff yet, but
currently I see no need for this for myself; but I'm open to any further
discussions of course.
> But, our Jetspeed components could be made (or maybe already are) reusable for Cocoon or any
> other portal like Gridsphere for instance.
Yepp :)
> I also have no objection to move such components to a separate (sub) project of Portals
> if they are really (going to be) reused and others will help out maintaining them.
Ok.
> <SNIP/>
>
> That is one solution, another one could be a separate J2 build, J2-light or whatever which is
> simply a lighter packaged version of J2 with an appropriate simpler configuration and assembly.
> And yes, maybe a new project could be more appropriate in the end, but I'm not convinced of that yet :-)
>
As long as the components are really separatly usable from J2, I don't
care that much were they are maintained - as long as I have access to it
:) And we can then later on move them to a commons project if appropriate.
> Anyways, for Cocoon, I recognize that separate usage of our J2 components or further generalized
> ones in a new portals-commons project might be very useful.
>
> May I suggest you or Carsten create a new discussion thread here, or on the Jetspeed dev list, in which
> we discusss what J2 features could be of use to Cocoon or we can create together for both our communities?
> I honestly like to help out with that one.
Great, thanks, Ate - yes, I think the best place would be the J2 list
for now; I'll start a thread in the new year.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Synergy In Portals
Posted by Ate Douma <at...@douma.nu>.
Ralph Goers wrote:
> The reason I would prefer a separate project for "portal-commons" is
> simple. I'm not a committer on Jetspeed. For that matter I've never
> even used Jetspeed so it would be completely inappropriate for me to
> be. However, I am somewhat familiar with Pluto and know the Cocoon
> portal pretty well. So for those of us who want common components it
> sounds like what you are proposing is that we should all tailor our
> stuff around the existing Jetspeed components - take it or leave it.
>
> Now this may not be the sentiment you meant to convey.
No, I'm certainly not trying to do that!
Maybe part of the problem with this thread is that several issues
are at play here.
- a proposal for a new light-weight portal
- a proposal for a separate portals-commons
- a proposal for maybe even a "Portals Suite" whatever that might be
- Cocoon Portal not being part of Apache Portals
Anyways, I did *not* say the solution *must* be tailored around J2. I only asked
for looking into that as a possible solution.
Note: this specifically concerns the issue of a new light-weight portal which I think
might less of interest to Cocoon (please correct me if I'm wrong here).
But, our Jetspeed components could be made (or maybe already are) reusable for Cocoon or any
other portal like Gridsphere for instance.
I also have no objection to move such components to a separate (sub) project of Portals
if they are really (going to be) reused and others will help out maintaining them.
In my view though, the set of components which can be made reusable as such, in itself
won't be enough to create a new light-weight portal upon. That requires many specific
choices like how to handle persistence or caching which cannot (and probably should not
tried to) be handled in a generic way. If it would, J2 would indeed need no more than
these components and some kind of assembly to make it what it is.
Its not *that* simple though ;-)
>
> As for the light-weight portal, for me it simply a matter of looking at
> the use cases. At the moment the only ones I am aware of are the
> Geronimo Admin Console and Pluto's container.
We have been discussing this with the Geronimo team a lot during ApacheCon. As far as I
now know it, they aren't really interested in a light-weight portal. They actually want J2.
I've been working with them looking at the few integration issues we have (like security) and will work
with them the next few weeks to see them solved.
The Pluto "Driver" Portal is a different issue.
Because of its charter, it is and should remain limited in scope.
Maybe there is a use-case for a separate light-weight portal, somewhere between Pluto and J2.
DDW thinks there is and Raphael seems to agree.
I'm not so sure though: compared with others like Liferay and Exo J2 is still lacking much in features
I think it would be smarter to concentrate on our real competition instead of .
But, I'm open for discussion.
> My concern with packaging
> the light-weight portal in Jetspeed is that it might get lost in the
> midst of all the stuff about its big brother, but I see no reason that a
> maven based build of a light-weight portal couldn't have dependencies on
> Jetspeed and/or common components.
That is one solution, another one could be a separate J2 build, J2-light or whatever which is
simply a lighter packaged version of J2 with an appropriate simpler configuration and assembly.
And yes, maybe a new project could be more appropriate in the end, but I'm not convinced of that yet :-)
Anyways, for Cocoon, I recognize that separate usage of our J2 components or further generalized
ones in a new portals-commons project might be very useful.
May I suggest you or Carsten create a new discussion thread here, or on the Jetspeed dev list, in which
we discusss what J2 features could be of use to Cocoon or we can create together for both our communities?
I honestly like to help out with that one.
Regards, Ate
> Ralph
>
Re: Synergy In Portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
David Sean Taylor wrote:
>
> Regarding your concern about NOT being a Jetspeed committer, I don't
> see that as a problem. If you join any of the Portals projects, you
> get commit access to ALL Portals repos. So if, for example, Cocoon
> portal was moved into the Portals project, then you would have commit
> access to Pluto, Jetspeed, Bridges...
Wow. I didn't know that. Carsten was supposed to give me access but I
guess he's been a little busy. I thought Jetspeed was separate.
Ralph
Re: Synergy In Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ralph Goers wrote:
> The reason I would prefer a separate project for "portal-commons" is
> simple. I'm not a committer on Jetspeed. For that matter I've never
> even used Jetspeed so it would be completely inappropriate for me to
> be. However, I am somewhat familiar with Pluto and know the Cocoon
> portal pretty well. So for those of us who want common components it
> sounds like what you are proposing is that we should all tailor our
> stuff around the existing Jetspeed components - take it or leave it.
>
> Now this may not be the sentiment you meant to convey.
>
> As for the light-weight portal, for me it simply a matter of looking at
> the use cases. At the moment the only ones I am aware of are the
> Geronimo Admin Console and Pluto's container. My concern with packaging
> the light-weight portal in Jetspeed is that it might get lost in the
> midst of all the stuff about its big brother, but I see no reason that a
> maven based build of a light-weight portal couldn't have dependencies on
> Jetspeed and/or common components.
> Ralph
>
Regarding your concern about NOT being a Jetspeed committer, I don't see
that as a problem. If you join any of the Portals projects, you get
commit access to ALL Portals repos. So if, for example, Cocoon portal
was moved into the Portals project, then you would have commit access to
Pluto, Jetspeed, Bridges...
Re: Synergy In Portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
The reason I would prefer a separate project for "portal-commons" is
simple. I'm not a committer on Jetspeed. For that matter I've never
even used Jetspeed so it would be completely inappropriate for me to
be. However, I am somewhat familiar with Pluto and know the Cocoon
portal pretty well. So for those of us who want common components it
sounds like what you are proposing is that we should all tailor our
stuff around the existing Jetspeed components - take it or leave it.
Now this may not be the sentiment you meant to convey.
As for the light-weight portal, for me it simply a matter of looking at
the use cases. At the moment the only ones I am aware of are the
Geronimo Admin Console and Pluto's container. My concern with packaging
the light-weight portal in Jetspeed is that it might get lost in the
midst of all the stuff about its big brother, but I see no reason that a
maven based build of a light-weight portal couldn't have dependencies on
Jetspeed and/or common components.
Ralph
Ate Douma wrote:
> 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.
>
> I've said so before, and I'll repeat it again to make it undeniable
> clear: I am *not* opposed to a
> separate project/repository *if* that turns out to be the best
> solution for all of the Portals community.
>
> 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?
>
> Ate
>
>
>
Re: Synergy In Portals
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta wrote:
> David H. DeWolf wrote:
>>> Ate Douma wrote:
>>>>> David H. DeWolf wrote:
>>>>>>> On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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.
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.
David DeWolf and anyone else *of course* is free to say or ask whatever he/she wants.
That *should* go without saying and I find it really astounding it being questioned here.
I never, ever, tried to prevent it nor tried to discourage it.
Don't try to make me sound as if I would want to have it any other way...
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.
Saying I'm defensive up to the point I don't allow non-J2 people the right to make up their mind
is really turning the world upside down here.
I'm holding back here...
>
> 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.
Yes.
Then why this *repeated* push for a separate project/repository upfront?
Every proposal from DDW or you comes back to that.
> 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.
I've said so before, and I'll repeat it again to make it undeniable clear: I am *not* opposed to a
separate project/repository *if* that turns out to be the best solution for all of the Portals community.
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?
Ate
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
David H. DeWolf wrote:
>>
>> Ate Douma wrote:
>
>>>> David H. DeWolf wrote:
>>
>>>>>> On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
Ate Douma wrote:
> David H. DeWolf wrote:
>
>> On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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/)
>>>
>>
>>
>>
>
>
>
>
Re: Synergy In Portals
Posted by Ate Douma <at...@douma.nu>.
David H. DeWolf wrote:
> On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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?
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.
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.
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.
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.
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.
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?
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.
And thus, I fully support David Sean Taylor's proposal and not divide our community up front.
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 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.
> 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.
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/)
>>
>
>
>
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
On 12/17/05, David Sean Taylor <da...@bluesunrise.com> 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.
>
> 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. 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 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?
>
> > 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/)
>
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
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 - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël 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'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.
> 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/)
Re: Synergy In Portals
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ralph Goers wrote:
> I agree with most of your post but I would add one more use case for the
> Cocoon Portal.
> - Web sites which have a desire to incorporate portlets of various types
> (JSR-168, WSRP, bridges, cocoon pipelines, etc) without looking like or
> behaving like a portal.
>
> As for what I am most interested in, all the portals will share some
> commonality in that they all need to deploy portlets, they all require
> security, they all want to provide personalization features, etc.
> Ideally, many of these features could be extracted into a set of
> frameworks that all the various portals could leverage. However, I
> would expect that when integrated into Jetspeed the variety of choices
> or set of features would be more extensive than with some of the other
> portals.
>
> I'm not really as interested in creating a "light portal" as I am in
> sharing as much between the projects as possible. However, at
> ApacheCon, the Geronimo team spoke about incorporating Pluto as its
> admin console and perhaps into Geronimo itself. If this is done I think
> it would make sense that if a Geronimo customer decided to use Jetspeed
> instead that they would just get an enhanced portal - ideally, all of
> Geronimo's documented procedures would still work.
>
> Likewise, in Cocoon we would prefer to leverage a common code base than
> go "borrowing" from other projects.
>
> So what I would like to see is a "portal common" project rather than a
> "portal light" project.
This sounds great. It would be great if we could share common
components. I'd like to help Cocoon in this process.
Jetspeed-2 provides a set of components that you can use in your portal
such as a registry component, aggregator component, and page manager
component for example.
These components are downloadable in the 2.0 release at Apache's maven
site under the org.apache.portals.jetspeed-2 group. You can download
them as is, although there are other support component dependencies that
will get drawn in.
As for a "portal common" project, could be interesting, although it may
already exist...
The Jetspeed-2 components already serves this purpose. The components
are ready to use as is. If it helps to build collaboration on these
components, we could consider factoring out, from a project POV, into a
"Jetspeed Components" project that builds alone, without the portal,
although its not really clear what that leaves to the portal, since the
entire Jetspeed portal is built of components. So I guess this idea of
"commons" is somewhat redundant to us, since we already consider
Jetspeed-2 to be the portal component architecture at Apache Portals. I
just want to be careful that we don't factor everything out of Jetspeed
and leave it with nothing.
Re: Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
Ralph Goers wrote:
> I agree with most of your post but I would add one more use case for the
> Cocoon Portal.
> - Web sites which have a desire to incorporate portlets of various types
> (JSR-168, WSRP, bridges, cocoon pipelines, etc) without looking like or
> behaving like a portal.
>
> As for what I am most interested in, all the portals will share some
> commonality in that they all need to deploy portlets, they all require
> security, they all want to provide personalization features, etc.
> Ideally, many of these features could be extracted into a set of
> frameworks that all the various portals could leverage. However, I
> would expect that when integrated into Jetspeed the variety of choices
> or set of features would be more extensive than with some of the other
> portals.
>
> I'm not really as interested in creating a "light portal" as I am in
> sharing as much between the projects as possible. However, at
> ApacheCon, the Geronimo team spoke about incorporating Pluto as its
> admin console and perhaps into Geronimo itself. If this is done I think
> it would make sense that if a Geronimo customer decided to use Jetspeed
> instead that they would just get an enhanced portal - ideally, all of
> Geronimo's documented procedures would still work.
>
> Likewise, in Cocoon we would prefer to leverage a common code base than
> go "borrowing" from other projects.
>
> So what I would like to see is a "portal common" project rather than a
> "portal light" project.
It sounds like that's what most people are thinking, so maybe that's
what we should focus on - common components/services. I guess I'm in
the minority of people who need this type of portal.
David
>
> Ralph
>
> Raphaël Luta wrote:
>
>>
>>
>> Cocoon Portal (not really Portals project but closely related)
>> -------------
>> Mission:
>> Provide a full-featured, reliable entreprise portal
>>
>> Main Use Cases:
>> - Corporate intranet portals
>> - Internet portals
>>
>>
>>
>>
>
Re: Synergy In Portals
Posted by Ralph Goers <Ra...@dslextreme.com>.
I agree with most of your post but I would add one more use case for the
Cocoon Portal.
- Web sites which have a desire to incorporate portlets of various types
(JSR-168, WSRP, bridges, cocoon pipelines, etc) without looking like or
behaving like a portal.
As for what I am most interested in, all the portals will share some
commonality in that they all need to deploy portlets, they all require
security, they all want to provide personalization features, etc.
Ideally, many of these features could be extracted into a set of
frameworks that all the various portals could leverage. However, I
would expect that when integrated into Jetspeed the variety of choices
or set of features would be more extensive than with some of the other
portals.
I'm not really as interested in creating a "light portal" as I am in
sharing as much between the projects as possible. However, at
ApacheCon, the Geronimo team spoke about incorporating Pluto as its
admin console and perhaps into Geronimo itself. If this is done I think
it would make sense that if a Geronimo customer decided to use Jetspeed
instead that they would just get an enhanced portal - ideally, all of
Geronimo's documented procedures would still work.
Likewise, in Cocoon we would prefer to leverage a common code base than
go "borrowing" from other projects.
So what I would like to see is a "portal common" project rather than a
"portal light" project.
Ralph
Raphaël Luta wrote:
>
>
>Cocoon Portal (not really Portals project but closely related)
>-------------
>Mission:
> Provide a full-featured, reliable entreprise portal
>
>Main Use Cases:
> - Corporate intranet portals
> - Internet portals
>
>
>
>
Re: Synergy In Portals
Posted by Raphaël Luta <ra...@apache.org>.
[Warning: *long* email...]
David H. DeWolf wrote:
> <snip>
>
> I'd like to open the discussion of a new portals project. This
> project would be a very lightweight portal implementation which
> provides more than the testbed which pluto provides (in fact, pluto
> would probably be greatly trimmed down or refactored out into this
> project) but no more than the core aggregation services (portlet
> registry, page management, deployment). The hope would be for portals
> such as jetspeed and cocoon to build on top of these core services.
> Additionally, this lightweight portal could be used for developing
> portlets, testing portlets, embedding within web applications which
> need to aggregate content, etc. . .
>
> Another idea we discussed was placing some of these facilities into a
> portal-commons project.
>
> Thoughts?
>
Interesting question, you're actually touching two different subjects here:
- organisation of Apache portals and goals of the various subprojects and
the possible need to restructure the project (portal commons, portal
applications, portal light...)
- core/target features of the different subprojects, mainly Pluto and Jetspeed
To address point one, we need to a have a common vision of the current org
and mission of the different subprojects.
To address point two, we need to take into account the wishes of the
different communities and the technical merits of the current solutions.
To help with point one, I'll provide my personal definitions/vision of the
different Portals efforts..
First, the mandate of Apache Portals: promote portal related technologies
in general and more specifically anything related to JSR-168.
Pluto
-----
Mission:
Provide the RI for a JSR-168 compliant container
Main Use Cases:
- Provide JSR-168 capabilities to an existing system
(container embedding)
- Provide a convenient testbed for JSR-168 portlet developpers
WSRP-4J (is that part of Portals or WS in the end ?)
-------
Mission:
Provide a "reference" WSRP Consumer and Producer implementation
Main use cases:
- Provide WSRP capabilities to an existing portal system
(container embedding)
- Provide a testbed for WSRP interactions
Jetspeed
--------
Mission:
Provide a full-featured, reliable entreprise portal
Main Use Cases:
- Base portal for an ISV product
- Corporate intranet portals
Cocoon Portal (not really Portals project but closely related)
-------------
Mission:
Provide a full-featured, reliable entreprise portal
Main Use Cases:
- Corporate intranet portals
- Internet portals
Bridges
-------
Mission:
Provide development tools and middleware to transform web
applications as portal applications.
Main use cases:
- Port existing web applications as portal applications
- Develop new portal applications with existing well-known
web development framework
Graffito
--------
Mission:
Provide a portal oriented content management system
Main use cases:
- Portal content publishing engine
- Corporate document management
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.
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.
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).
If we can agree on the best technological basis for the portal "light", we
can bootstrap this effort with whatever codebase is selected and have any
of the current committers maintain it in a separate repository.
(as a reminder, all portals committers have access to the complete portals
repository, so it's perfectly possible to reorganise the repository to create
a shared component system without a dedicated community support infra (like
ML, websites, etc...)
OK, enough for now...
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: Synergy In Portals
Posted by CD...@hannaford.com.
Hi David,
While Pluto was started as (and continues to be) the Reference
Implementation of a JSR-168 container, its users have primarily been
developers who want to learn the Portlet API and make sure that their
custom portlets conform to it. Therefore, a usable Pluto portal has always
been first in users mind and the reason why I created an Ant build for
deploying portlets and later the admin portlets. Therefore, I still
believe that portlet deployment features (contained in the admin portlets,
maven and Ant builds) should remain part of Pluto. They include:
1. Deployment, redeployment and undeployment functions.
2. Portlet application layout modification functions.
All other advanced functions are the purview of an enterprise portal.
I believe that by being affiliated with JSR-168 (and soon JSR-286), Pluto
will always be the entry point and verification point for portlet
developers, so we need to facilitate that role. That will benefit Cocoon,
Jetspeed and other enterprise portals as developers 'graduate' from their
Pluto apprenticeship.
I also believe the Portals-Bridges needs to be reorganized. I suggest
something like:
1. Portals-Commons containing the Common Utilities and Interfaces, Portlet
Filter and Frameworks subproject now in Portals-Bridges. David Sean Taylor
has also suggested this. I believe there is a need for a native
JSR-168-based development framework (like Struts, JSF or Tapestry) and
this project is the place for that. This project should also contain
common portal code as has been suggested by others.
2. Portals-Bridges for the JSF, Struts, PHP, Velocity, and Perl Bridges.
3. Portals-Applications to hold JSR-168 compliant portlet applications as
David Sean Taylor has suggested. Since not every open source and
commercial portlet app will be in this project, I would also like to see
some sort of portlet application wiki page or matrix be part of this
project that would point to other JSR-168 compliant portlets available on
the web.
Perhaps Portals-Commons should contain Portals-Bridges and
Portals-Applications as subprojects, but that is open to debate.
/Craig
----------------------------------------------------
Craig Doremus
Pluto Committer
----------------------------------------------------
"David H. DeWolf" <dd...@apache.org>
Sent by: ddewolf@gmail.com
12/13/2005 12:26 PM
Please respond to
"Portals Discussion" <ge...@portals.apache.org>
To
general@portals.apache.org
cc
Subject
Synergy In Portals
oops, the general list didn't recognize my gmail account the first
go-around.
---------- Forwarded message ----------
From: David H. DeWolf <dd...@apache.org>
Date: Dec 13, 2005 12:29 AM
Subject: Synergy In Portals
To: general@portals.apache.org
Cc: pluto-dev@portals.apache.org, Jetspeed Developers List
<je...@portals.apache.org>
*********************************
I am copying this email to multiple lists to make sure that all
portals projects are aware of the discussion. Please *only reply* to
the general@portals.apache.org address to reduce traffic.
*********************************
We had some great discussions tonight at ApacheCon concerning gaining
momentum and synergy between the portals (and related) projects.
Specifically, we addressed the need to determine where the line is
between pluto and enterprise portal implementations (specifically,
jetspeed and cocoon) .
There seems to be a need for a "lightweight" portal implementation
which provides standard aggregation services, but does not include all
of the bells and whistles (value added services such as cms, sso, etc.
. .). Pluto has been moving towards this point, but it isn't
necessarily the place for this (the portlet container should be the
primary need). Additionally, other common functions (i.e. autodeploy
- which both jetspeed and cocoon have implemented) may be beyond the
scope of pluto, but do not have a common home - thus duplicating work.
I'd like to open the discussion of a new portals project. This
project would be a very lightweight portal implementation which
provides more than the testbed which pluto provides (in fact, pluto
would probably be greatly trimmed down or refactored out into this
project) but no more than the core aggregation services (portlet
registry, page management, deployment). The hope would be for portals
such as jetspeed and cocoon to build on top of these core services.
Additionally, this lightweight portal could be used for developing
portlets, testing portlets, embedding within web applications which
need to aggregate content, etc. . .
Another idea we discussed was placing some of these facilities into a
portal-commons project.
Thoughts?
I'm looking forward to hearing suggestions on how we can address these
concerns and start working more closely together across portals
projects. . .
David
Synergy In Portals
Posted by "David H. DeWolf" <dd...@apache.org>.
oops, the general list didn't recognize my gmail account the first go-around.
---------- Forwarded message ----------
From: David H. DeWolf <dd...@apache.org>
Date: Dec 13, 2005 12:29 AM
Subject: Synergy In Portals
To: general@portals.apache.org
Cc: pluto-dev@portals.apache.org, Jetspeed Developers List
<je...@portals.apache.org>
*********************************
I am copying this email to multiple lists to make sure that all
portals projects are aware of the discussion. Please *only reply* to
the general@portals.apache.org address to reduce traffic.
*********************************
We had some great discussions tonight at ApacheCon concerning gaining
momentum and synergy between the portals (and related) projects.
Specifically, we addressed the need to determine where the line is
between pluto and enterprise portal implementations (specifically,
jetspeed and cocoon) .
There seems to be a need for a "lightweight" portal implementation
which provides standard aggregation services, but does not include all
of the bells and whistles (value added services such as cms, sso, etc.
. .). Pluto has been moving towards this point, but it isn't
necessarily the place for this (the portlet container should be the
primary need). Additionally, other common functions (i.e. autodeploy
- which both jetspeed and cocoon have implemented) may be beyond the
scope of pluto, but do not have a common home - thus duplicating work.
I'd like to open the discussion of a new portals project. This
project would be a very lightweight portal implementation which
provides more than the testbed which pluto provides (in fact, pluto
would probably be greatly trimmed down or refactored out into this
project) but no more than the core aggregation services (portlet
registry, page management, deployment). The hope would be for portals
such as jetspeed and cocoon to build on top of these core services.
Additionally, this lightweight portal could be used for developing
portlets, testing portlets, embedding within web applications which
need to aggregate content, etc. . .
Another idea we discussed was placing some of these facilities into a
portal-commons project.
Thoughts?
I'm looking forward to hearing suggestions on how we can address these
concerns and start working more closely together across portals
projects. . .
David