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.
Related
I am working with a rather complex open source Java project that uses Maven as its build tool.
It is a multi-module project with a parent POM, several submodules, WAR overlays, goals bound to nondefault phases and whatnot.
The build complexity is therefore high, and mvn help:describe -Dcmd=package is not informative enough to give an outline about what gets done during a build.
Is there a way to get an overview about all build steps?
As far as I know, I don't think that there's a Maven plugin that will do what you are asking out of the box. The way most of us Maven users do is to start from the root POM and simply run mvn clean install. What this gives you is more or less* all the plugin executions that are part of the default build.
Please note that there could also be profiles that may change things. Running mvn help:all-profiles will list all the available profiles and tell you where they come from (settings.xml, root POM, child POM, etc). This, together with perhaps mvn help:active-profiles, will help you get an idea of what is going on.
Also bear in mind that profiles are not mutually exclusive, so even though this allows for flexibility, they can sometimes cancel each other out or produce strange results for unexpected combinations.
I am sorry that I can't give you better advice than this. I don't know your level of Maven expertise so this information might be irrelevant to you.
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.
Does anyone know the Maven build goals dependencies and order?
For instance, if I tell Maven to clean, it just cleans. But if I tell Maven to install, it also calls generate-sources, compile, test, etc. I am trying to figure out which goals are dependent on which other goals.
I have found this document, but it doesn't show dependencies.
It is sequential in the order mentioned under lifecycle section. You have clean and default lifecycle. The last command deploy under default lifecycle depends on every other command listed above it in the hierarchy. Similarly every command in a lifecycle depends on other commands listed above it.
Is it possible to somehow chain archetypes together by some super-archetype in Maven?
For example I have an archetype create a multi-module project setup.
One of these module projects should be created by another archetype. This archetype is not controlled/developed by myself and availible versions change independently of my multi-module archetype.
Therefore is it possible to define some kind of a super-archetype which executes my archetype A creating the full multi-module setup and afterward creating a module by executing another archetype?
If that is not possible - maybe there is another way to achieve this by using some other Maven functionality?
If I understand correctly you could use your archetype to create your multimodule setup but lack the possibiliy to create one of the modules through another archetype. I don't know of a super-archetype but perhaps this approach is helpful:
You could either extend the pom of your archetype or use the goals commandline argument of the generate-goal to fire a second archetype generation (f.e. via the antrun plugin) and embed the result in your multimodule setup. To automate generation for the third-party archetype you can use the individual parameters of the generate goal (again).
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