Even though I can't officially vote, here is my unofficial vote. I agree with all of this. I would love to see the tree cleaned up so it is clear what does and does not matter/work. I have no problem with making the internal implementations purely vm based as long as JSP templates are still supported. I suppose that means that there should still be a JSP example or two.
-----Original Message----- From: Glenn Golden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 11:34 AM To: 'Jetspeed Developers List' Subject: RE: Cleaning up Jetspeed Comments below... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > 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 great!. > > 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 - [EMAIL PROTECTED] > Professional Services Manager > Vivendi Universal Networks - Paris > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
