Will Gorman’s Blog

Our build team has been busy over the past couple of months converting our 2.0 line of open source projects, including our BI Platform and Metadata, over to Ivy and a common Ant build.

In converting to Ivy, we’ve learned a lot about our actual dependencies.  Before, a developer would simply check in a Jar file into one of our projects.  Months later, we wouldn’t know exactly which version or from where the Jar originated.  Ivy forces us to be more explicit with project dependencies, and allows us to develop reports on exactly which projects are using what jars.

Our developers mostly use Eclipse for development, so we’ve been using IvyDE to manage our Ivy dependencies.  IvyDE works well, but we ran into a limitation when we parameterized some of our internal dependency revisions in our Ivy files.  Luckily IvyDE is open source and was very easy to add functionality to.  We’ve since submitted our code back to IvyDE for others to use when parameterizing ivy files.

This week I split Pentaho Metadata and its Editor into two separate projects.  Before this split, we built a single metadata jar file that contained both UI code and core library code.  With this split, we now have a separate jar for the core library, which will be deployed to the Pentaho BI Server and other dependent projects.  The original jar file was close to 1.5MB, now the library only jar is around 374K.

This split also resolves a circular project dependency that was created when we separated out the Metadata Query Language (MQL) Editor.  In order to properly build Pentaho Metadata, one would have to first build the main project, deploy the jar to the MQL Editor, and then check in the new MQL Editor jar back into the main Metadata project and build again.  Now we no longer have this circular dependency.  First the core library is built, followed by the MQL Editor, and then finally the Metadata Editor is built.

You can access the latest Pentaho Metadata Library, Pentaho Metadata Editor, and Pentaho MQL Editor via SVN following these three links:

svn://source.pentaho.org/svnroot/pentaho-metadata/trunk
svn://source.pentaho.org/svnroot/pentaho-commons/trunk/pentaho-mql-editor
svn://source.pentaho.org/svnroot/pentaho-metadata-editor/trunk

Enjoy!

Will

Aaron Phillips, one of our newest Senior Engineers at Pentaho, introduced the team to Hudson this week. Hudson’s main purpose is to build and test software projects continuously.  It’s easy to install, and from the web UI it’s possible to configure new projects very easily.  Aaron demonstrated this by quickly setting up Hudson on a virtual machine, and then showing off its capabilities by building Pentaho Metadata, showing successful JUnit test percentages and code coverage reports from Cobertura.

If you have a need to build a Java project continuously, and want to monitor unit test and code coverage changes over time, you should definitely take a look at Hudson.  I’m very impressed.