|Home > Guides > Contributors Guide > Building the Framework from Source > Building with Maven|
|Maven 3.0.0 or later is required to build Struts 2|
First, let's review some Maven basics. Maven uses the notion of a build life-cycle to which plugins can attach. Plugins are similar to Ant tasks. When a Maven build is invoked, we specify a point in the life-cycle up to which the build should proceed. The compile phase comes before test, and test comes before package, and package comes before install. Once we have Maven setup, we can invoke the Struts build, and specify which phase the build should use.
The install phase builds up the project ("package"), and installs any JARs it needs into your local repository (e.g. ~/.m2/repository). Once installed, the JARs can be used by any other Maven project you build. The install phase is the default phase if none is specified.
To run a basic install, change to the root of the source distribution, and enter
That's it! Maven will download any dependencies the build needs; run all unit tests; package up the JARs; then install the new JARs locally. For your convenience, copies of the JARs can be found in the target directories of each module. For example, after the build, the main JAR can found at core/target/struts2-core-2.0-SNAPSHOT.jar.
|It's supposed to be automatic, but you might still have to press the button|
Sometimes, licensing restrictions prevent Maven from downloading all the JARs that a build might need. For example, JavaMail and Activation, can only be downloaded from Sun. When this happens, Maven will display a helpful message that explains how to install these JARs manually. After downloading the required JAR, follow the instructions to install it to the your local repository. Once installed, the JAR is available to all your Maven builds, not just Struts.
There are other phases that can be useful when working with Maven. The package phase will just JAR (or WAR) the modules. The test phase will only execute unit-tests. The compile phase will only build the source-code (but not the test sources). And the clean phase will remove all artifacts, typically the entire target directory.
The next step in building the framework with Maven is to understand build profiles. Profiles provide different configurations for a build. There are several profiles, including default, xwork, and _thirdparty".
|default||Builds site, api, and core|
|apps||Builds the example applications|
|plugins||Builds all plugins|
|extras||Includes the extras module that cannot be part of the default build due to licensing incompatibilities|
|xwork||Includes the xwork build|
The default profile will work for most developers; however some developers will want to use additional profiles because they work on both XWork and other modules, such as the JasperReports integration.
Specifying a profile is easy:
If you want to build all the Extras module (not included in the default build) use the _extras*_profile.
In the second run, the Extras module is built. If you decide to make use of this module, be sure to review the licenses of its dependencies, since they may fall under a license that is incompatible with the Apache License.
Struts 2 is an extension of the XWork framework. While Struts2 adds a lot of value for web developers, much of the core functionality is derived from XWork. The xwork plugins add the capability to build against a current XWork check-out, rather than a pre-compiled JAR.
The plugin assumes that the latest XWork code is checked out and is located at ../xwork, relative to the struts2 folder. You can check out XWork using the Subversion command:
If you don't have the command line version of Subversion installed, you can download it from the Subversion site, and add the bin folder to your command path.
Now, Maven will build XWork from source and use that as the XWork snapshot for the Struts build.
Maven can build against multiple profiles. If you are developing against both the XWork and Struts 2 frameworks at once, you can install both profiles with one call to Maven.
Using both profiles is especially important when using Maven to build your IDE project files (recommended).
Maven has a great feature that will allow you to build up your IDEA or Eclipse project files based on the project build structure. Using the Maven project files helps keep developers in-sync and efficient. The IDEA project files are pre-configured to define in the Run/Debug menu many common tasks, such as "execute all tests", "launch the showcase sample app", and so fort.
The Maven IDEA plugin creates IDEA project and modules files, based on the Maven build configuraton (pom.xml).
First, be sure you have the latest IDEA plugin for Maven.
Most often, we use Maven to build projects, but it can also run plugins directly. To build an IDEA project file for Struts 2, including all the modules, run
Maven will generate struts-parent.ipr, struts-parent.iws, and an iml file for each module listed Open up struts-parent.ipr in IDEA, and you should be good to go.
If you ever need to rebuild your projects, running the idea:idea command again will update your files without overriding any information that doesn't conflict. If you do want to overwrite the project files, specify the overwrite parameter as true.
|Clearing the cache|
If you find the xwork module causing you problems, such as displaying as "XWork" when it should be named "xwork", the problem is likely to be within IDEA. Try clearing out your IDEA system cache and then run it again
For Eclipse, try
Many Struts 2 developers use IDEA, and the Eclipse project files are not as well-tested or featureful as the IDEA versions. But as far as we know, they work!
Currently the sample applications can be deployed using the Maven 2 Jetty plugin. For example, you can run the showcase example application from the command line:
You could also use one of the Maven IDE plugins to run the plugin or simply execute the mvn or mvn.bat file as an external application within your IDE.
A good tutorial on how to use the Maven 2 jetty plugin along with your IDE, including JPDA debugging support, can be found at the Apache Wicket documentation.
A few helpful tips for using Maven are provided:
If you are disconnected from the Internet or simply wish to make your build faster, pass in the -o argument and Maven won't check for new modules to download.
If you get an OutOfMemoryError while running the tests:
Although this shouldn't ever happen, sometimes tests do fail and you need to build the framework anyway. If there's a problem, you can pass in the skip tests parameter.
Of course, if you find tests are failing, please submit a patch to fix them!
Struts 2 depends on the current snapshot artifact of XWork 2. Unfortunately, if XWork 2 is modified in a significant way, the Struts build doesn't check for and retrieve a new version of the XWork snapshot jar, resulting in compilation or unit test failures.
The solution is to clear out any stale XWork 2 jars in your local Maven repository, usually by removing the directory ~/.m2/repository/opensymphony. This will force the Struts Maven build to pull down a fresh copy of XWork and hopefully resolve your problem.
Maven terms a release build an "assembly". An assembly aggregates the builds of all the modules installed locally on your machine into one or more release files. The default profile for building Struts 2 includes an assembly that attempts to download a mirror of the wiki. This can be time-consuming, to disable the assembly module just add -DskipAssembly to your maven command line.
To create a release, you must first build and install locally every artifact. From the root struts2 directory, run:
Next, you need to run the assembly build to create the release files. From the struts2/assembly directory, run:
If the assembly built correctly, you should see the release files in the target/assembly/out directory.
The default mirror for Maven builds ("ibiblio") can be slow and unreliable. Maven lets you specify alternative mirrors so that you don't have to depend on ibiblio for everything.
You can add new mirrors through the Settings file (~/.m2/settings.xml).
|Sometimes the alternative mirrors have problems too or aren't updated at the same frequency as the main mirror. If you have trouble building, try commenting out the aternative mirror.|
In some cases it has been seen that Maven will complain if a module doesn't exist, even though it is part of the current build. Often, the missing module turns up when executing mvn package. A simple fix for this is to run mvn install instead. If you have to do this, it will probably only be a one time thing.