OT: Managing Modifications to Struts

[Derek Richardson <De...@appiancorp.com>]

I am interested in how developers and organizations that modify Struts for their own use manage the upgrade process. Of course, one technique is to give your modifications back to the project so that they become part of the next release. But what if you don't?

Re: OT: Managing Modifications to Struts

[David Graham <gr...@yahoo.com>]

--- Greg Reddin <gr...@fnf.com> wrote:
> I've only submitted a very small amount of code to this group so I'm 
> preaching to the choir :-)
> 
> But, now that I'm learning, there are only a few reasons why I would not
> 
> submit code back to the community:
> 
> 1) The code was written under a non-disclosure agreement and I am not 
> permitted to give it away.  In this case I would probably rewrite the 
> code in my own time and submit it, then tell my boss "Hey look.  There's
> 
> an open source solution for exactly what we're trying to do."
> 
> 2) I'm too embarassed to submit the code because people will see it and 
> laugh.  As I try to humble myself more, this becomes less of an issue 
> because I find that I get help more than I get flamed, and if I get 
> flamed it's usually because I deserve it (i.e. I've been lazy or done 
> something stupid).
> 
> 3) I can't imagine it will be useful to anyone else.  In this case I've 
> usually created something that's either not really useful to myself or 
> is useful, but I could use some help in making it useful.
> 
> The bottom line is, there are very few good reasons to not submit code 
> to the community.  If you do submit, you don't have to worry about 
> upgrades and multiple code paths and whatnot.  Plus you get excellent 
> bug fixes and support.
> 
> But the real answer to your question is that there's little reason to 
> modify Struts.  Struts has so many extension points that I don't think I
> 
> would ever need to modify it.  It's real easy to subclass 
> RequestProcessor and screw a lot of things up.

FYI, the RequestProcessor hasn't met the needs of many extenders for
various reasons discussed on the struts-dev list.  A Commons Chain project
is in the works that Struts will leverage in a future release to make it
far easier to customize the request processing pipeline.  Contributions
are welcome!

David

> 
> But, in the event that you find yourself modifying the code and there's 
> no way out upgrades will be a problem.  Having done this before there 
> was a Request Processor, the best advice I can give is keep track of 
> every bit of code you change and try to do it with diff/patch tools, so 
> as much of it as possible can be automated.
> 
> Sorry to give such a long response without any good answers.
> 
> Derek Richardson wrote:
> > I am interested in how developers and organizations that modify Struts
> for their own use manage the upgrade process. Of course, one technique
> is to give your modifications back to the project so that they become
> part of the next release. But what if you don't?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: OT: Managing Modifications to Struts

[Greg Reddin <gr...@fnf.com>]

I've only submitted a very small amount of code to this group so I'm 
preaching to the choir :-)

But, now that I'm learning, there are only a few reasons why I would not 
submit code back to the community:

1) The code was written under a non-disclosure agreement and I am not 
permitted to give it away.  In this case I would probably rewrite the 
code in my own time and submit it, then tell my boss "Hey look.  There's 
an open source solution for exactly what we're trying to do."

2) I'm too embarassed to submit the code because people will see it and 
laugh.  As I try to humble myself more, this becomes less of an issue 
because I find that I get help more than I get flamed, and if I get 
flamed it's usually because I deserve it (i.e. I've been lazy or done 
something stupid).

3) I can't imagine it will be useful to anyone else.  In this case I've 
usually created something that's either not really useful to myself or 
is useful, but I could use some help in making it useful.

The bottom line is, there are very few good reasons to not submit code 
to the community.  If you do submit, you don't have to worry about 
upgrades and multiple code paths and whatnot.  Plus you get excellent 
bug fixes and support.

But the real answer to your question is that there's little reason to 
modify Struts.  Struts has so many extension points that I don't think I 
would ever need to modify it.  It's real easy to subclass 
RequestProcessor and screw a lot of things up.

But, in the event that you find yourself modifying the code and there's 
no way out upgrades will be a problem.  Having done this before there 
was a Request Processor, the best advice I can give is keep track of 
every bit of code you change and try to do it with diff/patch tools, so 
as much of it as possible can be automated.

Sorry to give such a long response without any good answers.

Derek Richardson wrote:
> I am interested in how developers and organizations that modify Struts for their own use manage the upgrade process. Of course, one technique is to give your modifications back to the project so that they become part of the next release. But what if you don't?


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org