[Building Sakai] Sakai tool installer

Matthew Jones jonespm at umich.edu
Mon Mar 22 16:22:28 PDT 2010


I'd forgotten about this project, but I don't think it's really what we were
thinking about. An interesting line in the description is "It isn't actualy
an installer at all, as we'll see shortly." :)

What we have in Sakaiworld are 2 groups of people.

*1)* Those that are using the tagged official binary from the website (or a
tagged source release) and would like to be able to make minor
customizations to it without having to have a developer to rebuild anything
from source. Things like:
  - Drop in a "cool contrib tool" they read about on the a list or heard
about at the conference
    that is well maintained
  - Apply a patch that someone attached to a SAK
  - Customize the skin for their institution
  - Easily configure some properties (another conference topic I have
planned)

*2)* Those that download the source, possibly have a locally modified
externals to use different versions, likely have at least one developer on
staff. Things like:
  - Drop in a tool that may only exist in source or that was developed
locally
  - Apply a patch they created locally or one from svn merges with conflicts
resolved
  - Everything else in group (1)

*Group (1)* will need it to be easy. Either a shell script in the build
directory where it will go and
  - download pre-compiled binaries of the tool they want, or a website where
they can download a zip file that is specific to their version (2.7.1)
  - uncompress the zip that right into their tomcat.

No compilation should be expected or required. These would likely be done
using the current indie releases that use the release plugin. I'm not sure
how if it could work in 2.6 though or only 2.7+.

*Group (2)* could be harder, but the script would need to:
  - svn checkout a tool from sakaiproject at a specific known working
revision (one that is known to work with the version of sakai they is being
run)
  - Apply whatever patches might be needed
  - Compile it and dependencies
  - Produce an archive that someone can uncompress right into their tomcat
directory.
  - Optionally allow some of these steps to be overridden for even more
advanced mode (user defined versions, user defined patches)

If you've installed Gradebook2 into 2.6.x you have an idea of where I'm
coming from for Group 2. That tool nearly automatically will build for me,
which is nice, but it's taken some time.
---------------------------------------------------------------------
On a side note, I do have concerns about us using minor versions on the apis
(especially kernel) and seems like it might make this deployment harder.
This might not be an issue, but I never see the result of this locally
because I'm paranoid and all of the local Michigan builds are built from
source using a custom version kernel and all poms in every tool re-versioned
every time we do a build for production. I'm *expecting* to do this for 2.7
and indie tools.

For example for basic LTI we have in the war:

Basiclti 1.1.0-rc01 kernel-util-1.1.1
http://source.sakaiproject.org/maven2/org/sakaiproject/basiclti/basiclti-pack/1.1.0-rc01/
   235139  03-22-10 12:39   WEB-INF/lib/sakai-kernel-util-1.1.1.jar
But in
Basiclti 1.0.0-b01 is is kernel 1.1.0-util-beta04
http://source.sakaiproject.org/maven2/org/sakaiproject/basiclti/basiclti-pack/
   236038  01-21-10 00:31   WEB-INF/lib/sakai-kernel-util-1.1.0-beta04.jar

Is this going to cause a problem if basic LTI isn't updated every kernel
version, and someone doesn't pick up the right one to match their system?
Say when it gets to 1.1.5? How about when it gets to 1.2? I guess a minor
jump would be a problem but it *seems* like minors might be too. I'd feel
better if these artifacts were just something-1.1.jar and something-1.0.jar
with no minors for the *apis*. The impls/etc would have the minors.

Maybe my concern won't matter because these are guaranteed to not change and
it will all just work out okay? :) I'd brought this up a few months ago and
don't remember getting any reassuring response.

-Matthew

On Mon, Mar 22, 2010 at 6:26 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> There is a project in contrib that is along similar lines:
>
> Contrib: Sakai Installer
> http://confluence.sakaiproject.org/display/SAKINST/Home
>
> ... an installer that does two things: it check for and installs a Java JRE
> and it starts a demo version of Sakai that is placed on the stick alongside
> the installer. Once started, Sakai runs entirely from the stick. The
> database is HSQLDB, which is stored on the stick itself. That means you can
> start Sakai from the stick, create users, sites, resources etc and than plug
> the stick into a different computer and find Sakai in the exact state that
> you left it in.
>
> The source for the Sakai installer is in contrib:
> https://source.sakaiproject.org/contrib//sakai-installer/
>
> cheers,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100322/d977c7dc/attachment.html 


More information about the sakai-dev mailing list