Many of the tags (basically those that have been implemented in struts-el) are closely bound to Struts so I don't see that they belong anywhere else. (Separate jar, yes. Separate cvs dir, probably). The remaining tags have a limited shelf life, having been superseded by JSTL.
I'd also like to see a separate cvs & distribution of optional packages. While I'd probably be in favour of Struts becoming a top level project, I must confess I don't quite understand the criteria for becoming one. Having Jakarta, XML, DB makes sense to me, but I don't get why Ant and Maven warrant top level projects (build tools?) or Cocoon (surely that fits in Jakarta?). If anyone has a clue, please let me know! Having said that, if it's a question of visibility, Struts certainly deserves to be recognized as a top level project and it would give us an opportunity to reorganize the code base and get more people and related projects on board. Steve p.s. Jakarta Faces (or would it be Struts Faces?) would be an interesting subproject for a top level Struts. Then we'd be covering the V and the C. > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: September 27, 2003 10:20 AM > To: Struts Developers List > Subject: Re: Extending Standard Tags was Editable Fields V/S Static Text > > > Vic Cekvenich wrote: > > (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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]