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.
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 have a multimodules project with many dependencies. Until now after successful build I was performing sonar analysis of whole project. To save time and build project I detect which modules have been changed and run maven command:
mvn install -pl module1,module5,module2 -amd
Is there any way to do static analysis only for built modules? Something like mvn sonar:sonar -pl module1,module5,module2 -amd? of course it doesn't work, do you have any idea?
I know that there is option:
mvn sonar:sonar -pl !module2
but my project has more than 50 modules so if commit change only 5 modules I will have to list 45 others modules.
SonarQube always requires full scan. If you exclude some modules and execute the scanner, then excluded modules will disappear from SonarQube. It means there is no such flag.
Read more: How to analyse only new added lines of code?
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
I added to my maven project the a PMD and checkstyle plugins. And when I run them the work perfectly. But when I remove them from the pom.xml I can still run mvn checkstyle:checkstyle or mvn pmd:pmd even though I removed them. Also after removing them I ran mvn clean install. ANy idea of what could happen ?
The commands you execute are plugin goals (plugin:goal) and unlike "mvn install" not a phase.
you can run almost any plugin on a project if maven can find it. The apache maven plugins allow that shortcut notation (pmd:pmd) since maven will try to resolve them in the apache namespace.
Plugins from other sources would need to be run with their full name, for example:
org.codehaus.mojo:versions-maven-plugin:2.5:display-dependency-updates
The plugin itself decides if it can run a goal on its own or if it requires a running reactor and only works within the maven life-cycle (usually because it depends on outputs from other phases)
So in your case: mvn install should not run the pmd plugin anymore if its not in the pom - and install is a phase. mvn pmd:pmd will run it directly with its default config - since pmd:pmd is a plugin goal.
The default plugins per packaging and phase are documented here. These may run if in the pom or not (depending on whats in the project).
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