[Building Sakai] [Management] MT deprecation recommendationsfor 2.7

Fri Mar 19 03:46:47 PDT 2010

First off: I do not know a great deal about annotations, but ...

Could we not write an annotation that just goes and wires up our 
dependency for us, via the component manager? That way people don't have 
to mess with spring XML and don't have to write the ComponentManager code.

Like I said, I don't really know much about them so it may not be 
feasible. It would be nice though.

Cheers,

Adrian.

Steve Swinsburg wrote:
>
>>
>> It may be necessary that the code which is being unit-tested does not 
>> use the static covers, but that is no obstacle to any other 
>> (non-unit-tested code, e.g.  local tools, 3rd-party code) continuing 
>> to use the static covers.
>
> Except new tools and new developers are still using them. 
>
> At least deprecating them signals that they should change. If the 
> timeline is long enough for Kernel 2.0.0, we should be able to remove 
> all instances in the current code. Using the ComponentManager it is 
> extremely simple.
>
> cheers,
> Steve
>
>
>
>>
>>>>> "Berg, Alan" <A.M.Berg at uva.nl <mailto:A.M.Berg at uva.nl>> 3/19/2010 
>>>>> 9:31 AM >>>
>> Hi all,
>>
>> I like Noahs email as debate is most welcome as QA hopes to motivate 
>> an increase test coverage.
>>
>>> 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.
>>
>> Agreed
>>
>>> I think the unit test scenario is a red herring.
>>
>> Disagree.  If the MT agree to add tests as they maintain then we 
>> start to cluster and increase the regression testing around weak points.
>>
>> I am a great fan of unit like tests in combination with continuous 
>> builds. In Sakai 2.x if a bug is found I would promote the idea of 
>> adding tests around the cleaned code.If we run the builds say once 
>> every 2 hours with a praise mechanism then the community more 
>> aggressively avoids regression. I therefore think the current status 
>> of having limited test coverage is not an argument. I find David 
>> Haines suggestion of adding an extra method to get the instance in 
>> the cover rather intriguing and would enjoy more discussion. I also 
>> see Aarons point about ad-hoc improvement removing covers as code is 
>> maintained, as an incremental investment.
>>
>> Opinions?
>>
>>
>>
>> Alan
>>
>> Alan Berg
>> Interim QA Director - The Sakai Foundation
>>
>> Senior Developer / Quality Assurance
>> Group Education and Research Services
>> Central Computer Services
>> University of Amsterdam
>>
>> http://home.uva.nl/a.m.berg
>>
>>
>>
>>
>> -----Original Message-----
>> From: sakai-dev-bounces at collab.sakaiproject.org on behalf of Noah Botimer
>> Sent: Thu 3/18/2010 22:42
>> To: markjnorton at earthlink.net
>> Cc: Developers Sakai-Dev
>> Subject: Re: [Building Sakai] [Management] MT deprecation 
>> recommendationsfor 2.7
>>
>>
>> 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"
>> _______________________________________________
>> 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"
>>
>>
>>
>>
>>
>> ______________________________________________________________________________________________ 
>>
>>
>> UNIVERSITY OF CAPE TOWN
>>
>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer 
>> published on our website at 
>> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable 
>> from +27 21 650 4500. This e-mail is intended only for the person(s) 
>> to whom it is addressed. If the e-mail has reached you in error, 
>> please notify the author. If you are not the intended recipient of 
>> the e-mail you may not use, disclose, copy, redirect or print the 
>> content. If this e-mail is not related to the business of UCT it is 
>> sent by the sender in the sender's individual capacity.
>>
>> _____________________________________________________________________________________________________
>>
>> _______________________________________________
>> 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"

-- 
==================================
Adrian Fish
Software Engineer
Centre for e-Science
Bowland Tower South C Floor
Lancaster University
Lancaster
LA1 4YW
email: a.fish at lancaster.ac.uk

http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/BLOG/Home
http://confluence.sakaiproject.org/display/AGORA/Home

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_fish.vcf
Type: text/x-vcard
Size: 289 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100319/953a250e/attachment.vcf 