Build profiles and Sakai dependencies, revisited and resolved

A few weeks ago I wrote an article about how I was investigating using build profiles in Maven POMs, for building Sakai against either the older style dependencies used in 2.4.x/2.5.x, or the newer kernel dependencies used in 2.6.x/trunk. Because the dependencies are completely different, if you need to build the same tool in either of these, you had to manually change the dependencies in every POM.

That article proposed a solution of adding -P <profile> to the Maven build command. This worked great, but I wanted it to be even more automatic. It was by chance that I noticed a commit come through from Nuno Fernandes who picked up the idea of build profiles and was looking at using them in Site Stats.
We banged away a few emails and have finally come up with a solution to make it completely automatic!
How it works:
 
We needed to check for something that was always going to be present in a kernel based build, and never present in a 2.5.x based build, or vice versa. I tossed up the idea of checking for the the authz/authz-api/pom.xml since that is an integral part of Sakai, is present in 2.5.x, but has been moved to the kernel in 2.6.x+.
Nuno mentioned that he uses (and potentially other developers use as well) a different structure for contrib projects vs core Sakai projects, where the contrib projects are located outside the main Sakai code, and symlinked together via a ‘master’ link:
This was the key. Because Maven can follow symlinks, we can use the ‘master’ project as our launchpad. Enough guff, whats the solution!
 
Solution:
<profiles>
 <profile>
 <!-- Binds to Sakai Kernel K1 - for Sakai 2.6.0+ -->
   <id>K1</id>
   <activation>
     <file>
       <exists>../master/../kernel-deploy/pom.xml</exists>
     </file>
   </activation>
 </profile>
 <profile>
 <!-- Binds to Sakai pre Kernel K1 - for Sakai 2.4.x/2.5.x -->
   <id>pre-K1</id>
   <activation>
     <file>
       <missing>../master/../kernel-deploy/pom.xml</missing>
     </file>
   </activation>
 </profile>
</profiles>
Here we are still checking for the existence (or not) of a file, but with a path that is safe for both our cases, having contrib projects mixed with the main Sakai projects, and having them external and symlinked.
And with this approach, Maven can select the profile automatically without any extra flags!
Muchas gracias to Nuno for his work on this! Check out his post about the different layouts that this approach can cater for as well.
Advertisements

One thought on “Build profiles and Sakai dependencies, revisited and resolved

  1. >This works better if you have an exists tag for both fields. So for the pre-k1 you can have (HTML Tags not allowed)(exists)../master/../component/pom.xml\(/exists)instead of the missing.The problem with having a missing/exists is that if you're trying to build a K1 in a subdirectory where the kernel-deploy doesn't exist with a profile activation (mvn -P K1) then the pre-k1 is missing and also tries to activate so it will never compile. Having them both set to exist makes it so it will only pick it up when needed, and component doesn't exist in K1.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s