[sakai2-tcc] Annotation based injection within Sakai components

Aaron Zeckoski azeckoski at unicon.net
Thu May 17 06:39:01 PDT 2012


For everyone:

Just an FYI that I am going to be adjusting the order to try to put it
in order of priority (with the less contentious stuff being placed
early in the agenda).

If you disagree with my ordering then please feel free to yell at me
on list (or hit me on IM) but do me a favor and don't just adjust it
without talking to me (or you may find I keep on switching it back).

-AZ


On Thu, May 17, 2012 at 9:24 AM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> 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


More information about the sakai2-tcc mailing list