In maven, what does "-e" stands for in the following command.
mvn -e clean install
Moreover, what is the difference between
mvn clean install
and
mvn clean compile
As Satish stated, the "-e" switch will display execution errors in the maven output.
As to the difference in "install" vs "compile", those are different Maven lifecycle stages. See the Introduction to the Build Lifecycle documentation for help with that. The key to remember is that Maven will execute all lifecycle stages up to and including the one you specify, and then stop.
Specifically in your case, "mvn clean compile" will run Maven with two lifecycle targets, the first being "clean", and the second being "compile". The "compile" lifecycle phase will run the build up to and including the compilation of project source code. The "install" lifecycle phase will run all the way through packaging your project into it's container (jar, war, etc) and will install it to your local maven repository, which resides on your local machine. When a project is installed to your local repository, other projects you build on your machine can reference it without having to have any knowledge of where the source code or project build artifacts actually reside.
the e flag (e = errors) prints out more detailed error messages.
mvn clean install, does compilation, linking and installs (copies to app server etc)
for more maven options look at this ref card
http://www.scribd.com/doc/15778516/DZone-Refcard-55-Apache-Maven-2
or maven command list
http://cvs.peopleware.be/training/maven/maven2/mvnCommand.html
mvn clean install - First, cleans already compiled class files (probably in target/ directory). Then, it compiles the classes, generate the jar, and then install the created jar to your local m2 repository (probably located at ~/.m2/repository/).
mvn clean compile - The clean does the same thing as above. And, then, it compiles the java files in the project. And, stops there. It doesn't create the jar nor install anything to the local maven repository.
-e switch will display the stack-traces occur when your build is failed. It's a normal stack-trace that java programs produce when exceptions occur. Do note that Maven itself is a Java program.
Related
I checked out a gtk project inside a docker and during meson build found many dependencies are missing eg. libwayland-dev, libxrandr-dev...
Because meson fails at the first missing dependency, I had to redo this over and over to get install the entire list of dependencies that will be looked for using pkg-config. And, in projects with multiple git submodules, this becomes a lengthy process.
Wondering if I'm doing this whole thing wrong or if there is a way to get to the complete list of dependencies.
To get dependencies for your project, from build directory run:
meson introspect --dependencies
How does mvn clean install works
mvn install should execute all the phases before install phase, that means it will first run the surefire test and then later update m2 respository with the dependency
Yes, this is how it works.
The phases are executed in order and the installation into the local repository is the last one.
With external dependencies it's simple: before compiling anything Maven downloads them.
With inter-module dependencies it's more complicated. It's important to understand that Maven first runs all phases for the 1st module, then runs all phases for the 2nd module, and so on. So depending on which phase you call there either will be a JAR file or there won't be.
Maven will try to give you as "high-quality" dependency as possible, meaning:
if you run mvn install - this will put 1st module's jar into ~/.m2, then by the time 2nd module starts - it already has a JAR dependency waiting in the local repo.
if you run mvn package the JAR doesn't go to local repo, it stays in target/. Thus this target/xxx.jar will be used as a dependency.
if you run mvn test there won't even be a JAR. There will only be target/classes. So 2nd module's compilation & runtime will have directory with classes & resources in its classpath (no JAR).
PS: this may actually lead to real implications. When you run tests in module2 you may be reading resources of module1 and working with their file paths. And everything will work fine in case of mvn test. But once you start running at least mvn package there won't be files anymore - all resources of module2 will be in JAR and thus can be accessed only with getResourceAsStream().
When I run
./gradlew clean assembleRelease
my binaries are built, but the unit tests do not run.
When I run
./gradlew clean build
all binaries are built and all unit tests are run, twice... once for debug and once for release.
How can I achieve what 'clean build' does but only for the release buildType?
Context: The main problem I am trying to solve is what is the proper way to configure a jenkins job to build assemble and run all unit tests for the RELEASE buildType only.
The way I have solved this for now is by adding this code block to the bottom of build.gradle in each module of my project:
project.tasks.assembleRelease.dependsOn {
project.tasks.findAll { task ->
task.name.startsWith('testRelease')
}
}
This does what I need it to do, such that when our jenkins server job runs:
clean assembleRelease
All the release unit tests are run and the artifacts are all created.
Not sure if this is the best/cleanest solution.
This worked for me:
gradlew clean check assembleRelease
This cleans and verifies (includes running tests) for all subprojects (even plain java ones) and then assembles only the release buildType, i.e. dexing and signing is only done as specified in the release closure.
I'm not sure if that's the cleanest solution, either. Still, it does not append boilerplate to build.gradle files and its is faster than running the clean build tasks.
A good overview over gradle's anchor tasks assemble, check and build is provided by the Gradle Plugin User Guide.
I have a multi-module maven project (maven 2.2.1).
One of the module is a maven plugin.
This plugin is bound to the compile phase of another module, and added as a direct dependency to trigger correct reactor ordering of module's building.
If I run 'mvn clean install' on the root module, with a fresh local repository, everything goes fine (build, test, install). (I precise that my project's artifacts are not deployed anywhere, only installed locally in my machine's local repo).
BUT if I delete my local repository, and perform 'mvn test', the plugin module is reported as missing ? Whereas, the build order is correct, the plugin module is built succesfully before the module using it ???
Is there any special treatment of maven module with 'maven-plugin' packaging ?
I don't understand why other project inter modules dependencies are resolved correctly and not this specific one !
The problem is that a Maven Plugin must be installed into the local repository first before you can use a plugin as a dependency (or better be part of the life-cycle).
I've been seeing odd behaviour from my Maven 2.2.1 installation whilst doing war installs.
Occasionally, I will update a class but the updated version is not packaged up in the artifact produced by mvn install.
So far, I have determined that an updated .class file is produced in the target directory, and that the class of the same name in the produced .war is not the same (different date modified, different size)
Running Maven from the command line with the -X flag produced debug output for the class like:
[DEBUG] *
WEB-INF/classes/mypackage/MyClass.class
is up to date.
I think I've also had the same problem before where the file that was cached(?) was an incomplete compile from Eclipse, causing 'Unresolved Compilation Problem' errors from the Maven build, but a working artifact from an Eclipse export.
How does Maven determine whether a
file 'is up to date' during the
install process?
Where are the files Maven is comparing to?
Can I force Maven to build a package from scratch?
Any other ideas would be appreciated!
So far, I have determined that an
updated .class file is produced in the
target directory, and that the class
of the same name in the produced .war
is not the same (different date
modified, different size)
Just to be sure, the classes should be built under target\classes, not target.
Can I force Maven to build a package from scratch?
You can force a full build by running
mvn clean install
This performs a clean (essentially removes the target directory) before running the install phase.
Also - check for copies of your classes outside of the Maven build directory. In this case as it is a webapp, check src/main/webapp/WEB-INF/classes