If we bring XWork here and it becomes its own subproject, it will have its own release cycle. This will allow people to use XWork independently of Struts, but it means there is still a separate release cycle, independent of the Struts 2 release cycle. Thus we're in pretty much the same situation as we are now, except for the location of the code base.
If we bring it here and embed it within the Struts 2 core, then it will become part of the Struts 2 release, but will no longer be available as an independent entity. This means it probably will not be usable outside of Struts 2, will not be identifiable as an independent entity, and almost certainly will lose its identity as a separately usable library. Which are we trying to do? I am hearing advocates of both approaches, each with their own pros and cons... Also, are all of the existing XWork committers already Struts committers? If not, what do we plan to do about that? -- Martin Cooper 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 > >
