You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/07/06 00:55:06 UTC

Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)

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

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 <hu...@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


Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)

Posted by Craig McClanahan <cr...@apache.org>.
On 7/6/06, Don Brown <mr...@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 <mr...@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 <hu...@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
>
>

Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)

Posted by Don Brown <mr...@twdata.org>.
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.

Don

Craig McClanahan wrote:
> On 7/5/06, Don Brown <mr...@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 <hu...@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


Re: Sharing code between versions (was [jira] Created: (STR-2898) Rename Struts Action 1 to Struts 1)

Posted by Craig McClanahan <cr...@apache.org>.
On 7/5/06, Don Brown <mr...@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 <hu...@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
>
>