[sakai2-tcc] Annotation based injection within Sakai components

Wed May 16 08:26:06 PDT 2012

Can you tell us why you think CLE coding is a pain in the arse? The 
'fact' of it being a 'pain in the ass' doesn't seem to have deterred 
people from writing plenty of tools for it ...

Cheers,
Adrian.

On 16/05/2012 15:22, John Bush wrote:
> well right.  I guess what I'm saying is a reaction to matthews email.
> Little incremental changes like moving to this version of spring or
> that version of whatever aren't any sort of game changer for Sakai,
> they aren't going to solve the fundmental problems.  So if those
> incremental changes lead to a bunch of problems for no real gain, I
> don't see the point, it seems like a giant waste of effort.
>
> The fact that its a giant pain in the ass to do Sakai development
> isn't going to be solved by these little things.  Its still going to
> be a giant pain in the ass.  Maybe a little better, but still way too
> hard.
>
> I can't see why anyone would even want to build a new tool in sakai at
> this point, at least if you believe OAE will get off the ground at
> some point.  LTI makes much more sense, since anything you do there
> can run in OAE when its ready.
>
> That said I don't object to a kernel 2.0, it can go off and do its own
> little thing.  But I'm very doubtful that it would have much adoption
> at this point, outside of a few places, so in reality I'm not worried
> about it breaking anything, because I don't think anyone will even use
> it.
>
> On Wed, May 16, 2012 at 3:26 AM, Aaron Zeckoski<azeckoski at unicon.net>  wrote:
>> Just FYI that the idea of having reloadable services was one of the
>> first ideas that lead to the development of OAE (or K2 as it was known
>> as back then).
>>
>> If we really wanted something like that it would mean using spring
>> dynamic modules or some other OSGi framework.
>> http://www.springsource.org/osgi
>>
>> You can get reloadable services without that but it involves a LOT of
>> manual effort.
>>
>> I'm not sure anyone is ready to refactor the sakai kernel to use OSGi
>> (Spring DM or other). That effort would be massive.
>>
>> -AZ
>>
>>
>> On Wed, May 16, 2012 at 1:10 AM, John Bush<john.bush at rsmart.com>  wrote:
>>> I've worked on a few projects recently: oae, spring3, and tapestry
>>> that do injection without xml, and I have to say I do not miss xml.  I
>>> think if we go this route we'd want to be able to support annotations
>>> or xml wiring which I think spring can do.  The idea of a giant
>>> refactoring effort or breaking existing tools does not appeal to me.
>>> The ability for folks to innovate at a faster pace does appeal to me.
>>> So I'm for solutions that allow us to move out of 2005 with minimal
>>> pain for the legacy code.
>>>
>>> I don't see injection configuration as the big road block right now,
>>> its the lack of runtime configurability and hot swapping components
>>> that slow me down more than anything, and the technology soup issue
>>> Matthew brought up.  Now if kernel 2.0 was going to start tackling
>>> those types of issues I'd get interested.
>>>
>>> On Tue, May 15, 2012 at 5:31 PM, Aaron Zeckoski<azeckoski at unicon.net>  wrote:
>>>> Depending on how cutting edge spring we are trying to use (i.e. how
>>>> much we are willing to break), the XML file is still required. It just
>>>> doesn't have to have a bunch of beans defined in it. However, it does
>>>> typically still have some tags to tell it to scan for beans in the
>>>> classloader.
>>>>
>>>> Normally, this is done by specifying a domain to scan for like
>>>> org.sakaiproject (so anything not using that class path would not be
>>>> auto-injected).
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <beans xmlns="http://www.springframework.org/schema/beans"
>>>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>     xmlns:p="http://www.springframework.org/schema/p"
>>>>     xmlns:context="http://www.springframework.org/schema/context"
>>>>     xsi:schemaLocation="http://www.springframework.org/schema/beans
>>>> http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>>>> http://www.springframework.org/schema/context
>>>> http://www.springframework.org/schema/context/spring-context-3.0.xsd">
>>>>
>>>>     <context:component-scan base-package="org.sakaiproject" />
>>>> </beans>
>>>>
>>>> Either way, most likely we would still require an XML file for every
>>>> component so therefore we would be supporting the XML method
>>>> intrinsically and optionally also supporting the annotations method
>>>> (if the component-scan tag was included in that component).
>>>>
>>>> -AZ
>>>>
>>>>
>>>> On Tue, May 15, 2012 at 8:14 PM, Steve Swinsburg
>>>> <steve.swinsburg at gmail.com>  wrote:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> --
>>> John Bush
>>> 602-490-0470
>>> _______________________________________________
>>> 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
>
>

-- 
==================================
Adrian Fish
Software Engineer
B66 Management School
Lancaster University
Lancaster
LA1 4YW

http://www.sakaiproject.org
http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/CLOG/Home
http://confluence.sakaiproject.org/display/BBB/Home