How can I configure my sonarqube analysis to ignore my getters and setters and not count them as duplicated line. Because I have them both on my entites and on my DTO class. So the duplications % is up to 15%.
Thanks in advance.
Unfortunately, sonar do not provide many rules about getter/setter :
You can configure which files will be reviewed by sonarqube. This could be an exclusion by package or by class name.
For instance, you can exclude com.company.business.plip.dto by adding this to your sonar-project.properties :
sonar.exclusions=src/main/java/com/company/business/plip/dto/**
Considering your dto are just empty shells, containing only privated fields and getters/setters ; this wouldn't cause a huge impact to your code coverage.
You can set exclusions specifically for duplications using this:
sonar.cpd.exclusions=src/main/java/com/company/business/plip/dto/**
Related
I found a rule that makes sure JavaDoc's exist for public methods -> "Public types, methods and fields (API) should be documented with Javadoc", however, it doesn't appear to validate the param names are correct. For example, the JavaDoc below should fail because 'badName' does not match 'aParam'. Is there another rule I can use to validate JavaDoc's are documented correctly?
/**
* #param badName String
*/
public void myMethod(String aParam) {}
There are no rules in the SonarJava plugin that validate JavaDoc parameter names. Searching for all available Java rules, there are only three that are directly related to JavaDoc:
Deprecated elements should have both the annotation and the Javadoc tag
Public types, methods and fields (API) should be documented with Javadoc
Packages should have a javadoc file 'package-info.java'
However, if you install the Checkstyle plugin, you get some more Javadoc rules that may be close enough to what you are looking for. Here are some of their JavaDoc checks:
JavadocMethod: Checks the Javadoc of a method or constructor.
JavadocPackage: Checks that all packages have a package documentation.
JavadocParagraph: Checks Javadoc paragraphs.
JavadocStyle: Custom Checkstyle Check to validate Javadoc.
JavadocTagContinuationIndentation: Checks the indentation of the continuation lines in at-clauses.
JavadocType: Checks the Javadoc of a type.
JavadocVariable: Checks that a variable has Javadoc comment.
I'm making a REST API and I would like to add at the class generation the Jackson annotation to ignore null fields, so I would like to add this annotation onfly for certain classes, not for the hole project.
I know that this could be acomplished by adding in application.properties the following line :
spring.jackson.default-property-inclusion=non_null
But this is for entire project.
I see that there are some ".mustache" files
- api.mustache
- apiController.mustache
I supose that I have to add some code in one of this one, or should I insert some code in application.yml ?
I'm also using Spring Boot with Swagger-codgen.
Thank you in advance and have a nice day!
Ok, after few hours of research I found that because I'm using Swagger-codegen I have to search in https://github.com/swagger-api/swagger-codegen for all answers regarding Swagger-Codegen. Here are all the templates and I found that I need to add to my project the following two files
pojo.mustache
xmlAnnotation.mustache
The path where you can find the above files is
swagger-codegen/modules/swagger-codegen/src/main/resources/JavaSpring/
More than that, those files are simple templates to generate your Pojo classes, so you need to add the #JsonInclude(JsonInclude.Include.NON_NULL) annotation in the pojo.mustache file, above the line with public class {{classname}} {{#parent}}extends {{{parent}}}{{/parent}}... in order to be inserted when you generate pojo classes.
And done, build your project again! :)
You can try to set below proprty in application.yaml
spring.jackson.default-property-inclusion = NON_NULL
This worked for me to filter out null values from response.
I'm using SQ 6.0 and I have some POJOs which are (de)serialized by Spring/Jackson. For immutability reasons all members are passed to the constructor, so SQ complains with "Constructor has X parameters, which is greater than 7 authorized".
Since the constructor is annotated with #JsonCreator the number of arguments should imho be ignored, is there a way to configure this?
In your case would indeed make sense to have a way to exclude those constructors the same way constructors with #RequestMapping annotation are automatically excluded : https://jira.sonarsource.com/browse/RSPEC-2415. The short answer is no, there is no way. I'm going to open a thread on the SonarQube mailing list on this subject to see what we could do at mid-term.
I have two Maven projects, one called project-data and the other one call project-rest which has a dependency on the project-data project.
The Maven build is successful in the project-data project but it fails in the project-rest project, with the exception:
Caused by: org.hibernate.DuplicateMappingException: duplicate import: TemplatePageTag refers to both com.thalasoft.learnintouch.data.jpa.domain.TemplatePageTag and com.thalasoft.learnintouch.data.dao.domain.TemplatePageTag (try using auto-import="false")
I could see some explanation here: http://isolasoftware.it/2011/10/14/hibernate-and-jpa-error-duplicate-import-try-using-auto-importfalse/
What I don't understand, is why this message does not occur when building the project-data project and occurs when building the project-rest project.
I tried to look up in the pom.xml files to see if there was something in there that could explain the issue.
I also looked up the way the tests are configured and run on the project-rest project.
But I haven't yet seen any thing.
The error is basically due to the fact that the sessionFactory bean underlies two entities with the same logical name TemplatePageTag :
One lies under the com.thalasoft.learnintouch.data.jpa.domain package.
The other under the com.thalasoft.learnintouch.data.dao.domain.
Since this fall to an unusual case, you will have Hibernate complaining about the case. Mostly because you may run in eventual issues when running some HQL queries (which are basically entity oriented queries) and may have inconsistent results.
As a solution, you may need either to:
Rename your Entity beans with different name to avoid confusion which I assume is not a suitable solution in your case since it may need much re-factoring and can hurt your project compatibility.
Configure your EJB entities to be resolved with different names. As you are configuring one entity using xml based processing and the other through annotation, the schema is not the same to define the entities names:
For the com.thalasoft.learnintouch.data.jpa.domain.TemplatePageTag entity, you will need to add the name attribute to the #Entity annotation as below:
#Entity(name = "TemplatePageTag_1")
public class TemplatePageTag extends AbstractEntity {
//...
}
For the com.thalasoft.learnintouch.data.dao.domain.TemplatePageTag, as it is mapped using an hbm xml declaration, you will need to add the entity-name attribute to your class element as follows:
<hibernate-mapping>
<class name="com.thalasoft.learnintouch.data.dao.domain.TemplatePageTag"
table="template_page_tag"
entity-name="TemplatePageTag_2"
dynamic-insert="true"
dynamic-update="true">
<!-- other attributes declaration -->
</class>
</hibernate-mapping>
As I took a look deeper into your project strucure, you may need also to fix entity names for other beans as you have been following the same schema for many other classes, such as com.thalasoft.learnintouch.data.jpa.domain.AdminModule and com.thalasoft.learnintouch.data.dao.domain.AdminModule.
This issue could be fixed by using a combination of #Entity and #Table annotations. Below link provides a good explanation and difference between both.
difference between name-attribute-in-entity-and-table
I have converted a simple Spring project made with pure aop namespace xml coding to the same project but using annotations this time.
I've noticed that now the before-part of the around advice comes out before the before advice, which is the exact opposite behavior of the project's result when I was using aop namespace xml coding.
Is it the default behavior of the annotation style?
See Advice ordering:
When two pieces of advice defined in different aspects both need to run at the same join point, unless you specify otherwise the order of execution is undefined. You can control the order of execution by specifying precedence. This is done in the normal Spring way by either implementing the org.springframework.core.Ordered interface in the aspect class or annotating it with the Order annotation. Given two aspects, the aspect returning the lower value from Ordered.getValue() (or the annotation value) has the higher precedence.
Since the ordering is undefined, it could possibly vary even between multiple executions (having the same xml config).