[Building Sakai] MT deprecation recommendationsfor 2.7

Sat Mar 20 07:02:05 PDT 2010

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>
> Date: March 17, 2010 11:55:13 PM GMT+02:00
> To: Clay Fenlason <clay.fenlason at et.gatech.edu>
> Cc: management at collab.sakaiproject.org, Developers Sakai-Dev <sakai-dev at collab.sakaiproject.org>, Sakai QA <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
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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"
>> 
>> 
> 
> _______________________________________________
> 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"
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100320/34d52387/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100320/34d52387/attachment.bin 