[Building Sakai] 2x: Entity Broker into Kernel for 2.8

[csev]

This all makes reasonable sense with one gentle adjustment from my perspective.

Sakai is already so entangled with EB that whatever "future liability" is already there.  Simply moving the code into K1 does not alter the "future liability" in the least.

That said, I am always a supporter of having dependencies on tiny external projects pulled into our own source so if in the future something happens, we control our own destiny - of course the danger is the we "fork" - even a tiny bit.   My own inclusion of OAuth source code from a Google code project is something is less than ideal and something I am hoping to improve..

One really interesting approach to this that I am testing a bit with IMS Basic LTI support is to host the code in Sakai's SVN and make artifacts that are widely usable outside of Sakai.

A good example is the code in:

https://source.sakaiproject.org/svn//basiclti/trunk/basiclti-util/pom.xml

If you look at this, the code is copyright IMS, Apache 2 and it produces a jar file that is used in Sakai 2, Sakai 3, OLAT and (who knows) perhaps even my Shindig support for IMS Basic LTI.

In my opinion, there is no reason we cannot host, produce, develop and use indie artifacts from within the Sakai servers, project, and developer community.  I feel that the Sakai community is large enough and robust enough that other projects should not perceive our Maven artifacts as "here today and gone tomorrow".   I am not suggesting this as *the* way forward for reflectutils - just an idea that has been gurgling in the back of my mind for a while.

In summary, whilst some analysis is a good idea and a conversation with Aaron and Kernel about dependencies is completely in order, none of what you raise below sways me away from my recommendation of inclusion as quickly as possible.  I would rather move EB quickly to clean up our own messy internal dependencies a bit and then work the other issues as issues to track.

/Chuck

On Jun 30, 2010, at 7:22 AM, Ian Boston wrote:

> IMVHO before bringing anything into Kernel you should review what you are bringing in and its dependencies on the following basis:
> Ideally you should do that review in public, on list, so that , in the words of Roy Fielding... it happened.
> 
> I say this only to ensure that deployers and commercial SCA's don't find themselves with a unexpected liability in the future.
> 
> -------------------------------------------------
> 
> Ages ago, EB was considered for K1, we did a review with Aaron and he reduced the dependencies down. The one remaining dependency was reflectutils[1]. At the time Aaron was the sole committer. Nothing wrong with this if the code is never changed, and Aaron spends the rest of the lifetime of Sakai 2 working for Sakai. (10-15 years perhaps)
> 
> I suggested at the time that that code was made sustainable by either 
> a)  adding as many committers as possible to reflect utils with some form of succession
> b) bringing the code base back into Sakai 2
> 
> these things were not seen as possible at the time. I think GenericDAO many be similar.
> 
> Thats what we did then, if you have already done this on list, fantastic (and you can ignore everything I just said), if not, you might want to.
> 
> HTH
> Ian
> 
> 1 http://code.google.com/p/reflectutils/