Gradebook2 Developer Best Practices

Owned by Former user (Deleted)
Last updated: Mar 19, 2010Version comment
2 min read

This is a quick reference document for developer best practices when working on the
Gradebook2 project.

1. Versioning


We made a decision fairly early on in the development of Gradebook2 that it should be
versioned independently of Sakai releases. The basic thinking is that functionality within
the GB2 codebase is going to change at a different rate than the Sakai APIs themselves, and
that institutions that deploy GB2 will need to track their GB2 version independently, so for
example if an institution upgrades from Sakai 2.5.5 to 2.6.2, they can (in theory)
stick with version 1.2.0 of GB2. Perhaps more importantly, if an institution is committed
to staying at a particular Sakai release for some period, it will not be forced
to upgrade the overall release simply to get new functionality included in a later
version of the GB2 code.
One major advantage of this is also that GB2 does not have to maintain maintenance branches.
Our recommendation is that in cases where a blocker bug exists in a particular version
of GB2, all institutions should upgrade to a version where that bug has been fixed.
The major disadvantage is that we have to make the GB2 code build
against different versions of Sakai. Our current strategy for this is to make use of
maven's profile functionality and to pass in different -P values for each build, for example
-Psakai2.6 to build against a 2.6 Sakai instance.
This still requires that the root pom.xml file be modified to change it's version (from 2.8-SNAPSHOT
to 2.6.3, for example), which is unfortunate. We would like to eliminate that step in the future.

2. Organization of the Project

The following maven modules currently exist in the project:

  • model
  • api
  • shared
  • server
  • client
  • war

At the moment, everything gets deployed in "war". So api and model are both shared/lib jars. The module called
"shared" is a simple dependency jar that "server" and "client" require. The module called "server" is a simple
dependency jar that gets placed in war/WEB-INF/lib and "client", when it's built, simply overwrites the directory
war/gradebook, and the jar it produces never goes into tomcat, since it's purpose is only to build the GWT compiled javascript code.

In addition to these directories, there are also the following ones that are only used in development mode, and
which are not included in the maven build:

  • dev
  • unit-test