Actually, plugins already have a robust, tested versioning and dependency management system - Maven 2. Since Struts 2 plugins are built-time resources, their version and what versions they require are specified in the pom.xml and managed by Maven 2. If you want to use a Struts 2 plugin that requires an older version of Struts 2, you'll have to explicitly, in Maven 2, handle that conflict.
Of course, not everyone uses Maven 2, so perhaps we could build something that uses the pom.xml that Maven 2 automatically puts in the jar. I'd love to have a little plugin that did printed out something like php's phpinfo() method, or it could process the pom.xml's in a more intelligent way to do things like print warnings for mismatched versions. Don On 8/22/07, Ted Husted <[EMAIL PROTECTED]> wrote: > 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]
