[sakai2-tcc] Annotation based injection within Sakai components

[Steve Swinsburg]

Great, thanks Aaron. I've fleshed it out with everything that's been on my mind. Can cull/review the list as req'd.

cheers,
S

On 17/05/2012, at 9:18 PM, Aaron Zeckoski wrote:

> I created a confluence page for the TCC conference meetings so please
> feel free to go crazy with adding topics to the agenda. I put some of
> these on there and I will leave it to others to flesh out the list
> (for now anyway).
> 
> https://confluence.sakaiproject.org/x/gIXSB
> 
> -AZ
> 
> 
> On Wed, May 16, 2012 at 11:50 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile



Begin forwarded message:

> From: Aaron Zeckoski <azeckoski at unicon.net>
> Subject: Re: [sakai2-tcc] Annotation based injection within Sakai components
> Date: 17 May 2012 9:18:31 PM AEST
> To: Steve Swinsburg <steve.swinsburg at gmail.com>
> Cc: sakai2-tcc Committee <sakai2-tcc at collab.sakaiproject.org>
> 
> I created a confluence page for the TCC conference meetings so please
> feel free to go crazy with adding topics to the agenda. I put some of
> these on there and I will leave it to others to flesh out the list
> (for now anyway).
> 
> https://confluence.sakaiproject.org/x/gIXSB
> 
> -AZ
> 
> 
> On Wed, May 16, 2012 at 11:50 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile


Begin forwarded message:

> From: Aaron Zeckoski <azeckoski at unicon.net>
> Subject: Re: [sakai2-tcc] Annotation based injection within Sakai components
> Date: 17 May 2012 9:18:31 PM AEST
> To: Steve Swinsburg <steve.swinsburg at gmail.com>
> Cc: sakai2-tcc Committee <sakai2-tcc at collab.sakaiproject.org>
> 
> I created a confluence page for the TCC conference meetings so please
> feel free to go crazy with adding topics to the agenda. I put some of
> these on there and I will leave it to others to flesh out the list
> (for now anyway).
> 
> https://confluence.sakaiproject.org/x/gIXSB
> 
> -AZ
> 
> 
> On Wed, May 16, 2012 at 11:50 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile


Begin forwarded message:

> From: Aaron Zeckoski <azeckoski at unicon.net>
> Subject: Re: [sakai2-tcc] Annotation based injection within Sakai components
> Date: 17 May 2012 9:18:31 PM AEST
> To: Steve Swinsburg <steve.swinsburg at gmail.com>
> Cc: sakai2-tcc Committee <sakai2-tcc at collab.sakaiproject.org>
> 
> I created a confluence page for the TCC conference meetings so please
> feel free to go crazy with adding topics to the agenda. I put some of
> these on there and I will leave it to others to flesh out the list
> (for now anyway).
> 
> https://confluence.sakaiproject.org/x/gIXSB
> 
> -AZ
> 
> 
> On Wed, May 16, 2012 at 11:50 PM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120517/490683a2/attachment-0001.html