Some ideas, not neccessarily complete or well-formed... > -----Original Message----- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: April 26, 2004 9:44 PM > To: Struts Developers List > Subject: Re: Adding new Struts features/sub-projects (was > [Bug 28609] - > Scriptable Actions Support) > > What criteria are we using when deciding what to add to the Struts > project?
Core: 1. Must make Struts a better controller. (easier to use, more flexible, more reliable, more performant etc.) 2. See 1. "Scriptable Actions" seems to achieve the first two items in #1, so under those criteria maybe it should be in the core. Sub-projects: 1. Must add value to Struts for a good proportion of the Struts user base. 2. Must depend on Struts (does this exclude Tiles ??) 3. Must be of sufficient quality to be worthy of the Apache Struts 'brand' 4. Must have committers who have demonstrated a commitment to maintaining the add-on (either existing Struts committers or developers willing to become Struts committers). I think that, in practice, a few of the existing committers should at least be familiar with the add-on. #1 is the main reason to include a sub-project. It has to justify its existence by make life easier for Struts users. If it does that, we're performing an additional service of making it visible to a wider audience and easing its adoption by making it an "official" Struts extension. For some reason, that kind of thing means a lot to pointy-haired types ;-) > The questions I asked in the bugzilla posting haven't been > addressed. Why should the Struts team be expected to house > and support extra add-on projects? I don't see that, in this case, the Struts team is being expected to make any additional effort since it's already being maintained by two of us. Presumably, any other project would also come with developers who have been maintaining it separately. They could not only continue to do so, but also contribute to Struts core. > We've been making good progress moving code out of > Struts into the commons and focusing on a smaller core of > functionality. > I'd hate to reverse that trend and start bloating Struts again. Sub-projects should depend on Struts core, but not the other way around. So sub-projects would not bloat Struts core. Don't forget that one source for Struts sub-projects is the existing Struts codebase, thus de-bloating core Struts further. > IMO, the BSF actions are a perfect example of a core Struts > feature (ie. Actions) allowing many neat implementations that > don't have to be supported by the core project. But to make life easier for Struts' users, we can provide useful, trusted, proven extensions from the same place they already get Struts. > > David Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
