[Building Sakai] MT deprecation recommendationsfor 2.7

[Mark Norton]

I think the idea is to encourage the use of injection strategies while 
retaining the covers.  I maintain that covers shouldn't be deprecated at 
all.  They represent an alternative development strategy better suited 
to inexperienced/naive Sakai tool developers.  Adding to the JavaDoc 
suggesting that there are better ways to do this are fine, but a 
compiler warning suggesting that the cover will go away will only 
confuse a naive developer.

-1 on deprecating cover

Ray Davis wrote:
> That isn't how Java API deprecation typically works. As a developer I 
> would prefer to be warned sooner rather than later. And deprecation 
> warnings from the compiler should help the Maintenance team track progress.
>
> Best,
> Ray
>
> On 3/19/10 9:42 AM, csev wrote:
>   
>> How about if we add the "buyer beware" - *after* the MT finishes fixing everything in the release.   At that point, I would withdraw my objection.
>>
>> /Chuck
>>
>> On Mar 19, 2010, at 12:13 PM, Aaron Zeckoski wrote:
>>
>>     
>>> It is fair. I also can understand why people would use the covers
>>> since it is easier than trying to understand dependency injection.
>>> There are uses all over the core code as well (and quite heavily in
>>> some places like search) but the MT plans to clean these up.
>>> I feel like it is reasonable to leave them in for the life of the core
>>> services they are attached to at this point with a "buyer beware"
>>> deprecation marker on them.
>>> -AZ
>>>       
>>     
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>