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 ;-)
