struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Cushing <jimo...@mac.com>
Subject Re: Should I announce SmartURLs or wait?
Date Thu, 13 Sep 2007 20:34:52 GMT
A Maven archetype should get you around any license/distribution  
issues, provided the dependencies are in a public Maven repository.  
Then, Maven will download the dependencies, such that they don't need  
to be bundled. It's nice, but not necessary, that the plugins have  
Maven POMs (for the sake of transitive dependencies), and that  
doesn't necessarily mean the plugin must be built using Maven 2.



On Sep 13, 2007, at 10:56 AM, 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 <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
>


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


Mime
View raw message