> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
