Not every Struts committer works on Struts 2, and not every committer working on Struts 2 wants to work on XWork too. It's a security exception to give people accounts that they haven't requested and may never use.
AFAIK, to date, anyone here who wanted access to XWork has gotten it without any trouble. I don't think we need any formal agreements. (In fact, I think some people like the fact that XWork is not as formal than Struts.) We probably just need to remember to mention to new committers that anyone who wants access to XWork should ping Rainer or Don. And, in any event, the venue for that discussion would be the XWork list. :) -Ted. On Jan 4, 2008 12:24 PM, Brian Pontarelli <[EMAIL PROTECTED]> wrote: > > If the codebases are to remain separate, I'd like to suggest that all > Struts2 committers are added to XWork. The reason that I say that is the > codebases are so coupled. If you look through comments in XWork, you > start to see more references directly to Struts2. Struts2 won't function > unless XWork is functioning and the XWork API is not changing. > Therefore, it is sometimes very important to work in both codebases when > doing development for Struts2 and bugs in XWork often halt development > completely on Struts2 until they are resolved. > > -bp > > > > Ted Husted wrote: > > The backstory is that we proposed bringing over WebWork as Struts 2, > > we decided to leave XWork at OpenSymphony. One reason is that most of > > us like the strong separation between XWork and Struts 2, so as to > > keep HTTP from creeping back in the core API. Another reason is that > > incubating a large codebase is painful, and there are so many other > > ways we could spend our volunteer hours. > > > > As it stands, most or all of the active XWork committers are Struts 2 > > committers, and, in practice, Struts 2 committers tend to be welcomed > > as XWork committers. So far, XWork hasn't had too much trouble keeping > > up with the Struts 2 releases. > > > > If XWork did decide to join the ASF, it probably end up being another > > top-level Apache project, and the overall workflow wouldn't be much > > different. The net gain would be pretty much zero. > > > > Merging XWork and Struts 2 back into a monolithic codebase has been > > discussed, and the suggestion seems like a non-starter. > > > > As for OGNL, the codebase is rumored to be dark and mysterious. As Don > > mentioned, volunteer hours might be better spent making the expression > > language pluggable, and then plugging in JUEL. > > > > I'm not 100% sure, but I believe if we ever made the tags into a > > plugin, then FreeMarker would be a dependency of that plugin, rather > > than the core. (A Good Thing, IMHO.) > > > > -Ted. > > > > On Jan 2, 2008 5:26 PM, Don Brown <[EMAIL PROTECTED]> wrote: > > > >>> Also, as a separate topic, what are the future plans for all the external > >>> dependencies for Struts core? One of the difficult things I've found is > >>> that > >>> the two most major dependencies, OGNL and XWork, are not only confusing > >>> for > >>> some of my employees since the need to import from packages other than > >>> org.apache.struts2, but also not accessible to me for modification and > >>> updates and such. > >>> > >> At this point, our plan is to leave them where they are. I'd like to > >> get rid of OGNL through the JUEL plugin, and perhaps just include the > >> xwork code inside the Struts jar, dropping our dependency list down to > >> just Freemarker. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
