In our case, we might want to think about a struts-standard.zip or struts-bundle.zip that contained the recommended plugins -and- their dependencies. So, if we are including the Spring plugin, we would include the spring.jar too. This could just be yet another artifact that we post, like the struts-lib.zip. We might also setup a Maven prototype that did the same thing, or just offer the prototype, a la AppFuse.
Of course, this presumes that all of the plugin dependencies that we bundle can be distributed under the Apache license. -Ted. On 9/13/07, Paul Benedict <[EMAIL PROTECTED]> wrote: > My only caution with a struts2-standard.jar is that the analogy to Spring > isn't accurate. Spring doesn't have a plug-in architecture (yet) and > including more classes doesn't affecting the running of the libraries. On > the contrary, Struts plug-ins are loaded automatically and hook themselves > into the framework. So I am -1 on providing a struts with statically-bound > bundled plug-ins. A zip file distribution would be preferred. > > Paul > > On 9/11/07, Don Brown <[EMAIL PROTECTED]> wrote: > > > > Could you translate these ideas into JIRA tickets and mark them > > against 2.1? After I finish with the XWork refactoring, I'd like to > > work on making the configuration providers pluggable, because as you > > said, it really opens up some interesting possibilities. It is kinda > > tricky as you have a chicken-egg situation with providers that create > > plugins which create providers, so patches would be very welcome :) > > > > Don > > > > On 9/12/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > > > > > Well, the configuration provider is kinda a pain right now. I started a > > > thread a while back about making configuration providers pluggable via > > the > > > struts-plugin.xml file. I think it sorta died because you can use init > > > parameters to setup providers in web.xml. > > > > > > In addition, if you want to use the extensionless support as well as > > all > > > the index support of the plugin it requires a completely different > > filter, > > > but it would be much nicer to have everything just plug-in and run with > > as > > > little configuration as possible. > > > > > > If we keep it a plugin then I would suggest removing zero-config from > > core > > > so that they don't conflict. I'd probably also want to rework the > > > DispatcherFilter to make it more pluggable so that the majority of the > > work > > > is from injections and then it can be changed without modifying the > > web.xml. > > > Lastly, the configuration providers need to be easier to setup. This > > would > > > probably require a more robust configuration mechanism that would > > pre-inject > > > configuration providers and then inject the rest of the container. > > > > > > However, all that said, I think this should be in core. The beauty of > > > frameworks like Rails and Grails is that they give all the conventions > > right > > > out of the box. I feel like Struts should try to strive to match the > > ease of > > > these other frameworks. Otherwise, it requires the users to actually > > know > > > that the plugin exists, go find it, install it and then learn it all. > > > > > > -bp > > > > > > > > > > > > Don Brown wrote: > > > The reason the zero config stuff is in core is mainly because it > > > requires a configuration provider, which cannot be plugged in via a > > > struts plugin. Is there any other technical reason that this should > > > be in core? > > > > > > Don > > > > > > On 9/11/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > > > > > > > > IMO this should be a "core" feature of struts 2. > > > > > > musachy > > > > > > On 9/10/07, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hmm...along those lines, could SmartURL be Codebehind 2.0? > > > > > > As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among > > > other things, make OGNL pluggable and fully migrate the code to > > > container injection (no statics!). I should be done sometime this > > > week. > > > > > > Don > > > > > > On 9/11/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > > > > > > Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x > > > could be out next week, or next month, or next year. There's really no > > > telling. > > > > > > I'm not sure what "rolling it into the core" means. If it means > > > putting the source into the Struts-Core JAR, then I'd probably be > > > opposed. Personally, I'd like to keep rolling things out of the core > > > and distribute as much as possible in the form of plugins. Ultimately, > > > there should be nothing in the core that doesn't *need* to be in the > > > core. My thought would be to include SmartURLs in Struts 2.1.x as the > > > successor to the CodeBehind plugin. > > > > > > -Ted. > > > > > > On 9/10/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > > > > > > > > +1 for waiting and rolling it into core, it could be available for 2.1 > > > > > > musachy > > > > > > On 9/10/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > > > > > > > > I was planning on release 1.0 of SmartURLs in the near future and doing > > > some announcements to the user lists and some other locations. However, > > > should I wait on that if favor of rolling this back into core, or should > > > I go ahead? > > > > > > Thoughts? > > > > > > -bp > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > -- > > > "Hey you! Would you help me to carry the stone?" Pink Floyd > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
