Table of Contents
Maven project is opened in Visual Studio. You can find instructions how to create a Maven project in this section. You can also find an overview of Maven projects in this section.
Maven system has a modular architecture. That means there is a central framework, as well as a lot of plugins which perform various activities related to the build (like compiling sources, packaging classes into a JAR, generating documentation, etc). Each such activity performed by a plugin is called a goal. A plugin may provide multiple goals, so you can think of it as a library of goals. (Caution: there are also so-called reporting plugins which are a bit different and not to be confused with regular plugins. Reporting plugins are described in this section.)
A goal is also somewhat similar to Ant task so that it performs single build activity which can be configured. The difference is that in Ant you specify a sequence of tasks directly, but in Maven the order of execution of goals is determined by Maven itself using a set of rules. These rules are collectively named the build lifecycle. In short words, the build is divided into some phases which order is fixed (e.g. validate, compile, test, package, integration-test, verify, install, deploy), and you can specify which goals are to be run in each phase. If you do not specify this, Maven will pick certain default plugins and goals to be run in each phase. Therefore Maven build will work even with minimal configuration. Default lifecycle provides a working build process mostly suitable for typical cases.
When you want to modify some aspects of the default lifecycle, you need to specify plugin configurations. This involves both setting various parameters for a plugin, and specifying which goals to run during various lifecycle phases. The latter one is called goal binding. One important concept related to goal binding is plugin execution. A plugin execution is a directive to run particular goal (or goals) in specified build phase, with specified settings. You can think of it as of a kind of command -- although not executed immediately, but rather when its turn comes, that means when corresponding build phase has started.
In fact, Maven defines by default three lifecycles: the build lifecycle (which has no name and is often called the "default" lifecycle in Maven docs), the clean lifecycle (cleans build results) and site lifecycle which generates so-called site documentation for the project (this is HTML view of the project metadata). Each lifecycle has its own list of phases. These lifecycles have different phase names, therefore it is always sufficient to use a phase name alone, without its lifecycle name.
There is also one more small complication: lifecycles are defined separately for each packaging, so that Maven can do different things when building a JAR, WAR, EJB or other package type. Since your project specify concrete packaging, there is no ambiguity here and Maven exactly knows which lifecycle definition to use.
You can find more info on plugins and the lifecycles in this section of Maven docs.
Plugins in IntegraStudio are configured in the Solution Explorer window. There is the Plugins node, listing all plugins used during the build.
Under each plugin node, there is Executions list which lists particular executions. When that list is empty, Maven usually supplies some default executions for the plugin. For example, compile goal of the maven-compiler-plugin is called by default during the compile build phase. The execution list you can specify here overrides default execution list.
In order to add a plugin to the list, right click on the Plugins node and choose New item. A property editor window will appear, where you can enter basic plugin data: mainly the group, artifact and version. In most cases you will be configuring standard Maven plugins, hence the group id will be default org.apache.maven.plugins and the artifact name can be choosen from the standard plugins list (click the arrow button next to the field to open it). The version parameter can be left empty.
To remove a plugin, right-click on it and choose Remove. You can also edit its basic Properties.
For advanced configuration of a plugin, you will need to write some XML code. First of all, you need to decide whether to configure each of the executions separately, or supply one configuration for all executions. For the latter one, right-click on a plugin node and choose Edit configuration node. A XML editor will open in Visual Studio, where you can edit the <configuration> node contents. It is dependent on particular plugin. Each plugin has its own XML format of the configuration.
Note that IntegraStudio does not check correctness of entered configuration, because only particular Maven plugin can do it. In case of wrong configuration, you will get Maven errors during the build.
The configuration specified here will be used for all executions (regardless of the phase), unless overridden in particular execution. It is also effective for executions supplied by Maven by default (when you do not specify any execution by hand). Therefore it is viable method of configuration when you want only to modify some parameters, not altering default bindings.
If you want to customize the default build lifecycle, you will need to add one or more execution elements. Each execution collects together the following data, describing what, when and how to execute:
Sometimes what you want is not to add an execution of a plugin to the build, but rather remove it, so that the plugin does not get executed. If it is your own added execution, the trivial solution would be just to delete it. But what to do for default executions, which Maven performs implicitly? There is a way to disable these implicit executions as well.
First, you need to know the id attribute of the execution. The simplest way to retrieve it is to right-click on appropriate project node and choose Maven / Display effective POM option. IntegraStudio will display an XML document being the "effective" (fully resolved) project structure, as Maven uses for actual build. These default executions are there as well, and what you need is to look up id attribute values (e.g. default-compile or similar).
Next, add an execution to the plugin with the id value you took from the effective POM, and the phase name set to none. This will effectively disable that particular plugin execution.
Table of Contents