[sakai-core-team] Fwd: [Building Sakai] Java 8

[Charles Severance]

On Feb 12, 2015, at 3:20 PM, Matthew Jones <matthew at longsight.com> wrote:

> Yeah, I agree that we can't just assume that these projects are only used by Sakai. They don't have any explicit dependencies on Sakai, so while I'd be okay with them living in a sakaiproject space as a separate project, not in the sakaiproject/sakai unless they were specific to Sakai. Something that *should* be in sakaiproject/sakai that isn't would be something like SakaiRSF (https://github.com/rsf/SakaiRSF) since that's an RSF piece that has no use outside of Sakai, but RSF in general would stay separate.


>> On Thu, Feb 12, 2015 at 12:06 PM, Kirschner, Beth <bkirschn at umich.edu> wrote:
>> I believe I have Sakai building & running with Java 8 -- the only outstanding issue is reflectutils. I've attached a patch to Aaron's google svn repo, and also sent him an email to his gmail address, but haven't heard anything back. I wonder if we should move this dependency into github? 
>> 
>> Thoughts?
>> - Beth


Matt - 

I was answering a *very specific question*.   If Aaron has stopped maintaining reflectutils - and so to get our patch in, we are forced to fork it to perhaps bkirschn/reflectutils, then we might just as well fork it right into Sakai and forget about the original repo.  While other projects "might" use it - if the repo is not going to be maintained - it is dead.  We do not need to worry about the effect on those "other adopters" - we need to worry about our use of the code and the simple fact that we depend heavily on this code and are likely the single largest user of the code and that probably all the other users of the code are some legacy thing deep inside Unicon that will never be updated.

If the patch gets applied and a release gets made - then the repo is not dead and I withdraw my suggestion.  My suggestion only triggers when the original repo is dead.

A middle ground might be to for it to sakai/reflectutils.  But that would be silly too - as it would mean that we would need to release our little reflectutils and then release Sakai based on that release.   Just simplify it all - fork it and put it in our repo and tag/branch our version with our own tagging scheme.

We depend heavily on these bits of code and it is *highly unlikely* that we could switch to anything else without breaking upwards compatibility with who knows how many bits that have now hard coded to the exact conventions of /direct and entitybroker.

When you are the only real customer for something that you depend heavily on - there is little value in maintaining the sham of "independence".

I understand that I won't win this argument - I just bring it back from time to time in hopes of removing dependencies on code that is effectively dead-end.

/Chuck

P.S. Rhetorical question: What happens if Aaron deletes his repo because he ran out of space on github?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150212/be92cc1c/attachment.html