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

[Ian Boston]

IMVHO before bringing anything into Kernel you should review what you are bringing in and its dependencies on the following basis:
1. License
2. Provenance
3. Sustainability

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/

On 30 Jun 2010, at 04:43, csev wrote:

> One of the things that we talked about for 2.8 in the Denver meeting was moving Entity broker into Kernel.
> 
> http://confluence.sakaiproject.org/display/MGT/Sakai+2x+Project+Planning+Goals
> 
> It would seem to me that the earlier, the better to let things settle down.  It looks like the service would go into Kernel whilst the /direct code would stay in the main SVN.
> 
> I have a suggestion that when we do this, we keep an empty entity broker jar in its former location until at least after 2.8.   We would move the non servlet bits of EB into kernel, then release kernel, put the "empty jar" into the EB in non-kernel space and then "indie release" the new EB with the empty EB artifact and update the EB version in the main SVN to the new indie release.
> 
> Perhaps you are wondering, why the gerrymandering?   For me it is to keep things smooth for lots of code with EB dependencies from having to change their POMs in a way that breaks them for 2.5 - 2.7 so they work in 2.8.  By having the empty EB artifact, we can delay the mass update of dependencies for stuff from contrib until 2.9.  I do think we would quickly remove the unneeded dependencies from the core Sakai release - but let contrib tools have a bit more time.
> 
> Again, this is just to make those with vendor branches lives a little easier as well as make it smooth for folks a release behind and branch managers and make it quicker to get contrib stuff across the 2.7 to 2.8 transition. 
> 
> Regardless of how well folks like the "empty EB jar" idea - I do think we should move forward quickly on the EB move/rework and make sure that the kernel folks have plenty of time to talk about this.
> 
> /Chuck
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"