I am using PMD maven plugin for my project and I am seeing very strange behavior in it. The following pom.xml configuration fails the build with violations in basic.xml -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<!-- ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset-->
</rulesets>
</configuration>
But the below one passes the build smoothly -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset>
</rulesets>
</configuration>
The build should have failed in the second scenario also. As per what I have noticed, if the last rule (in above example comments.xml) does not have any code violation then the build will not break even if any of the rulesets above it (basic.xml, braces.xml, etc.) have code violations. I am unable to understand the reason behind this behavior. Can someone help me out with this?
I found the issue. There was an issue with Maven Plugin version 3.3 . Now I am using version 3.1 and the exact same code is working as expected.
Related
Problem Description
I'm working with a collection of old projects from defects4j. My problem now is that since I want to combine those projects with a newer maven plugin, a regression test tool, there are some issue with the maven surefire plugin version.
In the pom.xml that come along with the projects, there are no specifications of surefire version:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>plain</id>
<configuration>
<includes>
<include>**/*Test.java</include>
</includes>
<runOrder>random</runOrder>
</configuration>
</execution>
</executions>
</plugin>
However, the regression tool (made into a maven plugin), require surefire version of 2.14 and above. So I get error like this:
[ERROR] Failed to execute goal edu.illinois:starts-maven-plugin:1.4-SNAPSHOT:select (default-cli) on project commons-lang: Unsupported Surefire version: 2.12.4. Use version 2.13 and above
Efforts Done
I checked several stackoverflow posts, and they talked about the effective pom. When I run mvn help:effective-pom, I can see that the version of surefire used is
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
Question
Since the project collection in defects4j does not specify surefire version in their pom.xml, is there a way to specify the surefire version used to 2.14 or above from command line? I want to prevent from manually editing the pom every time.
Update
by running mvn dependency:resolve-plugins, i get
Plugin Resolved: maven-surefire-plugin-2.12.4.jar
So it seems to me that somehow maven use 2.12.4 as a default. The reason maybe that I used this version previously. How do I fix this?
Without modifying the pom manually?
Any advice will be welcomed!
Update:
Problem solved by editing maven's super pom.
Maven takes the newest version from the repository if there was no version fixed in your POM, parent POM or the super POM (from which every Maven project inherits).
It is best practise to fix a version "manually" in the POM. The best place for this is a parent POM from which the projects inherit (this means, only one place to change).
You cannot just supply a version from command line. Unless you do some tricks like putting <version>${surefire.version}</version> into the plugin definition and set this property from command line.
I'm 4+ years removed from working with poms so don't remember everything, but consider a couple of things.
First, since the pom you show isn't specifying the version of surefire to use I don't think that the 2.12.4 version can be coming from that directly. Try getting a dependency tree to see where things are coming from. Try How can you display the Maven dependency tree for the *plugins* in your project? for that and a few other suggestions.
Second, I think I recall that in your own pom you should be able to specify the version of plugin to associate with a dependency that doesn't specify one. You'll have to research that option yourself.
I think your best bet is the dependency tree to find what's using what and where things are coming from. If you get the tree and still can't figure out what to do try adding the tree output to your question. (You can edit out parts that are proprietary, or clearly unrelated.)
I'm working with a project that has, historically, been supported and developed in an Eclipse environment. I'm hoping to move this over to Intellij, and I'm currently using the full (Ultimate) package.
There are a few intricacies of the build process that don't appear to be working, which relate to selectively building the resources for the project. I could work around this, but would rather try and understand why IntelliJ and Eclipse are building the same project in a slightly different way.
I've noticed in my parent POM that the following code has an issue:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includes>
<include>**/*.js</include>
</includes>
<nosuffix>true</nosuffix>
</configuration>
</plugin>
Intellij is saying element includes is not allowed here' and itcannot resolve symbol 'include'`.
As far as I can see, the declarations are valid and in the correct place, and maven appears to be set up as required with the maven plugins installed as required too. The POM uses the http://maven.apache.org/maven-v4_0_0.xsd schema.
This kind of stuff has generally been left untouched for a number of years, but I can't see why it is having issues with this particular symbol/declaration?
As above, I've checked the plugins, Maven settings, all the usual suspects. Another of the plugins uses <excludes> with no errors, which makes it a bit more of a puzzle to me?
Can anyone help?
I have SonarqubeServer(Version 5.6.3), in which I have added two custom rules for java successfully, both are also visible in rule list.
Problem: I am also using Sonarlint for local eclipse issue. As usual their is sync issue for external plugins used by SonarqubeServer(PMD,FindBug,CHeckStyle). It is fine I have managed this.
So Now my question is that, will Sonarlint able to sync my newly added custom rules to SonarQubeServer?
if Yes then why I am not able to see those custom rule effect and reporting in eclipse classes.
Not sure about this, but i have activated Sonarlint support in pom.xml and it works for me. Here is the relevant entry, see <sonarLintSupported>:
[...]
<build>
<plugins>
<plugin>
<groupId>org.sonarsource.sonar-packaging-maven-plugin</groupId>
<artifactId>sonar-packaging-maven-plugin</artifactId>
<version>1.17</version>
<extensions>true</extensions>
<configuration>
<pluginClass>com.foobar.java.JavaRulesPlugin</pluginClass>
<sonarLintSupported>true</sonarLintSupported>
<sonarQubeMinVersion>5.6</sonarQubeMinVersion>
</configuration>
</plugin>
[...]
I have several OSGi bundles that are built in Eclipse using normal manifest-managed dependencies and external builds with Maven Tycho.
Running the bundles inside of Eclipse on Equinox works fine. Building them with Tycho works fine.
Now I want to use Tycho Surefire to run integration tests and for that I created a simple test bundle that contains some basic tests. The bundles under test rely on some other bundles present in the OSGi-container and some minor start level tweaks in order to run correctly - like I said, the bundles themself start up perfectly fine when running them normally on Equinox.
So to mimic that for Tycho Surefire, I specified the following in the pom.xml of the test bundle:
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>0.21.0</version>
<configuration>
<bundleStartLevel>
<bundle>
<id>org.hibernate.osgi</id>
<level>6</level>
<autoStart>true</autoStart>
</bundle>
<!-- plus a few more bundles in the real pom.xml -->
</bundleStartLevel>
</configuration>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-plugin</type>
<id>org.hibernate.entitymanager</id>
<versionRange>4.2.12.Final</versionRange>
</requirement>
<requirement>
<type>eclipse-plugin</type>
<id>org.hibernate.osgi</id>
<versionRange>4.2.12.Final</versionRange>
</requirement>
<!-- plus a few more bundles in the real pom.xml -->
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
</plugins>
</build>
Interestingly, the tests failed. After some research I found out how I can access the OSGi console during/after the failed test run to investigate the problem further (OSGi console after running tycho tests).
My findings are, that although all necessary bundles (all transitively derived bundles and all manually specified ones) are present in the OSGi-container only the ones with a distinctive <bundleStartLevel> have been started (plus the OSGi-core-bundles of course).
So given the above example, my findings are that while both org.hibernate.osgi and org.hibernate.entitymanager have been resolved, only the first is in the 'ACTIVE' state. This obviously messes up the whole startup and my guess is that the tests would run fine if the bundles would start up as expected.
When I look at a "normal" Eclipse-OSGi-Launch configuration, there is a parameter "Default Auto-Start" that is set to true by default. I did not find anything like that in the Tycho Surefire documentation, but is it possible that setting a specific start level for some bundles somehow overrides the auto start of other bundles? At least I wouldn't guess that Tycho isn't auto starting any bundles at all by default...
I'd appreciate any hints on how to investigate that issue further or any clues for how I can get Tycho to start my bundles without having to specify a distinct start level for each.
If anyone is still stumbling onto this:
Since Tycho 0.23 the bundle auto start is configurable.
<configuration>
<defaultStartLevel>
<level>7</level>
<autoStart>true</autoStart>
</defaultStartLevel>
</configuration>
I would like to run the following basic procedure within my Maven 3.0.4 project. I have all the basics in place and haven't had any issues but am running into problems on step #3. For some reason the basic solution is eluding me, since it seems like something that should be very obvious.
Run a basic clean/install (without annotation processing)
Request that a site build be run
Before the site build kicks off, run annotation processing on the compiled classes using an annotation processor class that was compiled in the initial steps
I tried setting up the annotation processing goal as follows:
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>pre-site</phase>
<configuration>
<outputDirectory>${basedir}/target/generated-documentation</outputDirectory>
<processors>
<processor>com.mydomain.MyFancyAnnotationProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
For some reason this doesn't seem to be working.
I feel like I'm doing something very, very silly that is preventing it from working.
I am using the Maven Annotation Plugin instead of the basic, Mojo Apt Plugin. I don't mind switching if someone has a working solution with that one. I tried both without any immediate signs of success. Again, it feels like it's just something obvious that I'm overlooking.
Error received:
[INFO] diagnostic error: Annotation processor 'com.mydomain.MyFancyAnnotationProcessor' not found
[ERROR] error on execute: error during compilation
My guess would be that the plugin is not including the current project itself in its classpath. The best solution would be to separate the annotation processor into its own (sub-)module if possible. If you can't do that, you may be able to just add this project itself as a dependency of the plugin (using a <dependencies> section under the plugin node).
As a diagnostic note, you can run maven with the '-X' argument to see detailed info about the build. This should show you exactly what is on the classpath when the plugin is executed.