Sakai’s master branch (destined to be Sakai 22) has now switched to Java 11 - I had to upgrade all the ways I build, develop, and test Sakai. I am not expert enough to figure some of this stuff out so I just ask Matt and Earle enough questions and then put their answers into shell scripts or README files so I don’t forget their advice. This blog post summarizes how I did it so I don’t forget it :)
Here is the text from that blog post - as always - comments are welcome.
Since Sakai has moved to Java 11 for the Sakai 22 and later releases,
we will need to update our developer environments. I also made the
following changes.
- Use the org.mariadb database connector and
Hibernate dialect (even if I am using MySQL 5.7). The connector is free
and automatically deployed by Sakai so there is no extra fuss
downloading the com.mysql connector and hand-installing it in Tomcat.
- Upgrade Maven to 3.8.1 or later
- On my fresh-install Linux environments I am switching to MariaDB as
my dev database server. If I have an existing MySQL (i.e. MAMP on Mac
or Aurora on AWS) I will just keep using it but switch to the MariaDB
connector.
I have setup and tested four different environments in the post-JDK11 environment:
- Matt Jones’ docker-build
solution. This is very cool – especially for Windows. Matt mounts
folders from your computer’s file system into his (build/database/sakai)
docker containers so you can edit files outside of the docker
containers and then build / run all inside docker containers with a zero
footprint install on your computer other than docker itself. Also your
database persists even when you have no docker containers running. The container and mounted files slows this down a bit – but
if you have a super fast Windows or modern MacBook box with a lot of
memory and SSD, it is plenty quick.
- My MacBook running natively installed Java, Tomcat, and MAMP using my sakai-scripts
code. For Mac development it is faster than Matt’s docker solution
especially for my circa-2013 MacBooks that I refuse to upgrade.
- A simple self contained Ubuntu image running under docker using my sakai-scripts
code. I use this to make sure I can quickly test my scripts or Sakai’s
build under ubuntu without spinning up an EC2 node or DigitalOcean
Box. This is different from Matt’s docker approach because everything
(including the MariaDB server and data) is in the docker – it is nice
for quick tests because it is a zero-install other than docker on your
main computer.
- An ubuntu server running on Digital Ocean / EC2 using my sakai-scripts code like https://dev1.sakaicloud.com
If you want to figure out things like shell settings or other
configuration to adapt your own setup, you can take a look at some of
the files in my sakai-scripts repo. If you used these scripts before,
there was a complex step of getting all the environment variables set in
your profile (mac or linux). Now each script sets its environment
variable and does its thing – much better and easier to fix / upgrade
when things change a little.
You can examine these scripts and extract bits to use in your environment.
- Start with the README.md it
contains the overall outline of manual and automated steps. This shows
how to setup (a) a MackBook, (b) ubuntu in a stand-alone docker, and
(c) ubuntu on a stand-alone server.
- Take a look at ubuntu.sh to see what prerequisites are needed on ubuntu. Because I use sdman
the installs are much simpler – thanks Matt and Earl for teaching us
about this. Using sdman also allows you to switch back to JDK-8 if you
need to. It is the logical equivalent of Python virtual environments.
- Take a look at qmv.sh
to see things like needed environment variables to make maven work.
Without these maven will run out of memory whilst building.
- Take a look at start.sh
to see the relatively complex set of environment variables needed to
set up Java to run Sakai. These variables are adapted from the Matt /
Earle recommendations. Matt designed these to be tweak able and there
are some examples of things like setting up a debugger if you want that.
I hope you find this helpful. I would also like to explore moving
these scripts and Matt’s docker stuff into the core repository in a
“dev” folder. It is kind of silly to have these in hard-to-find
locations in contrib and my repo.