struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)
Date Thu, 06 Jul 2006 17:08:40 GMT
On 7/6/06, Don Brown <mrdon@twdata.org> 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 <mrdon@twdata.org> 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 <husted@apache.org> 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: dev-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >> >
> >> >
> >> > ---------------------------------
> >> > Want to be your own boss? Learn how on  Yahoo! Small Business.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message