On Thu, Aug 6, 2009 at 4:22 PM, Musachy Barroso<musa...@gmail.com> wrote: > Sounds reasonable to me. Couple of question to fuel discussion: > > What would be the target version? > Do we need to go through incubation, etc? (I have never known much > about the ASF legal process)
The code would definitely have to go through an IP clearance step, which I'd be happy to help with. The target version will just be the Struts version - no need for a separate release cycle. Don > > musachy > > On Wed, Aug 5, 2009 at 10:12 PM, Don Brown<donald.br...@gmail.com> wrote: >> XWork was left at OpenSymphony, because at the time, there were a >> number of WebWork developers still around and we wanted to continue to >> work together. Today, WebWork activity seems all but dead, leaving us >> with no advantages having the code hosted over there. Furthermore, >> having critical code in different packages is really confusing for >> developers of the framework and its apps with no apparent benefit. >> >> Ideally, I'd like to bring xwork trunk into the core jar and be done >> with the theoretically useful yet practically painful split. However, >> that would break Struts 2 apps without tedious backwards-compatibility >> code, but getting the code bases integrated is the first step. Maybe >> at first, we keep two artifacts, but I think we should think about a >> serious migration to just one. XWork itself will always be around, >> but trying to put a framework at our core that is meant for ambiguous >> theoretical users brings unnecessary complexity and problems to all >> parties. >> >> Can I start planning the funeral? :) >> >> Don >> >> On Thu, Aug 6, 2009 at 11:55 AM, Wes Wannemacher<w...@wantii.com> wrote: >>> On Wednesday 05 August 2009 09:44:45 pm Musachy Barroso wrote: >>> [snip] >>>> >>>> I was going to ask if anyone was using it outside struts, but that >>>> doesn't prevent us from making it it's own artifact. >>>> >>> [snip] >>>> >>>> I don't think this would fix the problem, which is the duplicated >>>> effort on the builds. A good compromise would be to keep it under its >>>> own artifact under struts, just like core, that way we would need just >>>> one release and it could still be used independently. I haven't cared >>>> much before, but if it will make our releases easier/smoother, then I >>>> am +1 for it. >>>> >>> >>> being its own artifact makes more sense, it would make releasing the two >>> much >>> easier, on second thought I agree with this. My only real concern is that I >>> can get to it w/o struts. The context I am working with now doesn't fit well >>> with struts, and adding struts means I would have to do even more work >>> getting >>> a base configuration so that xwork can run actions. One example that sticks >>> out >>> in my mind is that when I run actions, each action execution gets its own >>> thread and one of the results I built for this project launches from 1 to >>> infinite more actions. Obviously it wouldn't make sense to chain to multiple >>> actions in a web-app and since a view is rendered in struts, having actions >>> run in a separate thread wouldn't work well in a web-app. >>> >>> -W >>> >>> -- >>> Wes Wannemacher >>> >>> Head Engineer, WanTii, Inc. >>> Need Training? Struts, Spring, Maven, Tomcat... >>> Ask me for a quote! >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
