[sakai2-tcc] Annotation based injection within Sakai components

[Matthew Jones]

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/20120515/d6db5d05/attachment.html