[sakai2-tcc] Annotation based injection within Sakai components

Steve Swinsburg steve.swinsburg at gmail.com
Wed May 16 20:50:04 PDT 2012


I go to sleep and this happens! We are a passionate bunch :)

Chuck's list is good and I expect some healthy discussions and decisions to come out of the TCC meetings at the conference. Last year's discussions were great, we got real work done. Go us!

I would, however, really like to make some technology changes that allow us to move our stack into this decade *without* breaking everything. 

Back to David's list:

1) Spring 3
2) Moving to the tomcat 6/7 classloader layout
3) Removal of deprecated API methods
[4) anything I missed?]

Out of these what would be non breaking changes? 

1. I haven't fully investigated yet but from the patch attached to KNL-517 it looks like it is just dependencies. Are there any code changes?

2. Doable with the Sakai Maven plugin - reduces additional Tomcat config required. Tools that bind to newer versions of CLE would automatically be deployed that way, tools that bind to older releases would be deployed in the old layout. Backwards compatible.

3. Depending on what this is it may be more disruptive. Risk mitigated somewhat by documenting how people move from one to another. I'm easily swung to *not* have this included and then contrib tools live happily ever after.

4. Could be keeping our shared libraries up to date, which we are generally quite good at anyway. Maybe a review/cleanup.

I've just finished running a 10 week bootcamp course here and the top two feedback criticisms were that we had to use older versions of things when developing in Sakai, AND the tomcat restart issue. It would be nice if we could make that a bit easier for people without requiring a whole re-write.

cheers,
Steve


On 17/05/2012, at 5:52 AM, Nate Angell wrote:

> I wrote a Drupal module ;)
> 
> = nate
> 
> On May 16, 2012, at 12:03 PM, Charles Severance <csev at umich.edu> wrote:
> 
>> 
>> On May 16, 2012, at 11:48 AM, Matthew Jones wrote:
>> 
>>> Well, how long does it take a new developer who has never used Sakai Services before to write a new tool that integrates with assignment/gradebook/assessments/calendar/entitybroker.
>>> 
>>> My guess would easily be months. So this makes/keeps the development pool for Sakai small (a fixed ~10-15 devs?)
>> 
>> Matt - How many developers are waiting in the wings to work on the CLE where the ease of learning is the reason they are not coding?  Zero.  Lets not solve a problem we don't have and break all the contrib tools.
>> 
>> OAE spent five years claiming to make it easier to have new developers write tools - they have made this a core theme of their design and have not achieved "easy to learn".
>> 
>> Facebook FBML is a mess and hard to learn...
>> 
>> Moodle Modules are a total pain.
>> 
>> Building Blocks ... Aargh.  You pretty much need a mentor on the inside who looks at Bb source code when you get stuck.
>> 
>> OLAT extension point is elegant but massively painful.
>> 
>> The simple answer is that none of these "internal" extension points work.   It is silly to try to make Sakai CLE extensions "easy" by changing the kernel.  No major LMS has produced an extension point that is both powerful and easy.
>> 
>> LTI is easy.   But not all-powerful.
>> 
>> /Chuck
>> 
>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120517/17e2ad83/attachment.html 


More information about the sakai2-tcc mailing list