[Building Sakai] [Management] MT deprecation recommendations for 2.7

[Noah Botimer]

My thoughts here are simple and brief. My solution:

1. Remove all usage of covers from "the release".

2. Mark everything about them deprecated.

3. Keep them synchronized until 2015 (i.e., forever).

4. Add a Maven profile to lint the code and yell if any usage creeps back
in.

5. Include a link in every file's Javadoc to a permanent page of
instructions on how to use the profile to scan and the alternatives for
contrib/local code.

6. Eat pizza with the money we save on not rewriting code.

Everybody wins.


I think the unit test scenario is a red herring. If someone had the
resources to write the tests, they would exist. The fractional cost to
switch off the covers is not why we don't have them. 

Thanks,
-Noah

On Thu, 18 Mar 2010 09:08:21 -0400, Mark Norton <markjnorton at earthlink.net>
wrote:
> Anthony Whyte wrote:
>> 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?
> For you and I - no.  For a Java developer familiar with Spring - 
> probably not.  However, I've  trained dozens of developers in Sakai tool 
> development who are NOT familiar with Spring or even the concept of 
> injection.  While admittedly a crude approach to solving the problem, 
> covers are considerably easier for non-Spring Java programmers, or 
> (perhaps more importantly) experienced non-Java programmers.
>> 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.
> What is the problem of writing unit tests and the presence of service 
> manager covers?  If the cover is a method duplicate of the service 
> manager, unit tests should work equally well for both (with the addition 
> of the getInstance() method).
>> 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.
>>   
> I'd like to understand how it is in the way.
> 
> - Mark
> 
> _______________________________________________
> 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"