It seems that the assembly plugin (or jar/war plugin) are just dumb.
They just can't figure out whenever there is just nothing to do.
A basic "Makefile" won't recompile a target if all its dependencies are older than the target.
For maven, it seems that the packaging is done "all the time" !
if I do "mvn package" and then "mvn integration-test", Maven will process the packages again and again.
Since I build some fat-standalone jars : it takes a while !
Is it also the way is works for you, or is there something broken in my configuration.
Thanks in advance for your help,
Raphaël
In Maven exists a Life-Cycle which is run through every time you call a phase.
mvn integration-test
means to run all phases which are before integration-test (incl. integration-test itself) which includes in your case the package phase. Furthermore you shouldn't call integration-test cause the post-integration-test will not run in this case. You should call mvn verify instead.
The result from the above is you should simply call mvn integration-test and the package phase will run automatcially. Maven is not Make.
Related
I wrote a Mojo that creates a new Java class and puts it in /target/generated-sources/annotations. in addition, I have configured build-helper-maven-plugin to declare that folder as source folder.
The problem is when I do: mvn clean install from CLI it generates the source file but it doesn't compile it.
Note, if I run Maven Install from within Eclipse (using the m2e connector) then it works fine.
What am I missing?
Without an actual plugin definition, we can only speculate.
I can't comment on m2e, I see one obvious difference that you state by yourself: mvn clean install vs mvn install, but from the "bare" maven's standpoint,
here is one possible reason:
Maven has a concept of phases that comprise the lifecycle. An information about phases of default lifecycle is available here
Plugins (more precisely the "goals" of plugins) are something that usually gets attached to a particular phase.
Maven compiler plugin is attached to the compile phase, for example.
So, maybe the plugin that you've developed runs later than the compiler plugin.
Usually, source generation plugins are attached to generate-resources phase.
Its possible to run a full lifecycle in maven, in fact its what people usually do, for example, running mvn test actually means, run all phases of the default lifecycle up-to (including) phase test.
It's also possible however to run a particular plugin goal "directly" without attaching it to the phase. Of course, in this case, its pre-conditions should be met.
For example, mvn surefire:test means that we should invoke the surefire plugin directly. Of course the source code and test code should be compiled beforehand (bytecode has to exist in the target directory)
So I suggest you to run the following series of commands (Adjust if you have tests):
Run mvn clean install on the plugin project to place it to local m2 repo
Run the plugin directly: mvn ::: and check
whether the source is generated in the target folder
Make sure in pom.xml of the project that the source folder are configured correctly
Run mvn compile (phase up-to, including, compile) on pom even without the plugin
After this phase, there will be compiled sources in the target directory. Don't run
clean because it will wipe out all the target directory
This will effectively help to make sure that plugin does the job right
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'm running the following sonar command with maven:
mvn clean compile sonar:sonar
I'd like to just run:
mvn sonar:sonar
(ie have the sonar task trigger the clean and compile steps)
Is there a way to express this as a dependency in maven?
Quick Answer: No - not by declaring dependencies nor by having the plugin be in charge of the lifecycles and their phases to be run prior to the plugin's goal.
By mvn clean compile sonar:sonar you are instructing Maven to first run the entire clean-lifecycle with all its phases - then continoue with the default lifecycle to the phase compile and finally to call the goal sonar of the plugin sonar - i personally think the command is relativly short for what is going on and must not be simplified any further (what would be the actual benefit of a shorter command executing the same phases/ goals in the background?).
You can however bind plugins to certain build phases so that if the phase is run (say the phase process-classes right after phase compile in the default lifecycle) the plugin's goal will be executed automaticially.
This would abstract the need of explicitly calling sonar:sonar and allow for example to just call mvn clean process-classes and have sonar:sonar beeing executed in the process-classes phase of the default lifecycle.
Now to come back to your question one could generally ask if a Maven plugin can take controll of the lifecycles and phases beeing executed prior to its own goal which is as faar as i know not possible with "standard Maven techniques" (I however dont know of the possibilities if you write your own plugin).
I want to run a maven project lifecycle starting, and ending, with the unit tests.
How can I skip recompilation and re-resolution of dependencies and only run the test phase?
If you start maven by calling a phase it will execute all lifecycle phases up to the one you are calling. For example, when calling
mvn test
all the phases before the test lifecycle phase will be execute too: the project will be validated, sources and resources will be generated and processed, sources will be compiled, the same will happen to test sources and resources and finally unit tests will be run.
But you can also call the plugin goal that is bound to a lifecycle phase. In the case of the test phase the bound goal is surefire's test mojo. So you could call
mvn surefire:test
and no other lifecycle phase will be executed.
You can find the goals bound to each phase depending on the package type here.
You can run :
mvn surefire:test
Build your own lifecycle, or run the tests with something besides Maven (Ant, Gradle, your IDE, command-line JUnit runner, ...). That's the kind of restriction you live with when you're using Maven.
Is there any way to execute a specific phase in a maven build. For example, if I only want to run those plug-ins that execute in the pre-integration-phase, does Maven provide a means to do that?
e.g.
mvn pre-integration-phase
You can't call the life-cycle-phase itself but you can call the goals of the plugins which are bound to the life-cycle-phases.
mvn compile:testCompile
mvn failsafe:integration-test
but usually this shouldn't be needed...
No. You'd have to run the plugins manually.