David Sean Taylor wrote:
>>-----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
+1, as long as we are not talking about a exporting and importing.
Turbine did this and they log the history.
>
>
>>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?
+1 on keeping it, although it needs to work.
>
>
>>- 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.
+1 on keeping it
>
>
>>- 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'
Keep it. We just need to bring it to parity with vm.
>
Paul Spencer
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
