portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Cleaning up Jetspeed
Date Wed, 01 May 2002 16:34:05 GMT
Comments below...

> -----Original Message-----
> From: raphael.luta@networks.groupvu.com 
> [mailto:raphael.luta@networks.groupvu.com] 
> Sent: Wednesday, May 02, 2001 12:08 PM
> To: Jetspeed Developers List
> Subject: Cleaning up Jetspeed 
> In an effort to clean-up the state of the CVS repository 
> before the next 
> release, I'd propose
> to start a clean-up effort of the tree.
> The main target of the clean-up would be all the non-functional code 
> (like CocoonPortlet) and
> examples or obsolete/unused code (most of the legacy ECS controls or 
> controllers stuff).

+1 - The cleaner the better.

> There are 3 options to deal with these:
> - keep them in CVS, mark them as deprecated and remove them in an 
> ulterior release
> - move all these components in a separate archive/attic directory and 
> let them die in this
>   repository
> - remove them completely from the CVS tree.

+1 for removal, if we are *sure* they are old.  Just their presence will be
enough to confuse the new developer / user to think that it's important.
So, before we forget, or those of us who do know move on, a cleanup would be

> I'd personnally vote to completely remove all non-functional 
> code like 
> the CocoonPortlet
> from the CVS as well as all the legacy components that have a direct 
> "modern" functional replacement.
> I would also recommend moving all the unused components that have not 
> been directly
> superceded by new ones into a contrib directory (current named 
> jakarta-jetspeed/modules)
> If committers can give me their opinions quickly, I can deal 
> with the clean-up this week.
> Additionally, there are a couple of features for which I'm 
> not sure of their real status/use:
> - JCM: is it worth keeping it as is or should write a simple 
>   Torque-based message board replacement ?
> - WAP: is somebody actively looking at WML support to make sure it 
>   doesn't break. If no, should drop WML support ?
> - JSP/VM: Is there any added value to support the two templating
>   engines is a symmetric fashion or should simply write all the 
>   components in one of these, knowing that we can still include 
>   elements from either type if required.
>   If we chose to maintain symmetrically both environments, who's going
>   to make sure they are at parity level featurewise ?

I vote for dropping JSP support for use within Jetspeed, and using just vm
for this.  We still have JSP portlets, but not all the customizers, layouts,
navigations, screens, etc that make up Jetspeed proper.  We just don't need
two ways to make jetspeed internals work - velocity will run anywhere jsp
will.  We do need to keep supporting jsp for portlet development, though (I
guess - I don't use it here).

> Any opinions, comments ?
> -- 
> Raphaƫl Luta - raphael.luta@networks.groupvu.com
> Professional Services Manager
> Vivendi Universal Networks - Paris
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message