[sakai2-tcc] Annotation based injection within Sakai components

Tue May 15 17:14:35 PDT 2012

Maybe we should start planning Kernel 2.0 then? The CLE is going to be around for quite some time. I'd hate to see us stagnate for the next few years.

Would there be a way to support both approaches for dependency injection? Then it could be an optional thing that tools can adopt as they move forward, and not break everything. Of course it means that tool wouldn't work going backwards but in the ideal world, it would still be supported via a maintenance branch, as most are now.

cheers,
Steve

On 16/05/2012, at 9:00 AM, Matthew Jones wrote:

> Well the things you mention (api changes) *can* be often easily remedied via reflection or wrappers if a tool developer cared about that. Annotations for spring however which is in shared mean that we'll either require branches, patches or just say "this version doesn't work anymore". That sounds like a Kernel 2.0 thing like Dave was talking about if it did happen, because almost everyone isn't going to back-port to multiple older versions. We can't even support 2.7.x and 2.8.x very well.
> 
> I'd argue that coding anything in Java is *so 2005*, and we'd see significant developer improvements just rewriting tools in jruby/jython/groovy and going forward with that. Even junit tests written in java feel like a waste of developer time, and often either eventually break, only test the happy path, or and are never fixed because only the original author knows what they did (gradebook unit tests?). 
> 
> A few months ago Noah started some great rspec experiments with gradebook and also had some jruby/rails apps that looked pretty easy to deploy against the rest of Sakai. These looks incredibly easier to maintain than anything currently in the code. If I started a new tool it would have been in this. (Or completely external hooked up with LTI)
> 
> But I still think we need to weigh every change with it's likely-hood of increasing CLE adoption verses discouraging CLE adoption. Also figuring out what things at this point are must have and what things are nice.
> 
> If the Sakai CLE would have had less ways to do the same thing (rsf/velocity/jsf/hibernate/springmvc/wicket/ambrosia/...) then it we'd be in a better place right now. :)
> 
> I also love Ian Boston's blog post: (emphasis mine)
> "Could the same be done in Java?
> Probably, but the pace of development would be considerably less (DJango development follows a edit-save-refresh pattern and requires far fewer lines of code than Java). Also, a mature framework that had solved all the problems DJango has addressed would be needed to avoid the curse of all Java developers, the temptation to write their own framework." - http://blog.tfd.co.uk/2012/04/10/pyoae/
> 
> On Tue, May 15, 2012 at 6:29 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> There have been previous breaking API changes, specifically when a new class/method is introduced and tools then use it, which mean they cannot be used in older versions.
> 
> One that comes to mind is the ActivityService API which was added in Kernel 1.2, and Profile2 1.4+ use it, so you cannot use Profile2 1.4 in Sakai 2.7 or previous.[1]
> 
> I think at some point we need to be able to make choices that move us forward, sometimes at the expense of tool or legacy code that cannot keep up. It would certainly highlight code which is unsupported but just hanging on. So I'd be all for incorporating a number of additional changes as David lists, so that it's all out of the way at once.
> 
> Making this change would theoretically mean that a tool wouldn't need to worry about XML wiring and they can just get busy writing code. It's a small improvement, but it's really useful. The other benefit is the combination with annotation based autowiring of dependencies in JUnit tests, which I have been unable to get working with a mix of Sakai specific components.xml and annotations. It's either one or the other.
> 
> cheers,
> Steve
> 
> p.s. By the way, the lombok thing is easily done, in any layer since it is (mostly) a compile time annotation. I don't even use getters/setters anymore, they are so 2011.
> 
> [1] https://confluence.sakaiproject.org/display/PROFILE/Profile2+-+Version+Compatibility
> 
> On 16/05/2012, at 1:56 AM, David Horwitz wrote:
> 
> > If we are going to make a non-backward compatible kernel (i.e. Kernel
> > 2.0). We should consider other changes that are queued for this:
> >
> > 1) Spring 3
> > 2) Moving to the tomcat 6/7 classloader layout
> > 3) Removal of deprecated API methods
> > 4) anything I missed?
> >
> > D
> >
> > On 05/15/2012 05:39 PM, John Bush wrote:
> >> what specifically is going to break backwards compatibility ?
> >>
> >> On Mon, May 14, 2012 at 7:17 PM, Steve Swinsburg
> >> <steve.swinsburg at gmail.com>  wrote:
> >>> Hi all,
> >>>
> >>> I've just filed a feature request for annotation based injection within Sakai components. Currently it is not possible and changes need to be made to the kernel to do this:
> >>> https://jira.sakaiproject.org/browse/KNL-923
> >>>
> >>> In discussions with Aaron, this is a relatively simple job, but will be a backwards incompatible change. I'm interested to know more about this and to get the discussion going.
> >>>
> >>> Also interested to know if the incompatibility means that:
> >>>
> >>> 1. You won't be able to use a newer kernel in an older version of Sakai (ie you won't be able to use the 1.3 kernel for Sakai 2.9 in Sakai 2.8) - does anyone even do that?
> >>> 2. Tools won't work.
> >>>
> >>> thanks,
> >>> Steve
> >>> _______________________________________________
> >>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120516/33e2bbea/attachment.html 