(also IMO Struts HTML and tiles tag could/should migrate to taglibs)
Yes, it would be nice if the taglibs were maintained by Jakarta Taglibs, in the same way that the Struts View Tools are maintained by Velocity. Struts should make it as easy as possible for presentation technologies to hook up to the controller, so that the experts in that technology can provide the appropriate adapters for their platform.
But Apache projects are not dumping grounds. To make it happen, a set of individuals deeply active in both Jakarta Taglibs and Jakarta Struts would have to step up and make the proposal to both communities.
(Personally, I'd also like to see someone with an itch start the ball rolling on a Jakarta Faces product. The Sun distribution is apparently going to be closed source, and the SourceForge MyFaces project is using a restrictive license. Then the Struts-Faces taglib would also have a home among experts in that technology.)
Alternatively, we should talk about setting up a series of "optional" Struts packages. So, rather than have things like Struts-Faces and Struts-el live in the nebulous contrib folder, they could live under org.apache.struts.opt.faces and *.opt.el. Likewise, there could be an *.opt.taglib. And at some point an opt.xls and maybe an opt.wml.
If we followed the "optional" strategy, I'd also suggest we apply for status as a top-level Apache project, so that each of the opt packages could be a proper subproject, with its own CVS, set of Committers, and so forth.
Though, personally, I'd prefer the idea of letting other Jakarta products do what they do best, so that Struts can focus on what it does best: provide the C in MVC.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
