Ate Douma wrote:
David H. DeWolf wrote:
On 12/17/05, David Sean Taylor <[EMAIL PROTECTED]> wrote:
Raphaël Luta wrote:
I'm not familiar enough with the current feature level of Pluto
portal driver
to have a definite idea but the best technical foundation.
I know Jetspeed spreing based architecture and pipeline processing
is supposed
to allow us to scale it down easily, but until somebody actually
tries it's
more a theoretical possibility than a reality.
That is exactly what we are proposing to do.
We believe it is possible. Give us a chance to prove it first before
diving into something completely new, which might end up conflicting
with and competing with the existing Jetspeed project and community.
I find this statement a little misleading. No one is suggesting we
start something completely new. In fact, what I've continually said
is that we need to take a look at what allready exists (between
jetspeed, cocoon, and pluto) and refactor it into a basic portal which
is distributed and developed seperately.
Now, I really can't agree with the usage of the term "misleading" here.
Didn't you start this discussion asking for a new portals project?
Ok, fair enough. Perhaps misleading was a bad choice of words. I
appologize if it was offensive. Maybe misinformed is a better choise.
While I'm suggesting that we consider a new project, I've also said
several times that I think it can be based off of code that allready
exists. To me, that is totally different than "completely new".
Completely new implies brand new code.
For me, to qualify something as a new Apache (Portals) project, it
should be something which isn't yet
provided for, or existing projects and their community can not or will
not provide.
Well, I think that 3 different project allready provide what I'm
suggesting. So perhaps I'm off base in proposing a new project. Maybe
consolidation is a better approach????
My thought was that it would be great to combine what overlaps in
those 3 projects into a single one which the other 3 can leverage. I
guess to me, the new aspect that warrents a new project is the
cooperation between the 3 projects.
Up until now, I haven't heard any valid reason why the Jetspeed project
and its community would be
unable or not fit to provide a light-weight/base portal solution.
1) Currently no light weight implementation exists. The codebase is
rather complex and goes way beyond the requirements of a simple embedded
aggregation server.
2) Some parts of jetspeed overlap with components needed in pluto and
cocoon. IMHO We should find a way to develop these as a team and not in
isolation of each other.
3) Jetspeed does not currently support users that are brand new to
portals and want to start learning, testing, developing portlets. I'd
like to see something that a brand new portlet developer can get up and
running in (literally) 3 mintues.
4) The jetspeed codebase and build are very complex. In fact, I heard
many complaints about the build system at ApacheCon. One of the ways I
like to simplify things is to break things into core and value added
services. By breaking out the the core components of jetspeed into a
seperate project upon which jetspeed builds upon, developers will be
able to more clearly see the line between core components of the portal
and value added services, and jetspeed as a whole will become easier to
maintain.
5) Because this solution which we are discussing should support
jetspeed, cocoon, and pluto, creating a new project from the best
components of each of the projects will help encourage a community
atmosphere where developers aren't defensive about ownership, design,
etc. . .By picking a single project and using it, I'm affraid only that
projects needs will be met.
On the contrary, David, myself, and at least all the other Jetspeed team
members which were at ApacheCon,
are very open to discuss such a solution and see how (not "if") we can
provide it from within our
project and community.
I guess that's my point. I don't understand why the default answer is
from "within jetspeed". I think we should make an objective descision
based on what's best for the community, cocoon, pluto, and jetspeed.
It's VERY possible that the answer to this descision is that the
solution is housed within jetpeed, however, I think that all solutions
should be considered.
Why has the jetspeed team has taken this suggestion as a challenge?
The comments all seem to be defensive and suggesting that jetspeed is
the only viable solution. I'd like to hear REAL REASONS as to why this
simple portal solution should be provided within jetspeed just as you'd
like to hear reasons for placing it elsewhere.
I appologize if that's a controversial statement.
We acknowledge that there is a usage for a light-weight portal. If there
are area's within Jetspeed
which needs to be improved (maybe trimmed down) in a way currently
provided for in the Pluto Portal Driver
or Cocoon Portal, then we can and will adapt that solution for Jetspeed
too.
Again, why does this have to be the approach? Reasons?
Jetspeed 2 is all about pluggable components so I don't think that will
be much of a problem.
Also note: this "problem" hasn't been discussed *ever* before with the
Jetspeed team.
It certainly would be unfair to say upfront Jetspeed won't be able or is
unfit to provide an good solution.
No one is accusing jetspeed of anything. Why the defensive attitude?
I'm suggestion synergy and cooperation, I'm NOT suggesting that jetspeed
has done anything wrong.
Right now, I really don't see a valid reason to create a new project
just to be able to distinguish from Jetspeed
and/or the Pluto Portal Driver or Cocoon Portal.
Why, with what purpose?
See above. . .
A new, independent "basic" portal project within Portals, *will* compete
with Jetspeed and its community.
We certainly aren't the biggest project within Apache to say the least.
As such, I'd suggest we look at finding a solution within Jetspeed first
we all can support and work on.
Hmmm. I didn't realize competition was such a contoversial subject. I
was thinking that by working together we could make more headway, I
didn't see this as such a you vs. me thing.
And thus, I fully support David Sean Taylor's proposal and not divide
our community up front.
Fair enough. If that's the opinion, I'm all for it. I just wanted to
see if there was a way we could find common ground and start working
together. I will move forward in giving jetspeed a fair shake and will
drop my suggestion of a common "base" portal. Apparently I'm one of the
only people that thinks it's a valid approach.
Regards, Ate
(note: I've added a few comments more below)
We have a 2.01 release to put out next week. We will then start work on
a lightweight assembly of Jetspeed-2. Additionally, we will start
writing light-weight implementations of most of the database components.
We are a small team at Apache Portals. It is essential that we all work
together towards the same vision. This is what Apache is all about.
+100 - but we need to find the same vision. It's fairly apparent that
we're not on the same page yet.
Well, which and whose page we're talking about isn't really clear, is it?
I REALLY don't get why this is such a controversial proposal. It's not
about me vs. you, it's about trying to create synergy. Why are you
trying to pit this as you vs. me?
I think the first step is diving into
the work that has been done in each project and begining to analyze
what we have.
I'm confused.
Can you describe *what* this basic portal should contain/provide for?
Shouldn't we have a clear vision of its purpose before shopping around for
possible features to attach to it? Otherwise it might end up not so
"lightweight"
any more after all.
Yes, we should. I've stated a couple of times that my vision is:
1) Portlet Registry
2) Aggregation
3) Page Management
4) Simple installation and deployment
NO VALUE ADDED SERVICES (sso, etc. . .)
> I have begun to look into jetspeed in more depth (and
hopefully will have time in the near future to look into cocoon as
well). Has anyone else had a chance to look at the changes that have
occured in pluto? What are your thoughts?
No, sorry.
Getting Bridges 1.0 and Jetspeed 2.0 released just a week ago was a
enormous effort
the whole Jetspeed team invested all their available spare *and*
business time in.
trust me, I understand. I just don't see how the jetspeed team can rule
out other options before even looking at them.
I personally intend to review it as soon as I'm back in the Netherlands
(next week) though.
In the end, I think the critical issue will be community: Pluto
currently has
a real stake in providing a light portal since it's required for it
to deliver
its second main use case (portlet development testbed) whereas
Jetspeed has
less an incentive to do it (the community rather tends to add
feature than
keeping it small and simple).
We are adding new features all the time, true, however, features are
added within the context of pluggable component solutions.
One of the most distinguishing features of Jetspeed is the component
model with ISVs in mind. It is the basis of the Jetspeed philosophy to
be able to assemble and plug-in components to specific target, be it a
heavy-weight full featured enterprise portal or a light-weight embedded
portal.
Examples of embedding and specialized solutions:
* Jetspeed-2 running embedded inside Jetspeed 1.6
* Jetspeed-2 running embedded inside Jahia Portal
* Jetspeed-2 running on top of JBoss dedicated for a specific purpose
(http://wfmopen.sourceforge.net/)
