Luckily Smart URLs is A2 ;)
I agree that providing a zip is probably better. I think ensuring that out of the box things can be configured for maximum simplicity and make it easy for developers to get up and running should be the goal. This mostly comes down to documentation and not necessarily with bundling. Writing up a good document that says, "grab these 5 JARs and put them in WEB-INF/lib" seems to be a minimal amount of overhead. The key is to provide clear information about the standard plugins and how to get up and running using them.
-bp Ted Husted wrote:
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 viathestruts-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 asallthe index support of the plugin it requires a completely differentfilter,but it would be much nicer to have everything just plug-in and run withaslittle configuration as possible. If we keep it a plugin then I would suggest removing zero-config fromcoreso that they don't conflict. I'd probably also want to rework the DispatcherFilter to make it more pluggable so that the majority of theworkis from injections and then it can be changed without modifying theweb.xml.Lastly, the configuration providers need to be easier to setup. Thiswouldprobably require a more robust configuration mechanism that wouldpre-injectconfiguration 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 conventionsrightout of the box. I feel like Struts should try to strive to match theease ofthese other frameworks. Otherwise, it requires the users to actuallyknowthat 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]
smime.p7s
Description: S/MIME Cryptographic Signature