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
