I'm trying to build a multi sub-modules project using maven 3.3.9 with --fail-at-end. Running one cycle of this phase took so much time (some hours) and in every cycle i solve problems in building some of sub-modules and running maven build again (starting another cycle).
So the question is: Is there any way to force maven not to try building packages which been built successfully in previous cycles?
Thanks in advance
It sounds like you have a multi module project and you are trying to get a complete, successful build via an iterative process of ...
build -> fail -> fix the failure -> rebuild
... and each time around that loop you'd like to resume with the module in which the failure occurred rather than building the whole project every time.
The standard approach to this use case is to use -rf:
-rf, --resume-from
Resume reactor from specified project
For example, if the module named moduleD fails then re-run your build as follows:
mvn -rf :moduleD install
More details in the docs.
You might also choose not to include the clean phase when re-running your build, thereby allowing Maven's incremental compiler to work out what needs to be rebuilt.
Related
I was building a multi-module project with Maven3. In a module, it gave a "build failure" and said after completing my error, I can use -rf :moduleName in order to continue my build. I did not change anything and gave the same command this time with -rf :moduleName as the maven said and built successfully. What may be the possible reasons of this situation and is not -rf command in Maven reliable?
Either you have a non-deterministic test which fails randomly, you need to look for why and fix it.
Etiher it is just a plugin maven error, for exemple maven-clean-plugin may fail under some OS if target directory is used (explorer, etc.) and may work when it is reexecuted a second time if the lock was released.
Either you have snapshots dependencies and parallel builds and share maven artifact repository with others teamates, like Nexus or Artifactory.
For example, if module A depends on B, in your local build the build chain will be "B, then A". If A doesn't compile, B is built and put into local repository, but the complete build chain fails when building project A.
Then if you use -rf flag, the build chain doesn't recompile B and starts building from module A.
But imagine that you have a continuous deployment, like Teamcity or Jenkins, the project B may be rebuilt with same version number (snapshot) and put in shared central repository. In this case, module A retrieve last available snapshot for module B which can not be the right artifact (if you have local modification), and A may have no error when compiling with this code for module B.
You can avoid this problem either by rebuilding the chain entirely, either by using the -o flag which means "offline" mode (ie maven will retrieve artifacts only from local repository).
To fix correctly it, you should take care of the error and investigate what the specific error means. It was a compile error ? a test failure ? a maven plugin error ? Start by reading the error message, it may help :)
I'm building a big project using Tycho.
Trying to build offline after one online build is successful, but every time I build, it costs me about 20mins to resolve dependencies.
For other reasons, build fails and I have to try many times. The wasted time got me crazy. Is there any way I can skip the "Resolving dependencies" step?
Once you build your project, i.e. you hit the install lifecycle phase, Maven will have the dependencies pasted under your local repository.
Unless you force dependencies reloading, Maven will go for an offline installation since all dependencies are there (that is the main purpose of saving artifacts locally).
That is the second build should be faster and straightforward.
If you are working within Eclipse, make sure it is using a local copy of Maven. Otherwise, the -o option should be fine if no snapshot dependencies are there:
mvn -o
I'm making a case for moving our builds from Maven to Gradle. Below are a few of the Maven command-line options my team finds useful. What are the Gradle equivalent choices?
-am,--also-makeIf project list is specified, also build projects required by the list
-amd,--also-make-dependentsIf project list is specified, also build projects that depend on projects on the list
-o,--offline Work offline
-pl,--projects Build specified reactor projects
instead of all projects
-rf,--resume-from Resume reactor from specified project
Maven Examples:
I only want to build the sub-project I'm working on and its dependencies.
mvn install --also-makeIf --projects :my-sub-project
After fixing an build issue, I want to start the build from the point of failure.
mvn install --resume-from :my-sub-project
I don't want to download external dependencies from an central repo.
mvn install --offline
Here are some rough analogues:
-am: buildNeeded (This triggers a full build of all upstream projects; building those parts of upstream projects that are required to fulfill the command at hand is automatic in Gradle.)
-amd: buildDependents
-o: --offline
-pl: :subproject1:build :subproject2:build
-rf: No direct analogue (not reliable, wouldn't work for parallel builds, etc.), but Gradle's incremental build will get you to the "resume point" quickly.
Note that Gradle's core concepts differ significantly from Maven's. To give one example, in Gradle build order is solely determined by task relationships, and there is no such concept as an execution dependency between projects. Due to these differences, some Maven features aren't necessary or useful in Gradle, some you get for free, and some come in a different form.
I have a project with the following subprojects:
foo-codegen
...which, as the name implies, performs code generation...
foo-maven-plugin
...which invokes foo-codegen during the build process.
Generally speaking, this works fine. The problem, though, is when I want to test foo-codegen: foo-maven-plugin isn't yet available during foo-codegen's build cycle if we're putting things together in dependency order, but the build process for the tests invokes that plugin to actually perform the necessary code generation.
What's the right way to break this chain? Should I move foo-codegen's tests into a third subproject? Use the Maven Invoker plugin rather than foo-maven-plugin for doing code generation during the test phase? Something else?
If you do a mvn install or mvn deploy to a repository on the plugin first, then you can run them any order and do a mvn compile separately.
When I build my application with maven, I run mvn clean install. As a part of the install lifecycle, I run appengine:devserver_start from Google's GAE Maven plugin. This appears to be already bound to a step in the lifecycle and therefore it reruns some build steps from the beginning, even though me running mvn install did those. For example, the resources step is rerun. I had my own Java script run to download the latest resources for my build. But because of appengine:devserver_stop, I need to uselessly run this cript again because the resources step is re-executed.
I can think of two ways I can avoid this, but I'm not sure how to configure both ways. The first would be to somehow skip re-running build steps that I've already run. The other way would be to change the Maven POM properties just for the plugin execution. I have a Maven property set, either to true or false, that I can use to set the skip setting for the Java script I use during resources (because I run this script using the exec-maven-plugin). Think of this as a Maven property that can be set with the -D flag. Can I have this property changed just for the plugin?
If you are having trouble thinking about my scenario, consider what happens when you run mvn compile install. All build lifecycle steps until compile will run, then all compile steps until install will run, including compile.
A common/easy way to solve this kind of problems is to use maven profile. Just create a new profile that includes the plugin with preferred phases.
You should probably don't fight with it and just run clean appengine:devserver_start instead of clean install. Read my answer here for a more detailed explanation:
https://stackoverflow.com/a/17638442/2464295