This is the first in series of two articles that will cover the binary deployment of tools in Sakai. In this article we will get your project ready, first by polishing the Maven POMs.
An issue in Sakai today is that there is no real standard for how the Maven coordinates of a project (artifactId, groupId) should be laid out. You can give your POMs any value, it will still build and everything will be fine. You might run into an issue if other people need to depend on your project though the main issue is how it’s arranged in the repositories.
A quick glance in your ~/.m2/repository directory and you’ll notice that most projects are under the org/sakaiproject umbrella, which is great, but from then on its a free-for all. Some project’s main POMs are appended with ‘-base’, some are not, some are prepended with ‘sakai-‘, others are not, and there is even a mix of the two approaches within projects.
It’s a bit of a hassle when you are trying to find a group of artifacts for a project and and delete them so you can rebuild properly, often you just end up deleting the whole org/sakaiproject directory and rebuilding the lot. It also causes issues if you import a Sakai project into Eclipse, you’ll get the project being called whatever the base-pom’s name is.
What this article will cover is how to setup your poms to give them more structure in the repository. We’ll actually be following the Maven standard.
First up, the groupId. Most POMs in Sakai currently have org.sakaiproject as the groupId. This is fine but will cause the repository layout to be spread out as in the image below:
What is suggested is to append your particular project name to the org.sakaiproject groupId to make it unique.
This will be consistent throughout the project’s POMs (ie the base POM, API, Impl, Pack, Tool and Util all have the same groupId), but different between projects, ie, SiteStats has:
This is the most important change you may need to make. You can even skip the next section if you like because its just a further refinement.
Next up is the artifactId. As recommended by Maven, the artifactId should be “the name that the project is known by”. In the case of the parent POM, this will be the name of the project, ie profile2 or sitestats or whatever your project is called. This is where a lot of projects prepend ‘sakai-‘ or append ‘-base’; this is unnecessary, the groupId already identifies that it’s a Sakai project.
For submodules in a project, the artifactId should simply be something like profile2-api or profile2-impl. These need to be unique amongst all submodules in this groupId so the -api and -impl appendages perform that purpose. Most projects are already setup this way so shouldn’t need much changed. Again, its unnecessary to prepend the ‘-sakai’ part but you can if you like.
Below is an extract from two POMs in Profile2, to illustrate some of these naming conventions discussed above:
The base POM:
The API submodule POM, showing its own artifactId as well as the parent:
Performing these small POM maintenance tasks will mean the repositories are arranged much better. Compare the following diagram with the first:
Note that all artifacts for a particular project are now grouped together, rather than being lumped in with every other project’s artifacts.
Note that you’ll need to be careful in changing the POMs if any other projects depend on your project as they will also need to have their POMs updated to point to your new layout.
Next up, creating an assembly module for your project so it can be deployed as a binary artifact automatically.