Raphaël Luta wrote:
David H. DeWolf wrote:
Ate Douma wrote:
David H. DeWolf wrote:
On 12/17/05, David Sean Taylor <[EMAIL PROTECTED]> 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
