struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <hus...@apache.org>
Subject Re: Should I announce SmartURLs or wait?
Date Thu, 13 Sep 2007 14:56:20 GMT
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 <pbenedict@apache.org> 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 <mrdon@twdata.org> 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 <brian@pontarelli.com> 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 <musachy@gmail.com> wrote:
> > >
> > >
> > >  IMO this should be a "core" feature of struts 2.
> > >
> > > musachy
> > >
> > > On 9/10/07, Don Brown <mrdon@twdata.org> 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 <husted@apache.org> 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 <musachy@gmail.com> wrote:
> > >
> > >
> > >  +1 for waiting and rolling it into core, it could be available for 2.1
> > >
> > > musachy
> > >
> > > On 9/10/07, Brian Pontarelli <brian@pontarelli.com> 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: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> > >  --
> > > "Hey you! Would you help me to carry the stone?" Pink Floyd
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>


-- 
HTH, Ted <http://www.husted.com/ted/blog/>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message