[Building Sakai] K1 - uitils rationalization?

[csev]

I like the commitment to not removing the APIs and to focus this on  
good documentation.  This allows new code to be "done right" and going  
forward and makes it convenient for existing code to migrate to best  
practices in good time and when they get the urge to do so.

Also if someone wanted to go through and point places like K1 at the  
new APIs - that too would be cool - but something that should e done  
carefully with some testing to make *sure* that functionality did not  
change.

/Chuck

On Jun 8, 2009, at 10:58 AM, David Horwitz wrote:

> Hi Chuck
>
> I'm certainly not suggesting that we remove methods from the API, I'm
> merely suggesting we mark them as deprecated in the case outlined. The
> motivation is to reduce the code that the kernel team has to manage to
> what is important to Sakai. I agree we need to make things easier for
> contrib developers I suggest we do this by not changing the API's and
> steering them to standard java libraries rather the sui generis  Sakai
> methods. As I noted in the thread earlier I believe where there is a
> good reason for having our own method this should be clearly noted in
> the Javadoc too ("unlike commons-foo this method...."). I see this  
> as a
> case for minimal effort (reviewing the content of utils, adding
> @deprecated and some explanatory doc) we can get increasing benefit
> during the life of the 2.x
>
> Regards
>
> David