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?
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/)
