portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Cleaning up Jetspeed
Date Wed, 01 May 2002 17:20:19 GMT

> -----Original Message-----
> From: raphael.luta@networks.groupvu.com 
> [mailto:raphael.luta@networks.groupvu.com] 
> Sent: Wednesday, May 02, 2001 9:08 AM
> 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.

I've been meaning to do this for a while now. 
There are lots of empty directories. 
>From what I understand, we must delete these directories directly from
Apache's file system. 

> 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).
> 
> There are 3 options to deal with these:
> - keep them in CVS, mark them as deprecated and remove them in an 
> ulterior release
-1

> - move all these components in a separate archive/attic directory and 
> let them die in this
>   repository
-1

> - remove them completely from the CVS tree.
+1

> 
> 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 ?
What is it?

> - WAP: is somebody actively looking at WML support to make sure it 
>   doesn't break. If no, should drop WML support ?

Keep it! It does work and it is used.

> - 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'd like to keep them both, but don't have time to 'assure parity
levels'



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


Mime
View raw message