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

[Matthew Jones]

This is moved over to github as mentioned on the ticket. (
https://github.com/azeckoski/reflectutils) There is still some work to do.
Ideally the people mentioned below would do it but I can do it if you'd
rather.

1) Beth - Move the patch over as a pull request against this repository
2) Aaron - Merge the pull request after Beth submits it
3) Anyone on this list - Build and test out new snapshot version with JDK8
in a tool that uses reflect utils. I don't think it was able to compiled
with JDK8 and I feel like signup was causing problems running in JDK8.
4) Aaron - Release reflectutils 0.9.20 after verified
5) Matt - Update Sakai master to reference this new version

As far as the release step #4, I'd also be happy to do that and change it
over to sonatype if given access to this repository in github. That would
make more sense than forking it and releasing this fork.

Thanks!

On Thu, Feb 26, 2015 at 5:07 PM, Kirschner, Beth <bkirschn at umich.edu> wrote:

> I haven't seen any activity on this thread in a few weeks (though I'm
> catching up from a vacation and might have missed it) -- has there been any
> decision? I think moving forward with Steve's proposal makes the most
> practical sense.
>
> Thoughts?
> - Beth
>
> On Feb 12, 2015, at 5:13 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:
>
> > What about a sakai-libs repo under sakai org, much like contrib but a
> place where we hold libraries we use for stuff that isn't core, isn't
> contrib and isn't really Sakai. Like forks of other projects, sakai wicket,
> rsf, etc.
> >
> > On 13 Feb 2015 08:42, "AZ" <azeckoski at gmail.com> wrote:
> > Let's petition github to give me more space for free. That is the best
> option for sure (for me).
> >
> > --
> > Aaron Zeckoski - Lead Architect for Elsevier Education
> >
> > On Feb 12, 2015, at 16:26, Charles Severance <csev at umich.edu> wrote:
> >
> >>
> >> 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?
> >>
> >> _______________________________________________
> >> sakai-core-team mailing list
> >> sakai-core-team at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >
> > _______________________________________________
> > sakai-core-team mailing list
> > sakai-core-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
> >
> > _______________________________________________
> > sakai-core-team mailing list
> > sakai-core-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>
> _______________________________________________
> sakai-core-team mailing list
> sakai-core-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-core-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-core-team/attachments/20150304/b5ae9271/attachment.html