On 7/6/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd be fine with a "shared" module, as long as releases could be quicker and easier. As I've previously mentioned, Struts releases are really a pain due to lack of committer support and a broken release process, and I certainly don't want to put a roadblock in the path of a stable Struts 2.0 release.
For one or two shared classes, I'd agree with Don that it's not worth the pain. If you anticipate 20+ shared classes, it starts to get more interesting (but still a bunch of work). Don Craig Craig McClanahan wrote:
> On 7/5/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> Good question. Here are the options of the top of my head: >> - Jakarta Commons project >> - Put it in Struts 1.x, since Struts 2 will probably have 1 has a dep >> for >> migration code >> - Create new Struts Commons >> - Just have two copies of the code > > > FWIW, the MyFaces folks have gone through the same sort of discussion > recently, trying to decide whether/how to share code between the JSF > implementation and the component classes. The hardest part of the whole > thing is actually synchronizing releases of the helper classes, since both > framework versions would have dependencies on the common stuff. They ended > up with a variation of the third approach -- a "shared" module in the > MyFaces repository that both things could depend on. > > Craig > > To be honest, I lean towards the last option, unless the code is large >> enough to >> warrant the first. For example, Struts 1 has WildcardHelper, but so does >> XWork >> 2.0 (used by Struts 2) and it all came from Cocoon. Cocoon recently >> rewrote the >> class, so I'll need to bring over the changes into those two new >> projects. >> Sure, that is a bit of work, but not in comparison to starting a new >> project >> just for that class. >> >> Don >> >> Paul Benedict wrote: >> > A thought occured to me today. If we ever want to share code between >> struts 1 and struts 2c (ie: locale resolution), having the >> org.apache.struts package structure being the neutral place makes sense, >> with action (1.x) and action2 (2.x) being specific implementations. >> > >> > Well, not that the renaming is done, I think we have no normal way of >> sharing code across packages. Thoughts? >> > >> > -- Paul >> > >> > Ted Husted <[EMAIL PROTECTED]> wrote: On 7/1/06, Don Brown >> (JIRA) wrote: >> >> Rename Struts Action 1 to Struts 1 >> > >> > If we are using "struts1" and "struts2" for the repository folders >> > (which is fine with me), why are we using "1.x" and "2.0" for the >> > website folders? >> > >> > * http://struts.apache.org/1.x/ >> > * http://struts.apache.org/2.0/ >> > >> > In the view of "convention over configuration", I feel we we should >> > work toward using a consistent set of conventions across tools. If >> > there is not a technical reason why we need to use symbols, I'd like >> > to use "struts1" and "struts2" for the website folders. >> > >> > -Ted. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> > >> > --------------------------------- >> > Want to be your own boss? Learn how on Yahoo! Small Business. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
