When we launch the maven command mvn package , does this command builds the Spring project at the same time ? Or does it just create the packaging file ?
Short answer - Yes!
Long answer:
Maven has a set of lifecycles (from https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html):
validate
compile
test
package
verify
install
deploy
Executing any given lifecycle will first execute the previous lifecycles - so when running mvn package it will first execute validate, then compile, then test, and then finally package.
If you run mvn package (or even just mvn compile) and check your target/classes directory you'll find your compiled .class files.
Related
Working with a multi-module project. Want to run maven commands as follows:
mvn clean compile
Then maven install phase without again executing maven compile
Not possible.
You would need to call the goals directly, phases cannot be run separately.
you can (now) skip phases by directly calling the goal via
mvn <plugin>:<goal>
e.g.
mvn compiler:compile
see this answer for details.
for install it should be mvn install:install
I can disable the particular phase in pom: Disable phases in Maven lifecycle. It is possible to disable test from the command line: -Dmaven.test.skip=true Is it possible to start mvn lifecycle from the particular phase, for example compile using only the command line options ?
By default, a lifecycle is as follows (from Introduction to the Build Lifecycle):
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework
package - take the compiled code and package it in its distributable format, such as a JAR
verify - run any checks on results of integration tests to ensure quality criteria are met
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in the build environment, copies the final package to the remote repository for sharing with other developers and projects.
While we can build applications without automated testing, we can't execute the package phase without an earlier code compilation.
Just as we are not able to install the package into the local repository without the .jar/.war packages, that are created in package phase.
For compilation you can use Apache Maven Compiler Plugin.
Then you can run compilation by executing
mvn compile
The command will execute maven goal compiler:compile
Based on the question Sonar + Clover only runs on src-instrumented, it is suggested using first mvn clean clover2:setup install clover2:clover, then: mvn sonar:sonar.
Just wonder why we cannot use mvn clean clover2:setup install clover2:clover sonar:sonar?
In the past it was the recommended way to run goal sonar:sonar alone. This is no more the case since SonarQube Scanner for Maven stopped trying to run unit tests + collect coverage for you by forking a new Maven lifecycle.
General advice is now to run goals in a single command. For example mvn clean package sonar:sonar
In the case of Clover the clover:setup goal will alter the Maven Model to make all other plugins (like surefire) use instrumented classes instead of original source code. This is indeed a problem because it will prevent SonarQube to match class files. So in your case you should either stick with two separate goals, or manually configure sonar.sources to refer to original source code.
Compared the maven logs and found the possible reason:
The "mvn clean clover2:setup install clover2:clover sonar:sonar" seems having issue to find the Source dirs. The log shows it uses ${project}\target\clover\src-instrumented and ${project}\target\generated-sources\annotations as the source dirs.
If explicitly specify src/main/java, then this single command works well. The only tricky thing is why running the goals separately doesn't need to specify sonar.sources but the plugin can still find the right folder for source dirs.
I am trying to understand the maven build lifecycle when it is regarding to tests:
Let's say I have a project with a class in the src/main folder and another one in the src/test. When I run mvn install, it get's compiled, then tested, then packaged and installed.
Until now I thought that maven would not package the tests in the snapshot, because this is not "production" code. Is this true?
In this case, when does maven ignores the test files?
What you said about the Maven lifecycle is true. The "main" phases include:
compile: in this phase, the maven-compiler-plugin:compile goal is run which compiles the main code of the project.
test-compile: in this phase, the maven-compiler-plugin:testCompile goal is run which compiles the test code of the project.
test: in this phase, the maven-surefire-plugin:test goal is run and all the unit tests are executed.
package: in this phase, the maven-jar-plugin:jar goal is run and creates a JAR of the current project. By default, this JAR will include all classes under target/classes, which contains all the main classes, but not the test classes which are located inside target/test-classes. You could say that it is at this step that Maven ignores the test classes.
install: in this phase, the maven-install-plugin:install will install the main artifact, and every attached artifact, into your local repository.
To answer more precisely, it's not that Maven ignores the test classes, it is that by default, the packaging process only considers the main classes. But you can configure it to also package the test classes with the maven-jar-plugin:test-jar goal inside another attached artifact.
I have a multi-module project a. Sub-module x includes an a simple integration test which requires also a dependency on sub-module y.
I would like to be able to separate the compilation and package phase from running the tests. When I run the following command, the integration test run successfully
mvn clean verify
When I run the following command, it fails
mvn clean package && mvn failsafe:integration-test failsafe:verify
[ERROR] Failed to execute goal on project x: Could not resolve dependencies for project a:x:jar:1.0-SNAPSHOT: Could not find artifact a:y:jar:1.0-SNAPSHOT -> [Help 1]
The underlying reason is that I would like to run the unit-tests and various integration tests each in separate jenkins tasks after the compilation completes (without running compile and package phase again). Reproducible code is here https://github.com/itaifrenkel/failsafe-test. Using Maven version 3.2.1.
Clarification: I cannot mvn install on jenkins machine since I have concurrent builds of different git versions (that have the same maven version).
When you execute mvn clean verify, the build succeeds: Maven resolves the y dependency because it is in the same project reactor and y was packaged successfully into a jar inside this reactor. If you take a look at the log, you will notice that this command triggered the maven-jar-plugin, which is expected since this plugin is bound to the package phase and verify phase comes after it in the build lifecycle.
The command mvn clean package && mvn failsafe:integration-test failsafe:verify actually executes 2 commands. First, mvn clean package will succeed and package the application (same reason as before: y is in the reactor and is packaged into a jar).
However, for the second build, mvn failsafe:integration-test failsafe:verify, since y was not packaged into a jar inside the reactor, Maven can't resolve the dependency directly so it needs to look for it in the repository. Since this artifact was never installed in the repository (and is obviously not available in Maven Central), the dependency can't be resolved, hence the error message
As such, you have 2 possible solutions:
Install the y dependency into the local repository with mvn install:
mvn clean install && mvn failsafe:integration-test failsafe:verify
Running jar:jar before the integration tests so that Maven can resolve the y dependency. This does not rebuild the project: it makes the assumption that the project was already built before by simply asking maven-jar-plugin to make a jar out of the result of the previous build.
mvn clean package && mvn jar:jar failsafe:integration-test failsafe:verify