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] > >
