Ralph Goers wrote:
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.
No, I'm certainly not trying to do that!
Maybe part of the problem with this thread is that several issues
are at play here.
- a proposal for a new light-weight portal
- a proposal for a separate portals-commons
- a proposal for maybe even a "Portals Suite" whatever that might be
- Cocoon Portal not being part of Apache Portals
Anyways, I did *not* say the solution *must* be tailored around J2. I only asked
for looking into that as a possible solution.
Note: this specifically concerns the issue of a new light-weight portal which I
think
might less of interest to Cocoon (please correct me if I'm wrong here).
But, our Jetspeed components could be made (or maybe already are) reusable for
Cocoon or any
other portal like Gridsphere for instance.
I also have no objection to move such components to a separate (sub) project of
Portals
if they are really (going to be) reused and others will help out maintaining
them.
In my view though, the set of components which can be made reusable as such, in
itself
won't be enough to create a new light-weight portal upon. That requires many
specific
choices like how to handle persistence or caching which cannot (and probably
should not
tried to) be handled in a generic way. If it would, J2 would indeed need no
more than
these components and some kind of assembly to make it what it is.
Its not *that* simple though ;-)
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.
We have been discussing this with the Geronimo team a lot during ApacheCon. As
far as I
now know it, they aren't really interested in a light-weight portal. They
actually want J2.
I've been working with them looking at the few integration issues we have (like
security) and will work
with them the next few weeks to see them solved.
The Pluto "Driver" Portal is a different issue.
Because of its charter, it is and should remain limited in scope.
Maybe there is a use-case for a separate light-weight portal, somewhere between
Pluto and J2.
DDW thinks there is and Raphael seems to agree.
I'm not so sure though: compared with others like Liferay and Exo J2 is still
lacking much in features
I think it would be smarter to concentrate on our real competition instead of .
But, I'm open for discussion.
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.
That is one solution, another one could be a separate J2 build, J2-light or
whatever which is
simply a lighter packaged version of J2 with an appropriate simpler
configuration and assembly.
And yes, maybe a new project could be more appropriate in the end, but I'm not
convinced of that yet :-)
Anyways, for Cocoon, I recognize that separate usage of our J2 components or
further generalized
ones in a new portals-commons project might be very useful.
May I suggest you or Carsten create a new discussion thread here, or on the
Jetspeed dev list, in which
we discusss what J2 features could be of use to Cocoon or we can create
together for both our communities?
I honestly like to help out with that one.
Regards, Ate
Ralph
