Is there any way to disable certain metrics from selected packages in Sonar? I use Sonar to analyze my project and in Entity and DTO packages I have some code that is equal - the same field ID with annotations, etc is being reported as a duplication by Sonar. It has absolutely no sense to me so I'd like to disable it. How can I achieve this? Using the global exclusions option disables all metrics on selected package but how to do it just for code duplications?
With a newer SonarQube installation, you can use sonar.cpd.exclusions to exclude certain files only from duplicate checks.
See: https://docs.sonarqube.org/latest/analysis/analysis-parameters/
Example:
sonar.cpd.exclusions=**/AssemblyInfo.cs,**/*.g.cs,**/Mappings/*.cs
You can exclude resources using the standard "sonar.exclusions" parameter or use the Switch Off violation plugin to exclude "Duplicated code" violations.
Note that the 2nd option (use of the switch off plugin) works only if you're using the SQALE plugin, which embeds the "sqale-java:DuplicatedBlocksCheck" rule.
For me works its:
<sonar.cpd.exclusions>
com.simulate.java.dto\**
<\sonar.cpd.exclusions>
I have mult modules java projects just like that:
- parent
-- project-a
-- project-b
-- project-c
in the pom.xml of parent project inside of tag <properties> i put:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
<sonar.cpd.exclusions>
com.simulate.java.vo\**,
com.simulate.java.dto\**
<\sonar.cpd.exclusions>
<\properties>
Just like that. I hope I helped you.
You can add these files to the properties in your pom.xml:
This one is to exclude from code coverage:
<sonar.coverage.exclusions>
your file paths
</sonar.coverage.exclusions>
This one is to exclude from code duplication:
<sonar.cpd.exclusions>
your file paths
</sonar.cpd.exclusions>
Related
I have two services A and B which placed in monorepo in different maven modules, also they have Aggregate pom.xml which contains the next modules:
<modules>
<module>A</module>
<module>B</module>
</modules>
Both services are talking through gRPC and have common protocol which described in the proto files.
The grpc-java manual says, that I must put my proto files into src/main/resourses/proto folder.
It means I have to copy the same proto files bewteen two services:
A/src/main/resourses/proto/somefile.proto
B/src/main/resourses/proto/somefile.proto
Which is code duplication actually.
The main question - How can I share and compile proto files between two maven modules in monorepo?
I have done the next:
Created the separate library which contains only proto files. Let's call it C.
Added C dependency to A and B modules.
Aggregated pom.xml looks like:
<modules>
<module>C</module>
<module>A</module>
<module>B</module>
</modules>
The approach seems quite havy for that case and I don't want to have a separate maven module for that.
Moreover, I will definetley face with a problem, if I use different language for B service (something other than java and maven).
Is there a known solution for this problem? Can I share protofiles without separate library/module? Any examples appreciated.
I've been wrong with
The grpc-java manual says, that I must put my proto files into
src/main/resourses/proto folder.
We can set protoSourceRoot configuration for grpc-java plugin. We can specify any required proto source folder as follows:
<protoSourceRoot>${basedir}/../proto</protoSourceRoot>
It means no need in separate maven module and library.
I have a multi module maven project, and in the dao module, I added the JSON-IO dependency. When I try to deserialize my object, it gives me:
Exception in thread "main" com.cedarsoftware.util.io.JsonIoException: Class listed in #type [hu.kleatech.projekt.model.Employee] is not found
The class name is correct, the Employee is public, and the dao has the module as dependency. What could have gone wrong?
Edit: Since this is an old question and have been answered long ago, I'm deleting the github repository that I made specifically for this question. The solution to the problem is in the accepted answer, the exact code is not relevant.
Please try adding an empty constructor to Employee class.
Edit: Actually, while adding an empty constructor solves the problem, it is not necessarily required. Json-IO "will make a valiant effort to instantiate passed in Class, including calling all of its constructors until successful. The order they tried are public with the fewest arguments first to private with the most arguments."
(copied from MetaUtils.java javadoc)
Also, when calling a multi-argument constructor, the library fills the arguments with nulls and defaults for primitives. Then any exceptions thrown during the constructor call is ignored. In your case, a NullPointerException was thrown, because the constructor is not null-safe. So either modify the constructor so that it can handle nulls, or add an empty constructor.
Maven dependency configuration is hierarchical from <parent> element not from <modules> element.
It means that in the project's pom.xml file where you have dependency on "JSON-IO dependency" you do not have dependency on your dao project or where that class is.
<modules> stands only to define what projects to build. Order of modules definition does not matter, since Maven detects order by required dependencies
So, you can define dependency in <parent> pom.xml either in
<dependencies> element. then all children will have it.
or in <dependencyManagement> - then children who need it can include it in their <dependencies> without common configurations like version, scope etc...
look at quite similar answer here:
How to minimize maven pom.xml
As per your project and modules Pom your main Pom should have modules in following order ....
<modules>
<module>core</module>
<module>controller</module>
<module>service</module>
<module>dao</module>
</modules>
service depends on core so core should be build before service
dao depends on service and core both so dao should be after core and service.
Employee class is available in core and it should be available in core jar.
You should add depencyManagent in main Pom and then add all the module as dependencies in dependencyManagement so whoever adds your main Pom as dependency will be able to access all your jars.
Once you change order build your project again and then update your maven project.
If this code is being used in another project then make sure that you have uploaded jars to repository (mvn deploy) so whoever uses it can download it when they are building their project.
One way to verify whether this jar is downloaded in the main project where it is used or not is check in project explorer there would be a Maven Dependencies section where you can see all dependency jars and check if core is present or not.
I am not sure what controller module is doing in main Pom as I couldn’t find a module by that name in your project so you should either remove it or add a module (folder) for it.
I have a maven project, and in the pom.xml I set properties as such:
<project>
<modelVersion>4.0.0</modelVersion>
<artifactId>myArtifact</artifactId>
<name>SomeProject</name>
<packaging>jar</packaging>
<properties>
<some-system-property>1.9.9</some-system-property>
</properties>
<...>
</project>
I want to pull the some-system-property value from within the java code, similar to
String someSystemPropery = System.getProperty("some-system-property");
But, this always returns null. Looking over StackOverflow, most of the answers seem to revolve around enhanced maven plugins which modify the code - something that's a nonstarter in my environment.
Is there a way to just get a property value from a pom.xml within the codebase? Alternatively, can one get the version of a dependency as described in the pom.xml (the 1.9.9 value below):
<dependencies>
<dependency>
<groupId>org.codehaus.jackson</groupId>
<artifactId>jackson-mapper-asl</artifactId>
<version>1.9.9</version>
</dependency>
</dependencies>
from code? Either one would solve my needs
Those are Maven properties that apply during the build, not runtime system properties. One typical approach is to use Maven resource filtering to write the value into a properties file in the target directory.
Maven properties and not system properties.
Generally you should set the system property for a maven plugin that is triggering the execution:
surefire for unit tests,
exec for execution,
jetty or similar for starting a web container
There is also properties maven plugin than can set properties:
http://mojo.codehaus.org/properties-maven-plugin/set-system-properties-mojo.html
Property values are accessible anywhere within a POM by using the notation ${X}, where X is the property, not outside. All properties accessible via java.lang.System.getProperties() are available as POM properties, such as ${java.home}, but not the other way around. So for your java code, it will need to scan the pom.xml as a xml parsing use case, but not sure why you want to do it.
In my Maven build I would like to be able to define default values (e.g. for database connection) in pom.xml, but I would like the user to be able to override these without having to modify pom.xml directly.
By way of example, in an Ant build you can define default properties in foo.properties, but Ant will look for overrides for each of these in a foo.$USERNAME.properties. The latter is generally not checked into source control, which eliminates the problem of developers accidentally committing their overrides of the default properties. Does Maven offer a similar facility?
To make the problem a bit more concrete, assume I have the following defined in pom.xml
<properties>
<db.url>jdbc:jtds:sqlserver://10.10.10.10:1433/somedb</db.url>
<db.driver>net.sourceforge.jtds.jdbc.Driver</db.driver>
<db.username>default_user</db.username>
<db.password>secret</db.password>
</properties>
Can a user override these properties without editing the pom.xml directly?
You can specify properties on the command line using -Dpropertyname=value, or the user can specify properties in their .m2/settings.xml.
You can achieve this with build profiles. See Introduction to build profiles for more information.
I used settings.xml to override these properties by adding the following to the <profiles> section
<profile>
<id>override-database-properties</id>
<activation>
<property>
<name>refreshDB</name>
</property>
</activation>
<properties>
<db.schema_name>store_don</db.schema_name>
</properties>
</profile>
In this case the overrides will only take effect if a -DrefreshDB is passed to the mvn command. To activate these overrides every time Maven is invoked also add the following to settings.xml
<activeProfiles>
<activeProfile>alwaysActiveProfile</activeProfile>
</activeProfiles>
If the profile is added to <activeProfiles> then the <activation> element should be removed.
If you don't want to add properties on the command line, but set some settings once (and if you can accept the default being empty strings); you could use environment variables like this:
<something>${env.ENVNAME}</something>
<!-- something will be blank "" unless ENVNAME is set -->
Edit: I've been trying to find a way of defining a default values for ${variable} if the variable is empty/undefined, but I've not found anything, this seems to be missing (the frequent suggestion is to use profiles but it's not quite the same).
I'd prefer if you could just set some environment variables and have sensible defaults so that you could just run mvn clean install (and not the 20-40 character strings I normally use to build our project). If default values is possible I'd love hear how...
BTW, if you're already used to Ant, I've heard that you can call Ant tasks from maven somehow (don't know how, though), maybe you could use that somehow?
I have a project that consists of several Maven modules which are all children of a parent module.
I have the parent set up to use checkstyle and the child modules all inherit this behaviour correctly. I would like all the child modules to use the parents suppression file defined in its plugin.
I define a property checkstyle.suppression which is used in the checkstyle plugin
<properties>
<checkstyle.suppressions>${basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions>
</properties>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.2</version>
<configuration>
<configLocation>config/sun_checks.xml</configLocation>
<suppressionsLocation>${checkstyle.suppressions}</suppressionsLocation>
<suppressionsFileExpression>${checkstyle.suppressions}</suppressionsFileExpression>
</configuration>
</plugin>
</plugins>
Which works fine for the parent but all the child modules try to find the file in their basedir which does make sense.
I am sure there must be a simple solution I am missing but is there a way to define this location so that all the child modules will use the parent location without hard coding it?
The answers above are dangerous. I maintain that each project should be self contained, so referring to files external to it is going to break a build sooner or later. Checkstyle can take a url for the file but that means you can't build offline. A better approach is to package your file (can also add pmd.xml) into a jar and then add that jar to the classpath of the checkstyle (or pmd) plugin. I have an example of it here and more about overridding a plugin classpath here
The plugin's documentation mentions a similar use case here:
http://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html
Have you tried defining the property like this in the parent pom or redefining it in the childrens?
<properties>
<checkstyle.suppressions>${parent.project.basedir}\src\checkstyle\suppressions.xml</checkstyle.suppressions>
</properties>
If the parent isn't going to run checkstyle, you might just be able to rewrite it to
<properties>
<checkstyle.suppressions>..\..\src\checkstyle\suppressions.xml</checkstyle.suppressions>
</properties>
Or something like this. Or you could put something in settings.xml to point everything to an system wide config directory.
While it might not be recommended, you can have use a boot-strap or set-up project or task put a copy of the suppressions.xml file to a location specified by a property in settings.xml and then always refer to it by that locations.