Currently we are using an Sonar On-Premise installation. (7.9.3.X)
We send our Sonar Analysis via the maven goal "mvn sonar:sonar" to our Sonar Server. We have the Server URL and the authentication configured in our .m2/settings.xml.
If I am triggering the goal it does not select the Quality Profiles for Java.
[INFO] Load quality profiles
[INFO] Load quality profiles (done) | time=62ms
[INFO] Load active rules
[INFO] Load active rules (done) | time=1159ms
[INFO] Indexing files...
[INFO] Project configuration:
[INFO] 1 file indexed
[INFO] 0 files ignored because of scm ignore settings
[INFO] Quality profile for xml: Sonar way
I tried to set:
<sonar.java.binaries>target/classes</sonar.java.binaries>
For testing the "Findbugs" Way
<sonar.sources>src/main/</sonar.sources>
for testing the "Sonar Way"
and the deprecated Setting
<sonar.language>java</sonar.language>
but the configuration does not Scan for Java Files.
The current sonar properties I set are:
<sonar.host.url>https://sonar:9000</sonar.host.url>
<sonar.login>secrettoken</sonar.login>
<sonar.projectName>myproject</sonar.projectName>
<sonar.sources>.</sonar.sources>
In other Projects Scanning for Java files succeed.
In my effective Pom of the Project ("mvn help:effective-pom") I cannot found any exclusions nor a language "preselection".
What am I missing? Anyone else faced this Problem?
Thanks for your help!
Try with this
<sonar.sources>UTF-8</sonar.sources>
<sonar.sources>.</sonar.sources>
I'm trying to install a module to local repository so that I can call its classes in another module.
IDEA shows me that the install process has been successfully done.
[INFO] --- maven-install-plugin:2.4:install (default-install) # commonJT808 ---
[INFO] Installing E:\学习测试\GpsTransferTest\commonJT808\target\GpsTest.jar to C:\Users\ASUS\.m2\repository\com\test\commonJT808\1.0-SNAPSHOT\commonJT808-1.0-SNAPSHOT.jar
[INFO] Installing E:\学习测试\GpsTransferTest\commonJT808\pom.xml to C:\Users\ASUS\.m2\repository\com\test\commonJT808\1.0-SNAPSHOT\commonJT808-1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
And I have verify in my local repo, [files][1] exist.
However when I try to use it in another module, it doesn't work. The IDE gives me a tip like "failed to read artificat descriptor for commonJT808:jar:1.0-SNAPSHOT".
How can I solve it?
In Jenkins, I have a Maven project with the following structure:
x proftaakmaven
- AutosimulatieSysteem
- LandenMonitoringSysteem
- PolitieSysteem
x Verplaatsingssysteem
- VerplaatsingREST
- VerplaatsingSOAP
- VerplaatsingCommon
- VerplaatsingenRabbitMQ
- RabbitMQ-Proof-of-Concept
- VerplaatsingenRabbitMQTestClient
The Maven reactor constructs this building order:
[INFO] Reactor Build Order:
[INFO]
[INFO] AutoSimulatie
[INFO] LandenMonitorSysteem
[INFO] PolitieSysteem
[INFO] VerplaatsingenSysteem
[INFO] VerplaatsingenCommon
[INFO] VerplaatsingenREST
[INFO] VerplaatsingenSOAP
[INFO] RabbitMQ-Proof-of-Concept
[INFO] VerplaatsingenRabbitMQ
[INFO] VerplaatsingenRabbitMQTestClient
[INFO] proftaakmaven
However, due to a current failure in 'LandenMonitorSysteem' source code, Maven fails on building the other modules as well. This makes the Jenkins job fail.
I have tried running Maven with --fail-never and --fail-at-end. But neither seem to have any effect.
How would I be able to continue building all the modules, even if one fails?
Thanks.
--fail-at-end should be the thing to use.
If that doesn't work you could use -pl to specify the list of working projects.
If you use the -am flag as well you can specify the target you are interested in building and Maven will calculate the dependency tree for you.
I.E. mvn clean install -pl VerplaatsingenRabbitMQTestClient -am
I have found the solution. The problem was the way that I provided the argument. In Jenkins 2.0, the job should be configured like this :
The settings inside the job
I am trying to understand what mvn clean:clean actually does.
mvn -B help:describe -Dcmd=clean
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building sample-one 1.0.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-help-plugin:2.2:describe (default-cli) # sample-one ---
[INFO] 'clean' is a lifecycle with the following phases:
* pre-clean: Not defined
* clean: org.apache.maven.plugins:maven-clean-plugin:2.5:clean
* post-clean: Not defined
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.689 s
[INFO] Finished at: 2015-12-10T10:20:16-08:00
[INFO] Final Memory: 9M/245M
[INFO] ------------------------------------------------------------------------
It appears to me that mvn clean:clean is same as doing mvn org.apache.maven.plugins:maven-clean-plugin:2.5:clean. Therefore I am assuming the first clean in mvn clean:clean is just an alias for org.apache.maven.plugins:maven-clean-plugin:2.5. Similarly mvn maven-surefire-plugin:2.12.4:test is same as mvn surefire:test.
So somehow, maven-surefire-plugin:2.12.4 seems to refer to surefire and org.apache.maven.plugins:maven-clean-plugin:2.5 to clean.
When I look at the effective-pom, I see the following
maven-surefire-plugin
2.12.4
default-test
test
test
maven-clean-plugin
2.5
default-clean
clean
clean
As you can see, the pom doesnt seem to define alias. So following are my questions
Is my understanding about plugin aliases correct
If my understanding about aliases is correct - a) how and where are they defined? b) Is there a way to list all aliases.
From official Maven documentation about plugins development:
Shortening the Command Line
There are several ways to reduce the amount of required typing:
If you need to run the latest version of a plugin installed in your local repository, you can omit its version number. So just use mvn sample.plugin:hello-maven-plugin:sayhi to run your plugin.
You can assign a shortened prefix to your plugin, such as mvn hello:sayhi. This is done automatically if you follow the convention of using ${prefix}-maven-plugin (or maven-${prefix}-plugin if the plugin is part of the Apache Maven project). You may also assign one through additional configuration - for more information see Introduction to Plugin Prefix Mapping.
Finally, you can also add your plugin's groupId to the list of groupIds searched by default. To do this, you need to add the following to your ${user.home}/.m2/settings.xml file:
<pluginGroups>
<pluginGroup>sample.plugin</pluginGroup>
</pluginGroups>
At this point, you can run the mojo with mvn hello:sayhi.
So, alias are not defined in the pom file but part of built-in mechanism of maven. Further details are also provided in the official documentation about Plugin Prefix Resolution.
Is there a Maven plugin that allows you to check if there are newer versions of dependencies available in the repository?
Say, you are using dependency X with version 1.2. Now a new version of X is released with version 1.3. I'd like to know, based on the dependencies used in my project, which dependencies have newer versions available.
The Maven Versions plugin and it's display-dependency-updates mojo are what you're looking for:
mvn versions:display-dependency-updates
Here is what the output looks like:
[INFO] ------------------------------------------------------------------------
[INFO] Building Build Helper Maven Plugin
[INFO] task-segment: [versions:display-dependency-updates]
[INFO] ------------------------------------------------------------------------
[INFO] [versions:display-dependency-updates]
[INFO]
[INFO] The following dependency updates are available:
[INFO] org.apache.maven:maven-artifact ........................ 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-plugin-api ...................... 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-project ....................... 2.0.2 -> 2.0.9
[INFO] org.codehaus.plexus:plexus-utils ....................... 1.1 -> 1.5.6
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri Aug 15 10:46:03 IST 2008
[INFO] Final Memory: 10M/167M
[INFO] ------------------------------------------------------------------------
If you want to receive email notifications when newer artifacts versions are available on Maven Central you can create an account on artifact-listener and choose which artifact you want to follow.
You can either search manually for artifacts or directly upload your pom.xml.
You will periodically received notifications like this one (available in english and french for now) :
In projects with a large number of dependancies, you sometimes keep your versions in a properties section.
<properties>
<assertj.version>3.15.0</assertj.version>
<aws-sdk.version>1.11.763</aws-sdk.version>
<cxf.version>3.3.6</cxf.version>
In the case where you are only interested in updates to those versions, you can use the following command
mvn versions:display-property-updates
This gives a more condensed view and only returns the versions you need to update in the properties section.
The VersionEye Maven Plugin is doing the same: versioneye_maven_plugin.
VersionEye can notify you about new versions on Maven Repositories, too. It is a language agnostic tool and beside Java it supports 7 other languages. Beside the simple follow/notify feature it can also directly monitor GitHub and BitBucket repositories and notify your about out-dated dependencies in your projects.
There is also a REST JSON API, for tool integrations.
By the way, I'm the dude who started this project. Let me know if you have questions.
The ideal way to do it is to set dependency versions as properties in pom.xml and then running the below command to get the updated versions for your specific/custom dependencies.
<properties>
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<skip.tests>true</skip.tests>
<spring-cloud-gcp.version>1.2.3.RELEASE</spring-cloud-gcp.version>
<spring-cloud.version>Hoxton.SR6</spring-cloud.version>
<spring-cloud-stream-schema.version>2.2.1.RELEASE</spring-cloud-stream-schema.version>
<confluent.version>5.5.1</confluent.version>
<avro.version>1.10.0</avro.version>
<janino.version>3.1.2</janino.version>
<swagger.version>2.9.2</swagger.version>
<google-cloud-logging-logback.version>0.118.1-alpha</google-cloud-logging-logback.version>
<spring-cloud-stream-binder-kafka.version>3.0.6.RELEASE</spring-cloud-stream-binder-kafka.version>
</properties>
mvn versions:display-property-updates
[INFO] The following version properties are referencing the newest available version:
[INFO] ${avro.version} .............................................. 1.10.0
[INFO] ${spring-cloud-stream-schema.version} ................. 2.2.1.RELEASE
[INFO] ${janino.version} ............................................. 3.1.2
[INFO] The following version property updates are available:
[INFO] ${spring-cloud-gcp.version} .......... 1.2.3.RELEASE -> 1.2.5.RELEASE
[INFO] ${google-cloud-logging-logback.version} 0.118.1-alpha -> 0.118.2-alpha
[INFO] ${spring-cloud-stream-binder-kafka.version} 3.0.6.RELEASE -> 3.0.8.RELEASE
[INFO] ${confluent.version} ................................. 5.5.1 -> 6.0.0
[INFO] ${swagger.version} ................................... 2.9.2 -> 3.0.0
[INFO] ${spring-cloud.version} .................... Hoxton.SR6 -> Hoxton.SR8
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.572 s
[INFO] Finished at: 2020-10-06T09:35:08-07:00
[INFO] ------------------------------------------------------------------------
Another way to achieve this is by executing the command mvn versions:display-dependency-updates but the problem I face with this approach is that it also shows me updates for the nested dependencies which are not too useful for me.
You can use the Versions Maven Plugin[1] to generate reports in your Maven site to get a list of possible updates. With regard to Spring's irregularity, it appears to use the Mercury versioning system[2]. When configuring the Versions plugin, you can add a special rule for Spring stuff:
http://mojo.codehaus.org/versions-maven-plugin/
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges
I might be a bit late to join the party but a more clear way to get more readable html file or a xml file as report which can be taken for further automation using:
mvn versions:dependency-updates-report
This report plugin not just shows more comprehensive details on updates but also has options to update to latest versions. You can find the documentation for it to use various parameters.
You can use Maven Check, a command line tool, which is standalone unlike the Versions Maven Plugin. It also works with Gradle projects.
Output example:
2 build file(s) found, checking for artifact updates
my-gradle-project\build.gradle
[COMPILE ONLY] com.google.guava:guava 31.0-android -> 31.1-android
1 artifact update(s) available
my-maven-project\pom.xml
[DEPENDENCY] org.apache.commons:commons-lang3 3.10 -> 3.12.0
[BUILD PLUGIN] org.apache.maven.plugins:maven-compiler-plugin 3.10.0 -> 3.10.1
2 artifact update(s) available
2/2 build file(s) checked, 3 artifact update(s) available
Disclaimer: I am the author of Maven Check.