Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Description

This document outlines describes how the University of Western Ontario's mSub has been was set up and organized. You can find our mSub at

...

To set up our trunk, we first created a "trunk" directory in the mSub, then copied in the contents of https://source.sakaiproject.org/svn/sakai/branches/sakai-2.8.x/, on which our trunk was based (we could have also based it on a tag instead). Now it would look like this:

...

To turn this from a vanilla Sakai branch into the OWL trunk, we first had to modify the .externals file. We'll go into the details of the modifications later on, but for now we'll just outline the process:1.

  1. Checkout the trunk (svn co https://source.sakaiproject.org/svn/msub/uwo.ca/owl/trunk trunk)

...

  1. Edit the .externals file

...

  1. Commit the changes (svn commit .externals -m "modifying .externals")

...

  1. Update the svn:externals property (svn propset svn:externals -F .externals .)
  2. Commit the property change (svn commit . -m "updating svn:externals")

At this point you could run svn update and it would pull down all the code for the various tools in your Sakai implementation.

...

These tools might be custom versions of existing Sakai tools (ie. site-manage), or they might be brand new tools (ie. newTool1). For the site-manage tool, we copied the 2.8.x branch of the tool into our site-manage/trunk, checked it out, and committed our changes back. For newTool1, we imported code we had written from scratch into newTool1/trunk.

You've probably guessed by now that our modifications to .externals involve pointing some of the references to our custom tools. Here's how this looks:

...

Now that the pom.xml is correct, we can build the trunk:1.

  1. Pull down the tool sources if you don't have them yet (svn update or svn co)

...

  1. cd master

...

  1. mvn clean install

...

  1. cd ..

...

  1. mvn clean install

Full structure

Here is how the full mSub structure might look once we have some tags:

  • .../svn/msub/uwo.ca
    • /owl
      • /trunk
      • /branches
      • /tags
        • /2.8.x-owl1
        • /2.8.x-owl2
    • /site-manage
      • /trunk
      • /branches
      • /tags
        • /2.8.x-owl1
    • /newTool1
      • /trunk
      • /branches
      • /tags
        • /1.0

Working with the code

Whenever we get down to modifying code, we are always working at the tool level in our mSub, either in the tool trunk or in a branch. We checkout the relevant tool from our mSub, make changes, and commit back. The code for any tools that we haven't modified or created remains outside of our mSub. If we need to make modifications to an existing Sakai tool we haven't touched before, we pull a copy into our mSub.

Tagging releases

We like to tag our releases before they go into production. This is easily managed by tagging individual tools and then referencing those tags in the .external of the overall OWL tag. For example, .../msub/uwo.ca/owl/tags/2.8.x-owl1/.external might look something like this:

Code Block

access https://source.sakaiproject.org/svn/access/branches/sakai-2.8.x
alias https://source.sakaiproject.org/svn/alias/branches/sakai-2.8.x
...
roster https://source.sakaiproject.org/svn/roster/branches/sakai-2.8.x
rwiki https://source.sakaiproject.org/svn/rwiki/branches/sakai-2.8.x
sections https://source.sakaiproject.org/svn/sections/branches/sakai-2.8.x
site https://source.sakaiproject.org/svn/site/branches/sakai-2.8.x
#site-manage https://source.sakaiproject.org/svn/site-manage/branches/sakai-2.8.x
syllabus https://source.sakaiproject.org/svn/syllabus/branches/sakai-2.8.x
...

site-manage https://source.sakaiproject.org/svn/msub/uwo.ca/site-manage/tags/2.8.x-owl1
newTool1 https://source.sakaiproject.org/svn/msub/uwo.ca/newTool1/tags/1.0