Build profiles and Sakai dependencies

>In the development of Profile2 I have come to the point where I need the one version of Profile2 to build in all 4 of the current flavours of Sakai: 2.4, 2.5, 2.6 and trunk.

Impossible you say, 2.6 and beyond uses the Kernel whereas 2.5 and lower uses the old set of dependencies!
One would think this task could only be accomplished by making 4 releases tailored to each version. That would be a maintenance nightmare.
The other way would be cutting a release and saying any new developments will only work in the latest versions of Sakai (2.6 and trunk/2.7); i.e. dropping support for 2.4 and potentially 2.5. Being a branch manager for both of those versions, I didn’t like that option either.
The solution I have in place now employs an oft-underused feature in the Sakai world, Maven build profiles. In a nutshell, I have two build profiles that wrap my Sakai dependencies, one for the older style dependencies used in Sakai 2.5, and one for the Kernel dependencies used in 2.6 and beyond. Any other dependencies go in a normal dependencies block.
Here’s an example:
<dependencies>
<!-- EXTERNAL DEPENDENCIES -->
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket</artifactId>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-extensions</artifactId>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-spring</artifactId>
</dependency>

<!-- GENERIC SAKAI DEPENDENCIES -->
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-common-edu-person-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-common-manager-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-common-type-api</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>

<profiles>
<profile>
<id>pre-K1</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<!-- SAKAI 2.5.X SPECIFIC DEPENDENCIES -->
<dependencies>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-tool-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-user-api</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>sakai-authz-api</artifactId>
<scope>provided</scope>
</dependency>
....
</dependencies>
</profile>
<profile>
<id>K1</id>
<!-- SAKAI 2.6+ SPECIFIC DEPENDENCIES -->
<dependencies>
<dependency>
<groupId>org.sakaiproject.kernel</groupId>
<artifactId>sakai-kernel-api</artifactId>
</dependency>
<dependency>
<groupId>org.sakaiproject.kernel</groupId>
<artifactId>sakai-component-manager</artifactId>
</dependency>
...
</dependencies>
</profile>
</profiles>
Something like that would go in your POM’s wherever you had to bind to any Sakai specific core dependencies.
Since I am building for 2.5 mainly, I have set the activeByDefault flag to true for that profile, so building on 2.5 is unaffected. To build on 2.6/trunk you just add -P K1 to your mvn command to choose the K1 build profile, like so:
mvn clean install sakai:deploy -P K1
Maven will use the right profile block to find it’s dependencies and ignore the other one. And thats it, I’ve got one tool building in both 2.5 and 2.6/trunk.
Ideally, I’d like for the activation of these profiles to be available via reading which version of Sakai we are building against.
Something like:
<profiles>
<profile>
<id>pre-K1</id>
<activation>
<property>
<name>sakai.version</name>
<value>[2.5.0,2.5.4)</value>
</property>
</activation>
<dependencies />
</profile>
<profile>
<id>K1</id>
<activation>
<property>
<name>sakai.version</name>
<value>[2.6.0,2.7)</value>
</property>
</activation>
<dependencies />
</profile>
</profiles>
But unfortunately that is not possible as Maven only reads properties explicitly set on the commandline to activate profiles via -Dproperty=value. Since it’s less work to just specify which profile we want via -P K1, that is the option I’ve chosen for now.
Finally, the 2.4 support is achieved via backporting the pom.xml to project.xml for Maven1 to use. See my last post about backporting Maven2 to Maven1.
Advertisements

20 thoughts on “Build profiles and Sakai dependencies

  1. @seriouslyuguys that is one thing I’d be very interested in because I want to get rid of the -P switch, but what is the difference between a pre-K1 Sakai and a K1 Sakai in terms of file structure? They both have the ../tool/pom.xml. If there was a definite file that only exists in the K1 versions I could point it to look for that.

  2. I guess I could check for the existence of the ../authz/authz-api/api/pom.xmlThat is present in pre-K1 and not present in K1 AND it works for both full builds and cafe builds as it’s an essential component.What do you think?

  3. Very nice. I think it might be nice to have a different maven classifier for the different artifacts, as otherwise what’s in your local maven repository is going to change dependent on what profile you last built the tool with.It doesn’t matter too much for tools but if there’s an API or if you start publishing the artifacts in a public repo it could get a little messy.

  4. @Thick Sliced not quite sure I follow. Profile2 builds under these profiles just fine, it pulls in it’s dependencies depending on what profile you are using. I don’t think that getting more artifacts in your local repo is a bad thing, they are all discrete units that are explicitly defined and retrieved when needed.If it was going into a public repo, I would cut several releases as yes, it would need to bind to specific versions of the Sakai dependencies :)But for local building, this is working great.

  5. Steve, when you specify dependencies in the profile, do you have to do anything to the poms in the source tree to make it work? i.e., can you do this with a plain vanilla Sakai checkout?

  6. Hi Zach,I haven’t done anything with the Sakai POMS’s to make this work, my dependencies with their versions are in a dependencyManagement block in the base pom for my app and then I build as normal against a vanilla Sakai. Is that what you mean?cheers.

  7. I guess another way to put my question is, do the profiles get selected only when you invoke mvn from inside your app, or do they also activate for all modules whenever you do a top-level full build?

  8. Right, in that case then no. Only works when building by itself and not bundled inside the main pom. I mainly did this for portability. If it was to be embedded in a specific version of Sakai, I’d adjust the poms to be specific to that version only.

  9. Steve,
    I am learning sakai portal and sakai.I am not able to build sakai with eclipse after executing following steps:
    1) i have execute mvn eclipse:eclipse in sakai main directory
    2) then trying to import sakai project in eclipse through import existing maven project.
    3) i checked importing of sakai taking memory consumption of around 1.5 GB.

    Please help me out to build sakai from eclipse

    Thanks and regards
    ~Suri

  10. Hi,
    Unless you have a need to build Sakai in Eclipse, don't. I don't have the whole source in Eclipse, I only import the modules I need to work on. I have the exact same issue you have when importing the whole source – its just too large to import in one go.

    So if you are just learning, just build via 'mvn clean install sakai:deploy -Dmaven.tomcat.home=/path/to/tomcat' on the command line

  11. Steve,
    Thanks for kind consideration.

    Can you please help me out to understand the Sakai-kernal?
    How it works? Which modules i need to understand kernal?

    Thanks and regards
    ~Suri

  12. The kernel is a set of the core Sakai API's and services, things like getting info about a site, getting info about users, etc. You can checkout and build the kernel separately if you wish, then build the Javadocs for it, via maven as well.For more info, check out the sakai-dev mailing list at collab.sakaiproject.org

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