We were using Woden M6 within Axis2. But I moved to Woden SNAPSHOT, because we were getting read to the upcoming interop event. I noticed some compilation errors in our Axis2 code, as two parameters were removed from the places I was using. I had no clue on how to correct this as those params were *just removed.* I agree that Woden devs must have complete freedom to change the API as and when they want to come up with the best possiblem API. I have no objections for that. What I need is a deprecation mechanism, so that people who are actually using Woden has a clue on adapting to changes.
For example, if the Foo class contained build() method, then Woden devs wanted to move that to Bar class, then 1. mark the Foo.build() as deprecated. Perhaps you might wanna call Bar.build() from that method. 2. Add a note in Foo.build() asking to move to Bar.method(). This process will allow Woden devs to change the APIs as and when you want. And at the same time, it will become easy for people like us to change according to the changes. If the Foo.build() was in M(i) release. And if the method change happened after it, then mark Foo.build() as deprecated in M(i+1) release and remove it in M(i+2) release. I hope I made myself clear. We will be able to have more discussion during the upcoming interop as well. -- Chinthaka Arthur Ryman wrote: > > I am starting a new thread since I've lost track of the requirements. > > Chinthaka, could you please write a short note summarizing the problem > that caused you to request that Woden "deprecate" API? > > It's hard for me to justify deprecating an API before it's been > finalized. I'd like to understand what is causing Axis2 pain. > > Arthur Ryman, > IBM Software Group, Rational Division > > blog: http://ryman.eclipsedevelopersjournal.com/ > phone: +1-905-413-3077, TL 969-3077 > assistant: +1-905-413-2411, TL 969-2411 > fax: +1-905-413-4920, TL 969-4920 > mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
