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
