This page last changed on May 31, 2006 by tcarlson.

Intro

There's a new source layout, hoping to cover most of what you need here.

The rationale for moving things about was to remove cyclic dependencies... modules that depend on each other. You generally want to avoid this, because it makes bootstrapping from source hard. Which modules should be built first?

When there are no cyclic dependencies, you get a dependency graph with no "back edges". Such a graph can be easily managed with a standard depth-first graph traversal algorithm. This is exactly what the Maven Reactor does.

At the top level of the build, note the maven.xml:

<project default="multiproject:install-snapshot"/>

One line simply tells maven that there are multiple projects that need to be built here. This file is inherited all the way down until overriden by a child project. In conjunction with this is the build.properties:

# ... many lines deleted
maven.multiproject.includes=*/project.xml,providers/*/project.xml,mule-extras/*/project.xml
# these are explained below
maven.repo.central = dist.codehaus.org
maven.repo.central.directory = /dist

This is telling the multiproject plugin that any project at the root level should be built, as well as all projects in providers and mule-extras folders. We only need to do this if there are projects that are not at the root level.

The goal of the current layout is that you can descend into any directory and issue a build from there in Maven. But the build isn't perfect yet, and if you find a problem doing that, it's probably a bug. Please report it in Jira.

Checking Out

See the Subversion guide for Mule that explains everything you need to know about checking out Mule from the source repository.

Build Targets

Here are some build targets that are good to know:

  • From the top level, just typing maven will build the entire Mule train.
  • As mentioned, typing maven from any child directory should build that directory and all it's children.
  • When you want to push jars out to Ibiblio, all you have to do is use the multiproject:deploy-snapshotgoal. It creates timestamped versions of the jars, uploads them to the central repository, and moves the symlink to the latest. We'll go over that below.

Artifacts

The default goal of the build now is to create SNAPSHOT artifacts. Previously, these were known as 1.0-SNAPSHOT. The difference is that if you have users that depend on 1.0-SNAPSHOTand you start working on 1.1, they will be left behind as the version changes. This is either a bad or good thing depending on your point of view, but here's another reason this is important. When using the built-in SNAPSHOT tools in Maven, you can end up with stale artifacts if you don't strictly stay on one or the other side of the version numbering fence. So all of the internal dependencies have been changed from pom.currentVersion to SNAPSHOT, and all of the targets now default to SNAPSHOT.

Deploying to Ibiblio

Codehaus has an arrangement whereby build artifacts can be uploaded to the central Maven repository. What this means is your projects can simply reference the dependencies and without additional configuration, the correct dependency jars will be downloaded automatically for you. This is managed by the artifact:deploy-snapshot goal and some properties.

The first setting you need is your repository username. If you are lucky enough to have the same username everywhere, you can create a file called build.properties in your home directory that looks like this:

maven.username=topping
maven.site.deploy.method=ssh

In conjunction with a properly configured RSA key for your SSH, Maven can automatically log into the central repository and upload the artifacts to the correct location. The locations of these directories are specified above, in the project.properties.

Importing the project into your IDE

IDEA

Typing maven idea:multiproject at the top level will create an IDEA project module with a full set of interdependent .iml files, each of those containing all the correct module references. This is extremely handy if you are an IDEA user.

Suggestion by Hardy Henneberg:

  1. Run maven -Dmaven.test.skip=true from Mule root
  2. Run maven idea:multiproject from Mule root
  3. Exclude source of mule-jbi-provider and mule-tools-config-graph
    in Idea
  4. Idea:build:'rebuild project' - builds all projects without errors

Eclipse

Typing maven eclipse at the top level will generate the .classpath and .project files for each sub-project. You can then import them into your workspace ("Import / Existing Projects into Workspace").

There does not seem to be a good way to import the entire Mule project into Eclipse using Maven 1.x

A workaround for this is to import the specific sub-project you want to work on and optionally its dependencies as follows.

If you want to work on, for example, the HTTP Provider, go to $MULE_HOME/providers/http and from there type maven eclipse (a standard maven goal). This will generate the .classpath and .project files so you can import it into Eclipse ("Import/Existing Projects into Workspace")

The problem is that if this sub-project has dependencies on other sub-projects, you either have to import those sub-projects into Eclipse also or temporarily remove the following property from those dependencies in the project.xml file:

<properties>
   <eclipse.dependency>true</eclipse.dependency>
</properties>

Hopefully importing the entire project will become much simpler with Maven 2.0!

Netbeans (using Mevenide)

It's currently quite easy to load the project into Netbeans using Mevenide2 for Netbeans. Just click the "Open project" toolbar action and navigate to the Mule root project directory. It allows you to open all of Mule at once or on a per project basis. Building inividual projects also works, a multiproject build doesn't yet (due to a Maven embedder bug).

Document generated by Confluence on Oct 03, 2006 09:23