However, on second thoughts, I would like to know the purpose of keeping XWork separate. Was it to allow other clients besides Struts? And do any of those exist?
My line of questioning is really about the future. If we want to clearly separate out a Struts API and Struts Core Implementation, we should think about where XWork fits into there. Is XWork really part of the Struts API? Because maybe more of Struts needs to move into XWork than the other way around. Cheers, Paul On Sat, May 10, 2014 at 6:15 PM, Paul Benedict <pbened...@apache.org> wrote: > Instead of merging, perhaps what you really need to do is modify the XWork > API to make it more extensible. It does seem a bit crazy you need to > constantly change both. XWork should be as un-struts as possible, I think. > > > Cheers, > Paul > > > On Fri, May 9, 2014 at 1:00 AM, Lukasz Lenart <lukaszlen...@apache.org>wrote: > >> Hi, >> >> I'm considering merging XWork code base into Struts Core module. There >> is a lot problems when I want to write some extension points (with >> @Inject and BeanSelectionProvider) and when the same extension point >> must be defined for class from XWork - I have to translate constants >> to keep separation of concerns :\ >> >> Do you have any objections? >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> >
