Latest Jacoco plugin (still in snapshot version, 0.7.10-SNAPSHOT), has a nice new feature to filter out the Lombok generated code (https://github.com/jacoco/jacoco/wiki/FilteringOptions).
All we need to do is add a lombok.config file at the root of the repository with:
lombok.addLombokGeneratedAnnotation=true
When I generate the Jacoco report internally, I see the difference.
However, when my regular quality job executes and publishes the result to Sonar, I get different (ie worse) results.
How come I don't have the same results in my local report and in Sonar? Is there any workaround?
As mentionned here : https://github.com/jacoco/jacoco/pull/513#issuecomment-293176354
filtering is performed at a time of report generation (creation of html, xml, etc), not at a time of collection of execution information (creation of exec file). So that tools that read execution data directly instead of reading of xml (which is a kind of mistake on their side to rely on purely internal intermediate format, but what's done is done) and create their own report (such as SonarQube, Jenkins, etc) will need to update their dependency on JaCoCo once it will be released in order to get filtering for reports. We will notify explicitly downstream projects (in particular all mentioned above) about this when our release will be done. So once again - please be patient. Thank you for your understanding.
I didn't find a way for Sonar to read the end report instead of the exec file, so I guess we need to be patient and wait for the official 0.7.10 jacoco plugin release and then an update on Sonar side !
------ UPDATE May 9th 2018
New versions have been released, and I can confirm it works for me.
Using :
Sonar 6.7
SonarJava plugin 5.1.1.13214
jacoco maven plugin 0.8.1
lombok.addLombokGeneratedAnnotation=true in lombok.config
I now get much better coverage results reported to Sonar, as Lombok generated code is now ignored. It really helps identifying what the "real" uncovered areas are, and whether it's risky or not.
First you have to check your lombok version is at least 1.16.14
pom.xml:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<scope>provided</scope>
<version>1.16.14</version>
</dependency>
Then you have to check that your Jacoco version is at least 0.8.0
pom.xml:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.0</version>
<!-- // -->
</plugin>
Then you have to add a lombok.config file in the src folder of your project (not in the resources folder)
lombok.config:
# tells Lombok that this is the root directory and that it shouldn’t search parent directories for more configuration files
config.stopBubbling = true
# tells Lombok to add #lombok.Generated annotation to all generated methods
lombok.addLombokGeneratedAnnotation = true
Related
In my maven project I want to implement dependency-locking.
One approach I've found is using dependency-lock-maven-plugin.
My project has multiple maven modules.
parent
core
service
third-maven-module
When I run mvn clean package it will generate a new core-0.0.1-SNAPSHOT.jar every time.
Now apart from checking version dependency-lock-maven-plugin also checks SHA, which in this case gets changed every time & then the plugin throws error stating SHA is different.
Now to avoid this in plugin's version 0.0.78f56707b3a1d639c8e769bba1686587e9a8956 we can simple add below lines:
<configuration>
<ignore>
<dependency>com.myservice:core:*</dependency>
</ignore>
</configuration>
It works but now I can see that this version has vulnerabilities, so I want to use the latest version 1.0
But it looks like the configuration to ignore a dependency has been changed & documentation does not says much.
Please suggest how can I ignore a dependency in dependency-lock-maven-plugin.
In my Java project, I get "java: cannot find symbol" errors pointing Metamodel classes e.g. Company_.
So, first I checked my-project\target\generated-sources\annotations and see that it is empty. Then, after several search on the web and SO, I see that the necessary settings seems to be ok and this is the first time I get this problem.
Here is corresponding settings in pom.xml:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>5.3.7.Final</version>
</dependency>
And I have already had this settings and these have not been changed:
Settings
Settings > Build execution, Deployment > Compiler > Annotation Processors > my-project (selected) :
Enable annotation processing (checked)
Obtain processors from project classpath (selected)
Store generated sources relative to: Module content root
Production sources directory: target\generated-sources\annotations
Test sources directory: target\generated-test-sources\test-annotations
I tried to rebuild project, module, etc. but there is still nothing in my-project\target\generated-sources\annotations directory. So, how can I generate these JPA Hibernate Metamodel classes in IntelliJ IDEA?
Try remove .Final from version or just use another version
I would like to be able to document the dependencies of my services directly in my code, using Java annotations. Those annotations could bear the information about the target system, whether the connection is incoming/outgoing/2-ways, and the type of connection (REST, RabbitMQ...).
It could look like this:
#Dependency(target = "Twitter API", type = "Outgoing", medium = "REST")
The idea would be to generate a DOT file from all the annotations inside the project.
I have a fair idea on how to create my own annotation, with the required attributes. However, i am not sure at which part of the lifecycle of the compilation/processing i should handle those annotations.
I understand that the annotation processors generate source files, but in my case the generated files are not at all required by the compiler nor the application itself.
Ideally i would like to be able to trigger the annotation processing, and DOT file generation, by a dedicated Maven or Gradle task.
Is it something that is easily doable when writing my own annotations?
If you want to create documentation via maven than you need add the bellow two dependencies as plugins and then execute site maven goal.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.7.1</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-project-info-reports-plugin</artifactId>
<version>3.0.0</version>
</plugin>
If you just want to document REST endpoints than you can use swagger.
If your project uses spring than the integration of swagger is pretty easy. You can use this tutorial.
If you want to save in a file the dependency graph of your project you can simply execute the following maven command.
mvn dependency:tree -Doutput=/path/to/file
Annotations are processed by the Java compiler directly.
For Maven, one can use the maven-compiler-plugin. It is also possible to perform the compilation in 2 steps, as explained here.
For Gradle, one can add the processors in the dependencies block under the annotationProcessor configuration, as explained here.
Annotation retention can be specified as SOURCE, so they won't be kept after compilation.
I want to add some tests to my camel project so I decided to create a clean project using maven and the camel-archetype-blueprint archetype to look at some samples.
Now I created the project using:
mvn archetype:generate -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-blueprint -DarchetypeVersion=2.15.3 -DgroupId=de.test - DartifactId=Testing
but without editing anything the test fails by default with this exception (building it with mvn package):
java.lang.RuntimeException: InputStream cannot be null
Is there anything else I have to do to for those tests to run?
There appears to be a bug in the camel blueprint testing dependency for 2.15.3. If you change it to another version (I tried 2.12.2 and 2.15.2) it fixes the null input stream error.
<!-- Testing & Camel Plugin -->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-test-blueprint</artifactId>
<version>2.15.2</version>
<scope>test</scope>
</dependency>
I would suggest you to try with newly released 2.15.4 version, which seems to address the issue you reported.
See CAMEL-9142 report (taken from version 2.15.4 release notes) in order to have more information:
Looks like update CAMEL-8948 dropped support for multiple blueprint descriptors within CamelBlueprintTestSupport file within camel-test-blueprint component. The symptom is a 'java.lang.RuntimeException: InputStream cannot be null' for unit tests that have a getBlueprintDescriptor with multiple file references, i.e. a '+' concatenating two or more descriptor files.
I just used maven-release-plugin to release a version, obviously :)
The scm configuration in my parent pom is as follows:
<scm>
<developerConnection>scm:svn:http:/localhost/svn/project/trunk/project/3. Implementation/02 Source code</developerConnection>
</scm>
As you can see, after trunk we have several more folders (RUP-style) before reaching the source code.
A mvn release:prepare results in the following scm configuration:
<scm>
<developerConnection>scm:svn:http://localhost/svn/project/tags/project-1.0.0/02 Source code</developerConnection>
</scm>
So, somehow, maven-release-plugin manages to replace trunk/project/3. Implementation/02 Source code with tags/project-1.0.0/02 Source code.
Why would this not be tags/project-1.0.0, as I would expect? If I would run mvn release:perform the plugin would checkout the entire 3. Implementation directory.
For reference, my plugin definition is as follows:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5</version>
<configuration>
<tagBase>http://localhost/svn/project/tags</tagBase>
</configuration>
</plugin>
</plugins>
Right, I figured out what causes this, looking at the maven-release-manager source code. When rewriting the developerConnection value, the RewritePomsForReleasePhase class calculates the number of subdirectories we need to remove from the developerConnectionUrl to get to the root of our project, based on the local project. Now there are two problems with this approach:
There is no guarantee the local depth will match the remote one. Although this may be best practice.
The working dir (from where mvn is called) does not have to be in the root of the project.
Both apply to my situation. I checked out the project two directories less deep than remote. To clarify:
http://localhost/project/3. Implementation/02 Source code was checked out to
D:\workspace\project
Also, we have a project-parent dir containing our parent pom.
So now it determines we are 1 deep by looking at the local structure (from work dir, i.e. project-parent, to project dir) and applies this to the developerConnection url. Then it does a substring on the original developerConnection with the result and ends up with 02 Source code in my case.
So long story less long: maven-release-plugin does not work as expected when the local directory structure does not match the remote one. Now I have to checkout honoring the server path and also create a new pom, or move the parent pom to the project root to get it to work...
EDIT: Moving the pom to the project base dir would probably fix the issue, leaving the developerConnection url unchanged. Will confirm this for the next release.