If someone is good enough to support a plugin, then they should also be good enough to support Struts proper too.
In this line of thinking, it may good to outsource the lesser plugins into GoogleCode (or whatever). If any plugins gain enough traction with outside committers, perhaps then you do things: (1) tap the committers and (2) incubate the code for ASF ownership. This will, in theory, allow a lower bar for development of plugin germination, but with the intention of us getting the talent and deliverables for Struts. Paul On 8/21/07, James Holmes <[EMAIL PROTECTED]> wrote: > > Oooh, good thinking! I mean on the minimum version check thing. > > > On Tue Aug 21 14:38 , 'Ted Husted' <[EMAIL PROTECTED]> sent: > > >On 8/21/07, Ian Roughley [EMAIL PROTECTED]> wrote: > >> For the plugins kept in s2, the other change I would like to see is > >> independent life cycles. If the code has not changed, I'm not sure why > >> its version needs to be incremented (other than staying with the s2 > core > >> version). Would independent SVN repos help here? > > > >What might help most would be a slightly more sophisticated plugin > >system, so that a plugin could declare its own minimum version of > >Struts Core, and loudly refuse to load if the minimum requirements are > >not met. (Of course, the same should be true of any external > >dependencies!) > > > >Following Don's lead, it might be a good idea to look toward OSGi as a > >plugin model, which is what Eclipse also uses. > > > >-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] > >
