/
Maven2 Implementation for Platform

Maven2 Implementation for Platform

Owned by Former user (Deleted)
Last updated: Sept 21, 2007 by Former user (Deleted)Version comment

Community home page for the Mavenization (if that is a word) of the BI Platform

Introduction

 The goal of the Maven project is to convert the Pentaho platform to use the Maven2 build process. The current build process uses Apache Ant, and our initial intent was to create a parallel Apache Maven build process that would live alongside the current build. For more information, see the Maven forum:

Structure

Pentaho is made up of a number of different source trees, a lot of which would have to be mavenized to able to build the Pentaho BI Suite. These source trees are:

The links will take you to current location of the subversion branches that are being worked on. The initial effort is centered around two of the source trees: pentaho and pentaho-metadata.

Building with Maven


Maven version

We have been using maven version 2.0.5 to build with. It may work with other versions, but this has not been tested.


In each of the projects, there is a directory named "maven" that contains the maven modules. For example, for the pentaho project you have:

pentaho
	-maven
		-pentaho-api
		-pentaho-core
		-pentaho-data
		.. (other modules)

To compile all of the modules from the top level, execute the following on the command line from the maven directory:

mvn clean install


Dependencies

Not all of the dependencies that pentaho depends on exist in maven repositories. To handle this, there is a install_rescued_jars.sh script in the maven directory for each project  that will install jars from the rescued_jars folder into your local maven repository. You only need to run this script once to put the jars into locations that the maven modules expect.

To build without tests, you would simply run 

mvn clean install -Dmaven.test.skip

To import these projects into eclipse you would first need to execute

mvn eclipse:eclipse

This will generate the .project, .classpath, and .settings files eclipse needs.

To see a collection of reports that maven  will generate for you about your project, execute

mvn site

Site problems

If you encounter problems with this command, try using the -U flag. This will update the versions of plugins that maven uses. For example:

mvn -U site


Pentaho

Project dependencies

Pentaho depends on the following other projects to build

  • pentaho-preconfiguredinstall
  • pentaho-solutions
  • pentaho-data
  • pentaho-commons

The pentaho source trees produces a number of different artifacts, as described in the current Ant build.xml and deployment_build.xml. (There is also a dev_build.xml.) With a maven build, the most common structure is to have one maven module per artifact to be generated.

The complication with this particular project involve the circular dependencies between the different jars to be created (as the community has mentioned before).

 This diagram captures these relationships:







 Arrows on both ends of a line signify the circular relationship between two modules. (In addition, there are some jars not pictured, such as pentaho-test and pentaho-i18n.) Currently, the mavenization has progressed to the point that these circular dependencies have been removed. This required moving classes from the pentaho/server/src directory into the various maven modules, and in many cases entailed moving those classes into different modules than what the Ant build originally stated. Two new modules were created (pentaho-api and pentaho-quartz-plugin) to break further circular relationships.


In addition to this, some code had to be refactored to break the circular dependencies, including making new classes. These refactorings are all accompanied by tests in the various modules where the code was changed.
Currently, the structure now looks like this:
 




Note, this is with redundant relationships removed. For example, pentaho-util depends on pentaho-api and pentaho-messages. Instead of needing to depend explicitly on both of these, pentaho-util can now just depend on pentaho-api, and pentaho-api will bring along pentaho-messages as a dependency.


Not shown is a relationship between pentaho and pentaho-metadata, pentaho-preconfiguredinstall, pentaho-solutions, and pentaho-data. Pentaho depends on pentaho-metadata for a number of classes, but it currently depends on a jar file to get these from. Once pentaho-metadata and pentaho are complete, pentaho should depend on the maven module for pentaho-metadata. Pentaho depends on the other projects for non-Java code files, and they must be built in order to compile this maven project.



Pentaho-metadata

Project dependencies

 
This maven module depends on code from the pentaho source tree. In particular, it is the pentaho-publisher jar that is required to build pentaho-metadata, so you will have to build that before attempting to compile pentaho-metadata. 


We successfully mavenized the pentaho-metadata project.

This project builds a number of different artifacts, including a zip file with a startup script, javadoc, and source zips and a jar. These artifacts are generated automatically by doing a complete build:

mvn clean install

Using the commands above this module compiles the pentaho-meta jar, runs the unit tests, and creates the following zips:

  • pentaho-meta-1.6-SNAPSHOT.jar [approx. 1.5MB - pentaho-meta lib]
  • pentaho-meta-1.6-SNAPSHOT.zip [approx. 57.6MB - all libs/docs/scripts to run the MetaEditor suite]
  • pentaho-meta-1.6-SNAPSHOT-javadoc.zip [approx. 1.6MB]
  • pentaho-meta-1.6-SNAPSHOT-src.zip [approx. 1.0MB]

In addition, we were able to unzip and successfully execute the MetaEditor.bat startup script.

All unit tests pass:

mvn test

as well as within eclipse:

Pentaho-preconfiguredinstall 

Pentaho-data 

Pentaho-solutions 

Pentaho-commons

 This module will contain multiple modules, much in the same way that the Pentaho project does. Currently, there is a top level pom and the pentaho-reportwizard-core module.

How to Help

Please reply to the Working Group Thread. A good step for anyone wishing to help out would be to check out the source and try to build from the maven modules. This can help root out problems in the build, and can only make it better.

  Next Steps

 The pentaho-commons project has not been touched as of yet, and would be the next step for anyone wishing to assist in this effort.