Mule : Working with the build (Maven 2.x)
This page last changed on Sep 28, 2006 by tcarlson.
Maven 2.xMaven 2.x has some pretty interesting and innovative concepts. Read all about it Documentation has not historically been one of Maven's strong points, but with the creation of Mergere this has been improving. If you are already familiar with Maven 1.x take a look at Information for Maven 1.0 Users Useful quick reference: ModulesThe Mule project is neatly organized into a hierarchy of sub-projects or "modules". Each module generally produces one artifact (usually a jar file). Modules are built by executing goals/targets such as "compile", "test", "install", etc. Executing a Maven goal for a module will also (by default) execute the goal for any modules below it in the hierarchy. This makes it easy to work with portions of the project at a time (providers, extras, tests, etc.) without having to rebuild the entire project. In fact, a single module (or group of modules) can be checked-out from source control, modified, and built on its own without even needing the rest of the project! GoalsCommon goals to execute for a module are: mvn clean - purges any built artifacts or intermediate files (.class, etc.) from the target directory ("target" by default)
See Introduction to the Build Lifecycle for more info. TestsUnit TestsAll unit tests for each module are run by default for each build. This can take a long time, depending on the module. If you wish to skip the unit tests, you can set the -Dmaven.test.skip=true parameter: mvn -Dmaven.test.skip=true install
Integration TestsIn addition to the unit tests for each module, the Mule project has a separate module containing integration tests. These tests verify "macroscopic" functionality which could not be tested by any single module alone. Vendor TestsIn addition to the unit and integation tests, there is a separate module containing "vendor" tests. These tests can only be run if a certain 3rd-party resource (database, application server, EIS, etc.) is present. Vendor tests are generally disabled by default. They may be run by either building the module from its own directory (i.e., not from Mule's top-level directory) or by enabling the corresponding profile (e.g., oracle, sap, tibco) as explained in the section Profiles, below. DistributionsAll distributions and distribution-related resources are located in the distributions module. For performance's sake, the distributions are not built from the project's top-level directory by default. You may either build a distribution from its own directory or by enabling the distributions profile as explained in the section Profiles, below. A brief description of each distribution follows: Full stand-alone server (distributions/server/full)Packages Mule as a stand-alone server application. Includes all providers and extras and all dependencies. Includes the Java Service Wrapper for starting/stopping/restarting Mule from the native OS. Custom stand-alone server (distributions/server/custom)Same as the Full stand-alone server but does not include any dependencies. If the user's project is based on Maven 2, it can easily provide the exact libraries it depends on thanks to m2's intelligent resolution of transitive dependencies. JCA Resource adapter (distributions/jca)Packages Mule as a JCA-compatible Resource Adapter for deployment into a J2EE application server. Includes all providers and extras and all dependencies. Embedded / Composite jar file (distributions/embedded)Builds a single jar file containing all Mule classes (including all providers and extras). This is useful for embedding Mule into another application or for using Mule with a non-Maven based build. Note that the user is responsible for providing any needed Mule dependencies. Extras (distributions/extras)Includes all the non-essentials: User's Guide (exported from Confluence), Samples, API (Javadocs), Tools, IDE. New users are recommended to download this in addition to the full distribution, whereas advanced users may not need/want it. SettingsOne of the principal objectives of Maven is to centralize all information necessary for building a module in a single project file. However there are a few settings (such as authentication, firewalls, active profiles, etc.) which may be host-specific or user-specific. These settings are stored in a separate file. Project settingsDefault settings for the project (or module) are stored in a settings.xml file alongside the project's (or module)'s pom.xml. User settingsUser-specific settings are stored in a settings.xml file in the user's local m2 directory. User-specific settings will override the project defaults. The top level directory of the Mule project contains a template for creating your user-specific settings. Copy and rename the file local_settings.xml to your local m2 directory (~/.m2/settings.xml by default). ProfilesProfiles are used to enable/disable certain parts of the build, depending on whether the profile is set. (It is sort of like setting a conditional compiler directive in C++) Your active profiles are determined by (in order of priority):
Command lineIn order to enable ("activate") the profile distributions from the command line: mvn -Ddistributions=true install
In order to disable ("deactivate") the profile tests from the command line: mvn -Dtests=false install
Settings fileIn order to permanently enable ("activate") the profile distributions in your project or user-specific settings.xml file, add the following: <activeProfiles> <activeProfile>distributions</activeProfile> </activeProfiles> RepositoriesA Maven repository ("repo") is a directory containing artifacts. The artifacts are usually Java libraries (jars) and meta-data (poms), but they could also be Maven plug-ins, source code bundles, javadocs, zips, pretty much anything. There is a very strict format to follow when adding an artifact to the repository, so don't try it by hand unless you know what you're doing. See Introduction to Repositories for more info. Local repositoryEach user has a local repository, created the first time Maven is run (~/.m2/repository by default) This is where artifacts produced by mvn install will be placed. Snapshots repositorySnapshots of artifacts are published to http://snapshots.repository.codehaus.org. This is where artifacts produced by mvn deploy will be placed. Release repositoryReleases of artifacts are published to http://repository.codehaus.org. This is where artifacts produced by mvn -DperformRelease=true deploy will be placed. Dependencies repositoryAn ad-hoc repository at http://dist.codehaus.org/mule/dependencies contains libraries which, for one reason or another, are not available for download from one of the major Maven repositories. The procedure for uploading a new library to this repository is as follows:
Troubleshooting and other Tips
Glossary
|
![]() |
Document generated by Confluence on Oct 03, 2006 09:23 |