struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Approaches to Contributing to Struts (Re: [Apache Struts Wiki] Updated: StrutsUpload)
Date Fri, 11 Mar 2005 17:42:20 GMT
At 8:29 AM -0800 3/11/05, Dakota Jack wrote:
>Thanks, Frank.  I posted this code in response to Ted's suggestion
>that this is the way to go to establish a dialogue with the committers
>on code.

I would totally endorse Ted's suggestion.  The best approach is to 
publicly document approaches and, where possible, provide extension 
code that can be exercised without rushing a change to the Struts 
core.  This is how struts-chain was developed and verified as a 
reasonable approach before the core was changed.  It also happens to 
be how validator and tiles evolved.  In a much more modest fashion, 
this was the origin of the DigestingPlugIn, which I developed and 
published and which was adopted into Struts all before I was a 

I feel bad seeing Frank's obvious bitter feelings, and as I noted 
elsewhere, I'm sorry I wasn't following the thread closely enough to 
warn that his efforts were pushing in a direction that Struts doesn't 
follow.  In fact, I know of no open source project which would add 
incompatible features to an older release, except in the case of a 
major version number change.

I don't think we've earned "Struts 2.0" with the other changes we 
have, although until we do a release, we could certainly debate 
calling the chain based processor Struts 2.0 and making room for 
Frank's changes in what would then be a live development version on 
the 1.x branch.

As always, remember that we're all volunteers here, and we all have 
to scrounge for the time we apply to Struts.  Also, we have an 
enormous installed base, and we have to take their needs into 
account.  If the general open source community has come to expect 
compatibility between minor version releases, and if we've always 
struck a firm stance towards providing that kind of compatibility in 
Struts, then we need to maintain consistency.

Frank, have you exhausted any hope of packaging your changes as 
something which can be added on to Struts 1.2 without requiring 
changes to the core classes?  It may seem cumbersome, but I have a 
feeling that it would be possible to package your changes as 
extensions instead of core changes or a forked Struts distribution. 
Where Struts falls short in this regard, I would be interested in 
helping design and implement changes to both 1.2 and 1.3 to improve 
its extensibility.

If Frank is burned out, but there's as much interest as there seemed 
to be on the list, perhaps some of those people would be willing to 
carry the baton to the next stage.


Joe Germuska       
"Narrow minds are weapons made for mass destruction"  -The Ex

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message