Mule : Working with the build (Maven 1.x)
This page last changed on May 31, 2006 by tcarlson.
IntroThere'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 OutSee the Subversion guide for Mule that explains everything you need to know about checking out Mule from the source repository. Build TargetsHere are some build targets that are good to know:
ArtifactsThe 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 IbiblioCodehaus 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 IDEIDEATyping 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.
EclipseTyping 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").
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 |