In Spring Boot project, I am using apache checkstyle plugin in POM as shown below:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<executions>
<execution>
<id>default-cli</id>
<goals>
<goal>check</goal>
</goals>
<phase>validate</phase>
</execution>
</executions>
<configuration>
<configLocation>google_checks.xml</configLocation>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
</configuration>
</plugin>
In Eclipse Neon.1 Release (4.6.1), I have installed Eclipse CheckStyle plugin from below path:
Eclipse CheckStyle Plugin
After fixing all Check Style issues highlighted by Eclipse plugin, when i run validate goal of maven, I still see many check style violations on the console related to import dependency reported by Maven plugin e.g.
D:\Data\Filter.java:4: warning: 'com.microsoft.aad.adal4j.AuthenticationContext' should be separated from previous import group.
D:\Data\Filter.java:39: warning: Import statement for 'org.springframework.beans.factory.annotation.Value' is in the wrong order. Should be in the 'THIRD_PARTY_PACKAGE' group, expecting not assigned imports on this line.
I want to know why eclipse plugin has not highlighted these issues while Maven plugin has reported them despite the fact both are using google_checks.xml. How to align them?
maven-checkstyle-plugin by default uses an older version of Checkstyle.
See https://maven.apache.org/plugins/maven-checkstyle-plugin/history.html (it lists 6.11.2 with maven-checkstyle-plugin version 2.17)
Depending on what version of Eclipse-CS you have installed, you could be running with 2 different versions of Checkstyle as Eclipse-CS tries to use newer versions, but may not use the latest.
Their website states:
Latest release 8.0.0, based on Checkstyle 8.0
To change the version of Checkstyle maven-checkstyle-plugin uses, see https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html .
Related
I am using DOJO toolkit and after upgrading to use the closure compiler, I noticed I needed to transpile to ES5 BEFORE the dojo build util does it's job in order to take advantage of newer ES6+ features.
So I am using babel-maven-plugin to accomplish this.
Everything is working fine with the exception that the ...spread operator is not transpiling.
Do I need to download the #babel/preset-env package as well to set the preset option? or is there an option I am missing?
After further discovery there is no need to download any preset package.
babel-standalone takes in preset options through its API as defined here and use in the babel-maven-plugin here.
The preset option is not passed to the Babel API like defined in a .babelrc config file. It is passed in without the preset- prefix. So to get the #babel/preset-env preset option you need to simply pass in env.
So to round this out, here are the common presets and how you would pass them through to the API:
#babel/preset-env --> env
#babel/preset-react --> react
#babel/preset-flow --> flow
#babel/preset-typescript --> typescript
So in order to use babel-maven-plugin I need to set up the pom.xml as follows:
<plugin>
<groupId>com.jarslab.maven</groupId>
<artifactId>babel-maven-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>js-transpile</id>
<phase>process-resources</phase>
<goals>
<goal>babel</goal>
</goals>
<configuration>
<verbose>true</verbose>
<babelSrc>./js/babel/babel.min.js</babelSrc>
<sourceDir>./js</sourceDir>
<targetDir>./js</targetDir>
<presets>env</presets>
</configuration>
</execution>
</executions>
</plugin>
I've a pretty standard Java-Maven build with some plain JUnit tests and some for Arquillian. JaCoCo is hooked via Maven like this:
<properties>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
</properties>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
<append>true</append>
</configuration>
<executions>
<execution>
<id>agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Running Sonar now seems to work, however the code coverage is all wrong. I'm not sure if these are separate issues or if there is one problem with the configuration producing all of them, so I'll just list them:
test suites are not run at all (meaning JUnit tests with #RunWith(AllTests.class))
Arquillian tests (with #RunWith(Arquillian.class)) are run, but the code coverage is wrong, i.e. entities have a code coverage of 0%
an entire module is not tested and I'm not sure why (all but one of the tests has #RunWith(Parameterized.class), but this annotation works in another module)
(After Qword's suggestion I tried it without the reportPath. However the reports in target/sites/jacoco/ are still missing the coverage.)
I'm wondering if the problem is with the JUnit runners or maybe because some of these tests are in another module than the classes they test (Arquillian / integration tests especially). On the other hand, some of the JUnit runners seem to work as well. Maybe it's a third component that breaks the build.
I tried arquillian-extension-jacoco as well, this plug-in doesn't seem to work at all (tests won't even start).
Is the problem with the JUnit runners? With the integration tests? How do I fix this?
You don't actually need to specify sonar.jacoco.reportPath. First of all, it's been deprecated in favor of sonar.jacoco.reportPaths. Second, if you specify the latter property, all reports will be created in a single binary file, but this is not default Jacoco behaviour (and SonarQube deprecated that as well).
I would suggest, as a first step, to
Entirely remove properties sonar.jacoco.reportPath and sonar.jacoco.reportPaths
Remove the configuration node from Jacoco plugin definition
Now, you'll won't find anymore the jacoco.exec file but instead for every module you'll find a new directory target/sites/jacoco in which there will be reports in CSV, XLM, and HTML. This is the standard Jacoco behaviour in v0.8.4.
I'm not entirely sure this will fix all your problems, but at least
I'm quite sure SonarQube will be able to correctly pick up the reports and show the coverage
You'll be able to analyse coverage with a simple mvn clean install on your local machine without having to go to SonarQube every time
I'm struggling getting the F8 CD-Pipeline to work on OpenShift. I use a Jenkinsfile downloaded from the F8 Jenkinsfile Library for Maven builds with steps "CanaryReleaseAndStage". The stage deploy step there looks like the following:
stage('Rollout Staging') {
kubernetesApply(environment: envStage)
}
I looked up the implementation of kubernetesApply() from the Kubernetes Pipeline Plugin. If no file parameter is present in the call (like here) it applies the Kubernetes/OpenShift resources defined in file "target/classes/META-INF/fabric8/openshift.yml", which is generated upon build.
In this file (which is also uploaded as artifact to the nexus, so I can easily fetch it) there are three resources defined:
A Service
A Deployment config, containing a Docker image reference (without tag), also containing a ConfigChange trigger listening for an ImageStreamTag 'my-project:latest'
A Route
... but no ImageStream. However on the build log I see that an image stream definition apparently got generated on a different file:
[INFO] F8: Found tag on ImageStream my-project tag: sha256:c15b56841387a7e0aea960020ccf2efb48f21bd4d12d826e2cd04a94f4d9d748
[INFO] F8: ImageStream my-project written to /home/jenkins/workspace/my-project-dir/target/my-project-is.yml
But I'm afraid that one never gets applied to Kubernetes. Hence there is no image stream in the staging project.
In this configuration the staging deployment cannot even deploy the pod. If I add an image stream manually to the staging project it deploys but is never updated when new builds occur.
I've updated to the newest fabric/jenkins image 2.2.331, but it also does not seem to work here.
My pom.xml (parts essential for f8 building):
<project ...>
<modelVersion>4.0.0</modelVersion>
<groupId>my.package</groupId>
<artifactId>myproject/artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<fabric8.mode>openshift</fabric8.mode>
<fabric8.build.strategy>docker</fabric8.build.strategy>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>io.fabric8</groupId>
<artifactId>fabric8-maven-plugin</artifactId>
<version>3.2.28</version>
<configuration>
<images>
<image>
<name>fabric8/my-project</name>
<build>
<dockerFileDir>${project.basedir}/src</dockerFileDir>
<dockerFile>Dockerfile</dockerFile>
</build>
</image>
</images>
</configuration>
<executions>
<execution>
<goals>
<goal>resource</goal>
<goal>build</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
So I'd like to know:
How is the CD pipeline supposed to work regarding updates to the staging deployments here?
Why is this image stream definition created if it is not applied. Am I missing some configuration here maybe.
Thanks for any insight!
Any chance of seeing your pom.xml and full build? It sounds like you are using fabric8-maven-plugin right? Its doing a S2I binary build and generating an image stream? It just sounds like somethings going wrong and the generated image stream isn't being included in your target/classes/META-INF/fabric8/openshift.yml maybe?
I wonder if something is going wrong in the order of your maven goals or something (e.g. typically fabric8:resource is first, then fabric8:build which then adds the ImageStream into the generated YAML files)
I am attempting to do a release via the Maven release plugin and am having issues with the SCM config. I am using Eclipse with m2eclipse installed. We use Mercurial and on my machine (Win7) I have TortoiseHg installed. I have a test project that creates a jar. We make use of a super pom for our projects, so the test project pom does as well. I have set up this in the super pom:
<build>
<plugins>
....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scm-plugin
<version>1.6</version>
<configuration>
<connectionType>connection</connectionType>
</configuration>
</plugin>
</plugins>
</build>
My test project pom looks like this:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>my.group</groupId>
<artifactId>TestJar
<version>1.0-SNAPSHOT</version>
<parent>
<groupId>my.group</groupId>
<artifactId>super-pom</artifactId>
<version>1.0</version>
</parent>
<scm>
<connection>
scm:hg:ssh://our.scm.server:22//path/to/TestJarProject
</connection>
<developerConnection>
scm:hg:ssh://our.scm.server:22//path/to/TestJarProject
</developerConnection>
</scm>
</project>
Note that we ssh to our SCM server. I suspect some of the issues I'm encountering my be related to this. I've only been able to find examples that use http.
In my settings.xml file, I added this:
<servers>
...
<server>
<id>our.scm.server</id>
<username>username</username>
<password>password</password>
</server>
</servers>
When I run release:prepare release:perform, a TortoisePlink dialog pops up prompting me for a password. The dialog box is asking of "#our.scm.server's password".
It appears it is not using the username or password from the settings.xml file which is what I was expecting by adding the server element to it. Should it be? I have also tried adding my username to the connection url:
<connection>
scm:hg:ssh://username#our.scm.server:22//path/to/TestJarProject
</connection>
but am still prompted for an empty username's password.
QUESTION ONE
Has anyone successfully used ssh to connect to Mercurial while doing Maven releases?
Since I ultimately want to do the builds in Hudson, I set up a Hudson job to do the release but it fails with this error:
[INFO] o.h.m.e.h.MavenExecutionResultHandler - Build failed with exception(s)
[INFO] o.h.m.e.h.MavenExecutionResultHandler - [1] org.apache.maven.lifecycle.\
LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:\
maven-release-plugin:2.0:prepare (default-cli) on project TestJar: Cannot \
prepare the release because you have local modifications :
[.maven/repo/ca/shaw/eng/nms/nms-super-pom/1.0/_maven.repositories:unknown]
[.maven/repo/ca/shaw/eng/nms/nms-super-pom/1.0/nms-super-pom-1.0.pom:unknown]
[.maven/repo/ca/shaw/eng/nms/nms-super-pom/1.0/nms-super-pom-1.0.pom.sha1:unknown]
... many, many more lines of this nature .....
QUESTION TWO
What local modifications is Maven encountering?
Since the project is being pulled from the repo, the only change I can think of is the update to the pom file (removing SNAPSHOT from the version). But Maven shouldn't be complaining about this since it made the change itself, no?
UPDATE
As per khmarbaise's suggestion, I've added this to my parent POM:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
</plugin>
</plugins>
</pluginManagement>
QUESTION ONE
Has anyone successfully used ssh to connect to Mercurial while doing Maven releases?
The answer appears to be that the Maven Release Plugin only works with https. We were able to get https working on our Mercurial server by generally following the instructions on this page:
https://www.mercurial-scm.org/wiki/HgWebDirStepByStep
QUESTION TWO
What local modifications is Maven encountering?
The local modifications are the .maven directory that is created during the build. By adding .maven/* to my .hgignore file, I was able to complete the build.
I am unable to reproduce this right now, but from earlier experience I remember that ssh connections only work with key-based authentication, not with usernames and passwords. This is not necessarily specific to the release plugin and/or its Mercurial support.
EDIT: I have tried key-based ssh access with Mercurial and the release plugin version 2.4.1 today, and it works nicely. One possible source of problems is the SCM URL format. In my case it's:
scm:hg:ssh://user#hostname.com/path
So the answer to your question one is: yes, but not with username/password authentication. I did not encounter any "local modifications" problem, but I have target in my .hgignore so that might be it.
We develop multiple branches of a project concurrently. Each developer has multiple working copies, each working copy uses its own DB schema. (There will typically be a working copy per branch, but sometimes even more than one working copy per branch.) We need to let Maven know the DB credentials (for the db-migration plugin, for unit tests, for the dev instance of the servlet).
We can't put the credentials in the pom.xml because each developer might use different DB schema names. We can't put the credentials in settings.xml because each developer uses more than one schema.
Where do we put the credentials?
For example, http://code.google.com/p/c5-db-migration/ describes that the DB credentials need to be present in pom.xml but I would like to externalize them out to a file that's not under revision control.
You could put them into a properties file inside the project directory but which is excluded from source control.
With Maven it's possible to read properties from an external file by using a <build><filters><filter> element as instructed here.
Read following answers:
How to read an external properties file in Maven
Reading properties file from Maven POM file
Read a file into a Maven property
or just:
<project>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
</execution>
<configuration>
<files>
<file>dev.properties</file> <======== IT IS!!!!!
</files>
</configuration>
</executions>
</plugin>
</plugins>
</build>
</project>