Profile2 1.3 series released

I am very pleased to announce the release of Profile2 1.3.

The 1.3 series represents dozens of refinements, enhancements and fixes over the 1.2 series. Notable features in 1.3 are a full integration with the Roster, a Help bundle, more language translations and more configuration options.

There are currently two tagged releases of the 1.3 series. 1.3.0 is the full 1.3 release. 1.3.1 is identical, however has the TinyUrlService methods removed, to make it ready for inclusion in upcoming Sakai releases. See this post for whats happening with TinyUrlService going forward.

To get Profile2, check out the install guide on Confluence.

For the full list of issues addressed, see the changelog in the Sakai JIRA.

And, as previously announced, v1.3.1 will be bundled with the upcoming Sakai 2.7.0 release!

A special thanks to everyone that has contributed to making this release a reality:

  • Mark Breuker
  • Nuno Fernandes
  • Adrian Fish
  • Mike Ozornin
  • Yuanhua Qu
  • Daniel Robinson
  • Anthony Whyte
  • and everyone that provided feedback over the past year of development!

TinyUrlService 1.0 released

I am very pleased to announce the 1.0 release of TinyUrlService.

TinyUrlService is a simple URL shortening service for Sakai and was initially created as a support project for Profile2 to allow sending shorter links in emails. For instance, you could turn a URL like this:


into this:



However, this will also be the final release of TinyUrlService in it’s current form. This is to make way for the renaming of this service to RandomisedUrlService and the creation of a more pluggable interface.

In the works is a ShortenedUrlService which will be able to be configured by an institution to use any one of a number of different URL shortening mechanisms. RandomisedUrlService will be one implementation, but many others could be created and used instead, even hooking into external URL shortening services like
Stay tuned!

For more info on TinyUrlService, see my prior blog posts, the Jira space, the SVN space, or the Sakai Maven2 repository.

Eclipse Galileo and Sakai

When Eclipse Galileo (3.5) was released a while ago, I quickly upgraded to it to try it out, but found a number of incompatibilities with plugins I was using at the time. I rolled back to Ganymede (3.4) and have been using it ever since. However, I recently upgraded my machines to Snow Leopard and with that came the option of only one Java environment, 1.6. You can install Java 1.5, but it’s already past it’s end of life, so decided to move on. This is fine, since I’ve been building and running Sakai with Java 1.6 for over a year now.

Today I came up against a new issue though. The Sakai App Builder, which I’ve done some work on to make compatible with K1 builds, was refusing to start up:

java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM

I scratched my head for a while but then it clicked, Ganymede is 32 bit and Snow Leopard is 64 bit. I checked the Eclipse download pages and sure enough, Ganymede is only available in 32bit for OS X. Galileo however, is available in both 32 and 64 bit for OS X.

So I took the plunge and upgraded to Galileo 64 bit. First impressions, it looks nice. It’s based on Cocoa so a few little UI things have changed. Most noticeably in the Package Explorer view, the icons and text are a bit smaller so you can see more. This is great because Profile2 has 11 modules and expanding any of those soon eats up real estate.

I’m a bit of a traditionalist and prefer to do things like Subversion and Maven builds on the commandline (having multiple screens helps here), hence don’t use plugins like Subclipse or any Maven plugins so can’t really comment on their compatibility, although am interested to hear your experiences.

So far I haven’t found any abnormal behaviour with Galileo in regards to Sakai, but will report back if I do.

Here are my relevant JVM settings in


Setting up your own Maven repository

I’ve just setup a local Maven repository so that I can share libraries I develop with other developers on campus. It was really easy, all you need is a filesystem that you can SCP to, you don’t need to install anything on it. Here’s how:

1. In the POM of the project you want to put in a repo:

    <name>Enterprise Systems Maven Repository</name>    

You can also separate snapshot releases from point releases in two different repositories, by defining a snapshotRepository element as well as the repository element, same attributes as above.

2. Setup your username and password that will be writing to the repo:

2a. If you have not yet set a master password for Maven, you need to create one. If you have done this already, skip to 2c.

mvn --encrypt-master-password masterpasswordhere


2b. Create a file .m2/settings-security.xml with that password:


2c. Encrypt your password you are going to use for pushing to this repository:

mvn --encrypt-password hello


2d. In .m2/settings.xml add a server block with that password, and matching id for the repo:

<servers>  ....  
  </server>  ....

3. Build and deploy your project to the repo:

mvn clean install source:jar javadoc:jar deploy

After it builds you should see it uploading the artifacts.

4. Now, in the POM of another project, you can set up your new maven repo as a repository to search and pull artifacts from: