[Building Sakai] MT deprecation recommendationsfor 2.7

[Jean-Francois Leveque]

+1 from a naive developer willing to learn

Anthony Whyte a écrit :
> The all-or-nothing cast to this discussion is going to lead us nowhere 
> fast.  I put forward a compromise proposal on 17 March and echoed by 
> David Haines on the 19th that offers us incremental, case-by-case 
> approach.  It recognizes that there may be times when a static cover 
> needs to be sacrificed in the interests of providing unit tests that 
> help strengthen the bug fix validation and verification process.
> 
> Ensuring that core production code is stable, reliable, maintainable and 
> defect free (to the best of our abilities) trumps, in my view, 
> (inexperienced) developer conveniences or local/contrib implementation 
> decisions.  That said, as Stephen Marquard has pointed out, deprecating 
> and then removing static covers wholesale could well impose extra costs 
> on schools required to refactor static covers out of their local/contrib 
> code.  This needs to be recognized but should not impose an absolute 
> blocker on static cover removal.
> 
> So, 
> 
> 1.  Deprecate static covers in trunk/2.7.x (this at least provides a 
> Javadoc warning that a cover might in future be removed)
> 2.  Add further documentation in Confluence regarding Sakai developer 
> best practices with respect to covers.
> 3.  Address any static cover removal question on a case-by-case basis in 
> Jira and on list (perhaps limited to blocker/critical issues).  
> 4.  If a static cover removal is justified, do it.
> 
> Cheers,
> 
> Anth
> 
> 
>> COMPROMISE PROPOSAL (17 March)
>> I'd like to see static covers eventually removed (so +1) but recognize 
>> that the current crowd wisdom appears to consider this desire, well, 
>> unwise.  Still, I'd like to suggest a compromise proposal, one that 
>> permits the removal of a static cover whenever it impedes the 
>> implementation of unit tests written in support of a bug fix. 
>>  Extension of 2.x unit test coverage is work that meets a long 
>> standing yet largely unrealized goal of the Sakai Community. 
>>  Suspending such work because one finds a static cover in the way 
>> appears to me unwise.
> 
> 
> 
> 
> Begin forwarded message:
> 
>> *From: *Anthony Whyte <arwhyte at umich.edu <mailto:arwhyte at umich.edu>>
>> *Date: *March 17, 2010 11:55:13 PM GMT+02:00
>> *To: *Clay Fenlason <clay.fenlason at et.gatech.edu 
>> <mailto:clay.fenlason at et.gatech.edu>>
>> *Cc: *management at collab.sakaiproject.org 
>> <mailto:management at collab.sakaiproject.org>, Developers Sakai-Dev 
>> <sakai-dev at collab.sakaiproject.org 
>> <mailto:sakai-dev at collab.sakaiproject.org>>, Sakai QA 
>> <sakai-qa at collab.sakaiproject.org 
>> <mailto:sakai-qa at collab.sakaiproject.org>>
>> *Subject: **Re: [Building Sakai] [Management] MT deprecation 
>> recommendations for 2.7*
>>
>> Yes, I sidestepped both JCR as well as the static cover deprecations 
>> recommendations in my email of last Sunday, choosing instead to focus 
>> solely on 2.7 tool deprecations in an effort to secure at least lazy 
>> consensus on how I planned to handle deprecations in the next QA tag.
>>
>> JCR
>> Despite the experimental nature of JCR I recommend we follow the same 
>> approach as we do for tool deprecations: deprecate in kernel-1.1 and 
>> remove in kernel-1.2 (moving JCR to contrib).  This should provide 
>> sufficient time for anyone using the JCR service to adjust their build 
>> practices to compensate for it's eventual removal from the kernel.  We 
>> should announce this decision with a deprecation alert (I plan to 
>> draft these when I return to the US) and provide one or more reminders 
>> of JCR's impending removal during 2010, early 2011.
>>
>> COVERS
>> You've no doubt seen the objections raised regarding deprecating 
>> static covers in the kernel and elsewhere.  While I am not persuaded 
>> by the claims that static cover removal truly raises barriers to 
>> writing Sakai tools--is it really all that challenging to add a 
>> service injection setter method that relies on a bit of XML residing 
>> in a Spring bean configuration file?--I am sensitive to the assertion 
>> that static cover removal imposes costs on those maintaining local 
>> code that make use of the covers.  Indeed, for an example of the 
>> refactoring involved in removing static covers in favor of service 
>> injection see http://jira.sakaiproject.org/browse/SAK-12077.  The 
>> work, while by no means onerous or difficult, is nevertheless non-trivial.
>>
>> Moreover, the kernel team is currently split on this issue in so far 
>> as static cover removal is concerned--a difference of opinion that 
>> raises something of a blocker to the removal proposal, although it 
>> should be recalled that static cover removal as proposed by David 
>> Horwitz would not commence for some time.
>>
>> COMPROMISE PROPOSAL
>> I'd like to see static covers eventually removed (so +1) but recognize 
>> that the current crowd wisdom appears to consider this desire, well, 
>> unwise.  Still, I'd like to suggest a compromise proposal, one that 
>> permits the removal of a static cover whenever it impedes the 
>> implementation of unit tests written in support of a bug fix. 
>>  Extension of 2.x unit test coverage is work that meets a long 
>> standing yet largely unrealized goal of the Sakai Community. 
>>  Suspending such work because one finds a static cover in the way 
>> appears to me unwise.
> 
> 
> 
> 
> 
> On Mar 19, 2010, at 7:48 PM, Mark Norton wrote:
> 
>> 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