The SOB you are talking about is a well-respected (and present)
colleague of mine and our team backed the decision, so the fun (which i
was not observing as you did) ends exactly here :-(
Robert
Bill Bohnenberger schrieb:
What an amusing thread. It seems to me the only problem here is the arrogant
SOB that decided to defy the Bean naming conventions. LOL. (No offense
intended if he is present company :)
With affection,
Bill
On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski <r...@lsoft.com>wrote:
Rafał Krupiński schrieb:
On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski <r...@lsoft.com>
wrote:
approach, which is tedious work because
[...]
i have to go through each applicable class and
refactor-rename each method.
Please don't try to make us feel guilty :-)
You'll get paid for this, we're not.
In previous post I stated clearly: "If the only problem is the number
of methods to be changed"
not "If you can change only some classes".
Well, yes, i am getting paid for this. So the time that i need to rename
the methods costs my employer big money.
This is a case of true backwards incompatibility and causes trouble in
non-trivial projects such as ours. Other projects may decide to not upgrade
from earlier Struts versions to V 2.1.8.1, which is something i would
definitely take serious if i were working without getting paid, because
having your stuff used by as many people out there as possible is a major
point of FOSS, right? Freedom of choice is the other, meaning that we could
of course stick with V2.1.6 and patch it to our liking. I personally voted
against the latter option and decided to go for the renaming option because
we need some other fixes that are available in 2.1.8. And, to tell the
truth, our choice to use "getmProperty()" as accessor method naming pattern
was a bad one originally but we lived with it since the beginning and are
now being bitten in the behind :-)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
