David Sean Taylor wrote: >> >>
>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. > > You can use the -P (prune) option when updating cvs and it will clean those directories that have no files (except the CVS dir). cvs update -d -P will also create new directories, which cvs does not do by default. Cleaning directories directly in the repository is tricky. I would instead keep the old repository for reference, and re-import into a new one. > > >>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? > > I think some people still use it, though I'm not sure. A vm based message board would be better. > > >>- 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' > > > One of the missing pieces here is having all the velocity tools as taglibs. I would like to have something that would generate automatically taglibs from beans, much like Castor, so that we can update easily the jsp examples using taglibs. While I don't like much jsp, it is used in a lot of places, and it is still the "official" way to develop pages. So at least a way to help users familiar with jsp to understand the jetspeed internals would be great. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
