I've been reading about Maven reactor and am confused by its terminology usage. I've read that a multi-module is a reactor, that you can manipulate the maven reactor and that the reactor is a plugin. What exactly is the reactor?
The reactor is the part of Maven that allows it to execute a goal on a set of modules. As mentioned in the Maven 1.x documentation on multi-modules builds (the reactor concept was already there in Maven 1.x), while modules are discrete unit of work, they can be gathered together using the reactor to build them simultaneously and:
The reactor determines the correct build order from the dependencies stated by each project in their respective project descriptors, and will then execute a stated set of goals. It can be used for both building projects and other goals, such as site generation.
As explained, the reactor is what makes multi-module builds possible: it computes the directed graph of dependencies between modules, derives the build order from this graph via topological sort (that's why cyclic dependencies are disallowed) and then executes goals on the modules. In other words, a "multi-modules build" is a "reactor build" and a "reactor build" is a "multi-modules build".
In Maven 2.x, the support of multi-module builds has been very much improved and the reactor has become transparent to Maven users. But it's still there and is used under the hood.
In September 2008 (i.e. a long time after the rollout of Maven 2), a reactor plugin has been created to make it possible to interact (again) more closely with the Maven reactor. Brett Porter blogged about it in Reactor: My New Favourite Maven Plugin.
Most of the reactor plugin features are now natively supported (since Maven 2.1.0). See Maven Tips and Tricks: Advanced Reactor Options.
Reactor is used when a project have multi-modules.
The work done by reactor is:
Collecting the module details
Sorting the order based on dependencies
Building the projects in order
Starting with the 2.1 release, there are new command line options which allow you to manipulate the way Maven will build multi-module projects. These new options are:
-rf, --resume-from
Resume reactor from specified project
-pl, --projects
Build specified reactor projects instead of all projects
-am, --also-make
If project list is specified, also build projects required by the list
-amd, --also-make-dependents
If project list is specified, also build projects that depend on projects on the list
More details:
Maven Tips and Tricks: Advanced Reactor Options
Related
I have to make build architecture of my small project and I wonder how to proceed?
I have classes in one project for the so call core-part which can be used in other projects and api part in the first project which uses core-part.
So how to act?
To make multi-module Maven build and to produce 2 artifacts (which to upload to our company repo) and api-part have project dependency to core-part:
pom.xml
|
/core-part
|
/api-part(depends on core-part)
Create separate projects
Project1
/core-part
|
pom.xml
Project2
/api-part
|
pom.xml -> depends on project1's GAV artifact
Project3 ,...n depends on project1?
"Strong advice" : a project belongs in a multi-module build if release of that build requires release of that module, and vice versa. Multi-module projects should consist of things that must be released together.
An API should [practically] never depend on the release of its implementation, whereas the release of an API [nearly always] dictates the release of a new dependent implementation.
If you're not doing formal releases (why aren't you doing formal releases?) then this advice is still in force but less strong.
1. is the way if you'd like to build core-part and api-part within one build by building the aggregator/multi-module project (which has to have <packaging>pom).
There is actually a third artifact created (and installed and deployed to the repositories) then: The one for the aggregator project.
2. is the way if you'd like to handle (build, install, deploy) core-part and api-part individually. (An option you still have with 1. anyway.)
See:
POM Reference, Aggregation (or Multi-Module)
Maven: The Complete Reference, 3.6.2. Multi-module vs. Inheritance.
I am thinking about creating a multi-module project in maven, with one plugin module (i.e. this module is used as a plugin in other projects, not a dependency).
Question: Is it feasible to have a plugin as a module in a multi module maven project?
It is feasible and it is also documented on the official maven multi-module/reactor page concerning how having a plugin as module is handled by the build (bold is mine):
Because modules within a multi-module build can depend on each other, it is important that The reactor sorts all the projects in a way that guarantees any project is built before it is required.
The following relationships are honoured when sorting projects:
a project dependency on another module in the build
a plugin declaration where the plugin is another modules in the build
a plugin dependency on another module in the build
[..]
Once the plugin is installed and deployed, it will then not bring with it any knowledge of its module nature, that is, it will be seen as a normal plugin by the projects that will use it via its unique maven coordinates (GAV).
The same is applied to archetypes, which can be modules of a multi module project and then be used individually.
Also note that you can have - as an example - an aggregator project of projects (then modules) completely unrelated between each other, and, say, just aggregate then because you want to build them all together (often not really meaningful, but useful in some cases).
It is my current impression that is impossible to do CI for a Maven 3 multi-module project well using Hudson (or Jenkins).
The situation seems to be that you have 2 realistic options of building a multi-module Maven 3 project with Hudson:
A freestyle project can also Build Maven projects, and with the incremental/recursive option it apparently should be able to deal with building only the necessary subtrees of the complete project tree.
A legacy, severly deprecated, with lots of warnings, Maven2/3 legacy build.
With the first option there is the significant disadvantage that your complete project looks like one big blob in Hudson, there is no visibility on the individual subprojects and there is no option for building individual subprojects and their dependees.
With the second option you have to basically swallow very little faith inducing warnings about legacy and "do not use" in order to find out that yes, it will build your multi-module project but the functionality of triggering subproject builds is completely broken and there is no intention of fixing this.
The only alternative I can figure out is to revert to Maven 2 for the build on the server, in which case the legacy plugin seems to work and even the individual sub-project builds can be triggered. But then I'm stuck on Maven 2.
I find my requirements to be rather conservative but I am completely stymied by the lack of Maven support in Hudson/Jenkins. Here's what I would expect:
ability to recognize multi-module projects and build them using Maven 3
ability to have "incremental" builds of such a multi-module project (i.e. only changed modules and its dependees)
ability to see the current status of the multi-module project and what sub-module has failed/succeeded/is unstable
The Maven project in question consists of about 84 Maven modules in a multi-module configuration with a common parent and a split into different subsystems. We are using Hudson 3.1.0.
Do I have any chance of achieving this?
Yes, it is impossible to do it well with the current Maven 2/3 project type.
I have done it well enough using a matrix / multi-configuration project type, and adding a "Module" axis manually. The configuration of the matrix job is a pain, and you have to remember to update your axis any time you add, remove or rename a module. But once configuration is complete, this solution works well for building. You can see the build and test results for each module separately, or integrated under the matrix job.
My colleague has been working on implementing Maven 3 multi-module functionality in Jenkins.
https://github.com/adamcin/maven-plugin
Not sure what the upstream acceptance status is.
I have been reading on Maven and I understand that phases contain goals (which belong to maven plugins), that a phase can have multiple goals and a plugin can expose multiple goals?
If you look at some Plugin Bindings, there is one plugin goal (one only), attached directly to a phase. It is true that you can customize, but why would you?
What is the purpose of this feature? Can anyone offer some examples?
Maven knows about all the phases, but not about all the plugins and their goals in the world. So it is not exactly that phases contains goals, but the other way around: a plugin goal is bound to a specific phase.
For example: there are several plugins which can do some validation before building the project, like the Maven Enforcer Plugin and maybe your custom-validation-plugin. Both goals needs to be executed during validation, so you bind them to that phase.
Maven defines about 20 phases, so simple projects often have indeed just 1 plugin bound to a phase, but as things get complexer, it is very normal to bind multiple plugins to 1 phase.
I have a maven project which has multiple profiles and lots of dependencies which are specific to each of those profiles. The current solution to clean this up works by creating an intermediate dependency pom for each profile which groups the dependencies together as described here in 3.6.1: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html Each of these dependency grouping poms lives in their own svn project and is build and deployed as a separate jenkins job.
The problem is that these poms, and the dependencies within them change and are released often and it has become difficult to maintain. Ideally, I would like all of the dependency management to live under one svn project and one build.
Any suggestions would be appreciated.
As khmarbaise writes, it would help with more information and an example.
However, just answering your actual question, how to get all your depenency grouping poms as one project and one build. It sound as if a multi module project with each module being one of your "dependency grouping pom" projects would be what you are looking for.
The Maven Release Plugin did what we needed.