Maven 2 checkstyle plugin version 2.5 - Problem with configLocation - maven-2

I am using checkstyle plugin in maven 2. I now want to switch my config file, from the default one to a) an online file, or b) a local file. I tried the following two things, which both didnt work. Any suggestions?
A) Local file, which is directly in my project folder next to the pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>checkstyle.xml</configLocation>
</configuration>
</plugin>
B) Remote file, that is stored on a server
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>http://stud.hs-heilbronn.de/~nischmid/development/checkstyle-config.xml</configLocation>
</configuration>
</plugin>
Both cases result in an error like this:
[INFO] An error has occurred in
Checkstyle report generation. Embedded
error: Failed during checkstyle
execution Could not find resource
'file:checkstyle.xml'.
Any help would be appreciated!

I've seen several issues related to configLocation in Jira with the version 2.5 of the plugin (like MCHECKSTYLE-129 or MCHECKSTYLE-131), both a) and b) just work fine with the version 2.4.
So, unless you're using Maven 3, I suggest to rollback to 2.4 for now:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
<configuration>
<configLocation>checkstyle.xml</configLocation>
</configuration>
</plugins>
or
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
<configuration>
<configLocation>http://stud.hs-heilbronn.de/~nischmid/development/checkstyle-config.xml</configLocation>
</configuration>
</plugin>
As a side note, for a multi-modules build, have a look at the Multimodule Configuration.

I've been trying to use version 3.0.1 of the Checkstyle plugin and found configLocation has no effect. Tried the approach above, but still no luck.
To summarise, the answer above probably does work, but you might need to set a property checkstyle.config.location.
Using -X to get debug output, I saw:
[DEBUG] (f) configLocation = config/sun_checks.xml
Scrolling further back in the log, it looks like configLocation isn't being set:
<configLocation default-value="config/sun_checks.xml">${checkstyle.config.location}</configLocation>
Based on that message, I set the property in the global <properties> as follows:
<checkstyle.config.location>${basedir}/config/checkstyle-configuration.xml</checkstyle.config.location>
This worked, but caused the plugin to throw an exception. After some Googling, I added the following to the checkstyle configuration file:
<module name="Checker">
...
<module name="TreeWalker">
...
<property name="cacheFile" value=""/>
For completeness, the last step came from the following Jira, marked as resolved in 2.8. The difference is it seems to work with an empty value, avoiding the need to set up a ${cachefile} property:
http://jira.codehaus.org/browse/MCHECKSTYLE-159

Maybe helpful for someone else who needs to still find a workaround.
By the way i had the same problem and the file is suppose to be searched in /classes/.xml or folders from here. But since it is looking directly after the project folder i included
<configuration>
<configLocation>src\main\resources\checkstyle-checker-dev.xml</configLocation>
</configuration>
Note: configLocation has L caps
Also you can define a global variable in environment and use here
Note: This is only a workaround, it needs to work as stated in the above lines.

Related

How to display dependency conflicts in 'mvn site'

I can easily see if there are conflicts between (transitive) dependency versions using:
mvn dependency:tree -Dverbose=true
... this will show the full resolution tree, including which elements were omitted (for duplicate or conflict or whatever). What I would like to do is to add the full tree to the 'mvn site' report.
Currently, the site report includes the dependency tree but only as resolved, i.e., without any conflicts. I see in the project-info-reports plugin that there is not currently any way to do what I want using the standard report.
I tried adding a section to the pom to include the maven-dependency-plugin 'tree' goal with the outputFile specified, but it wasn't included when I ran 'mvn site'. It was something like this:
<reporting>
....
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<reportSets>
<reportSet>
<id>deptree</id>
<reports>
<report>tree</report>
</reports>
<configuration>
<verbose>true</verbose>
<outputFile>${project.reporting.outputDirectory}/deptree.txt</outputFile>
</configuration>
Of course, the 'tree' goal is explicitly identified as not a report, but I was hoping to at least be able to produce a file that I could link to from the generated site. No dice.
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here? Obviously I could write my own reporting plugin to do this, and/or submit a patch for the project-info-reports plugin, but I want to make sure I've exhausted all the built-in maven options.
(I'm using maven 2.1.0, but I didn't see anything about a change to this functionality in the release notes for later versions.)
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here?
Just to answer your question, you can bind a mojo to the pre-site phase of the Site Lifecycle:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>tree</id>
<phase>pre-site</phase>
<goals>
<goal>tree</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
...
</reporting>
If you then run mvn site, dependency:tree will run.

How to exclude pom.xml from Maven generated war?

Using Maven war plugin, I generate WAR which includes following directory:
META-INF
-- maven
-- com.abc.def
-- myServlet
-- pom.xml
-- pom.properties
In release, I want to exclude this maven directory. How can I do that?
I tried latest maven-war-plugin (2.1-beta-1), it has configuration "packagingExcludes", but it doesn't work as I wish.
Any suggestions?
I'm not sure but I think that the Maven Archiver (which is mainly used by plugins to handle packaging) can be configured to achieve this.
About the <addMavenDescriptor> element, the Maven Archiver Reference says:
Whether the generated archive will contain these two Maven files:
The pom file, located in the archive in META-INF/maven/${groupId}/${artifactId}/pom.xml
A pom.properties file, located in the archive in META-INF/maven/${groupId}/${artifactId}/pom.properties
The default value is true.
So a pom configured like this should do the trick:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
</configuration>
</plugin>
...
</plugins>
</build>
...
</project>
Using the standard Maven packaging you can't omit the file to my knowledge. It is possible however to use the maven-assembly-plugin to construct the war, in this case you have much finer grained control over the contents of the artifact, and can omit the pom.xml.
However I have personally found it useful to keep the pom.xml for diagnostic purposes. It can be handy to know what was used to build and assemble the war when trying to figure out what is wrong with your app.
Update: in a bizarre bit of synchronicity to Pascal's answer, I've just been reading up on the Archiver reference and it appears that this can be done by setting the addMavenDescriptor property to false. Personally I would still avoid doing this for reasons given above. But you may want to change your acceptance to Pascal's answer.
Putting a META-INF folder in a resources directory or in the root of your source directory will destroy the META-INF content created by Maven. For WAR files, putting a META-INF in your web content directory will do the same.
Adding other content to that custom META-INF will override what maven would create.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warSourceExcludes>pom.xml</warSourceExcludes>
</configuration>
</plugin>
or
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warSourceExcludes>here/there/everywhere/a/pom.xml</warSourceExcludes>
</configuration>
</plugin>

Maven2: How to be sure Maven build is using a specific plugin version?

I just found something that sounds weird with Maven plugin management.
While working on the site generation I wanted to use a specific version of the maven site plugin in order to have a specific functionnalty working.
Let's say I want to use version 2.0.1 of this plugin.
If I use the reporting section of my POM in order to generate my project's site with the command:
mvn site
this works well. I mean the plugin version used is 2.0.1 as I wanted. Here is an extract from my POM configuring the site plugin:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</reporting>
Now if I want my site to be generated during a specific phase of the build life cycle, let's say prepare-package (and goal stage), I add the following section in the section:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>stage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
And here I am stuck with the maven site plugin version coming from the Super POM, ie. 2.0-beta-7.
Even if I try to add the configuration specifying I really want to use version 2.0.1 it still uses 2.0-beta-7.
I also tried to add the version in the section because the config that is used in the reporting section is supposed to be applied to the build section also. But this does not work neither.
Maybe I missed something, and correct me if I am wrong but this looks like a bug.
Is there a need on the Maven side to fix plugin's version to be used during the build process?
Thanks!
If you define a pluginManagement section in the pom, you can declare the versions used for any plugins, this will override the versions inherited from the super POM
For example:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</pluginManagement>
You can refer to the documentation for some background on configuring pluginManagement.
I think you need to use the "pluginManagement" section to set the global version number of the plugin.

Maven2: How to stage JXR plugin result when using mvn site?

I have a multi-module project and I want to deploy on the project's site an HTML version of my source code using the JXR maven plugin.
The problem is that the JXR plugin runs well, the XREF folder is properly generated for each of my module, but when I use the mvn site:stage command in order to retrieve all the project's site content and to have all link properly generated it does not retrieve the XREF folders.
Here is an extract of my POM file where the JXR plugin is configured:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jxr-maven-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
</configuration>
</plugin>
Here is the command I use to create and stage my site:
mvn site site:stage
Do you guys have any idea?
Thanks in advance.
r.
Not sure this is relevant, but your command is running the site twice, mvn site will generate the site, and site:stage will also run the site, perhaps this is causing problems but I honestly can't see why.
Looking at the JXR documentation, it only mentions the site:site goal, I can't see why it wouldn't be run properly for the site:stage goal as it extends it. If you run the site goal, then copy the output to another directory, run the site:stage goal and compare the output it might give some insight into the problem.
Update: I tried this myself and the xref was included and aggregated nicely in c:\test\stage with the cross references correctly managed. I've included the configuration I used.
In my parent pom I defined the site configuration like this:
<build>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>stage</goal>
</goals>
</execution>
</executions>
<configuration>
<stagingDirectory>c:\test\stage</stagingDirectory>
</configuration>
</plugin>
</plugins>
</build>
The distributionManagement section was configured with the site information (not really needed as I set the stagingDirectory above, but the goal won't run without it).
<distributionManagement>
<site>
<id>mojo.website</id>
<name>Mojo Website</name>
<url>scp://test/</url>
</site>
</distributionManagement>
My JXR configuration in the parent pom was as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<reportSets>
<reportSet>
<id>src-xref</id>
<reports>
<report>jxr</report>
</reports>
</reportSet>
<reportSet>
<id>test-xref</id>
<reports>
<report>test-jxr</report>
</reports>
</reportSet>
</reportSets>
<configuration>
<aggregate>true</aggregate>
</configuration>
</plugin>
The commandline run was mvn clean site:stage
Edit: Per the comments, there is a codehaus jxr plugin with slightly different semantics. Be sure to use the org.apache.maven.plugins version rather than the org.codehaus.mojo version.

maven compilation error: duplicate classes

In my maven2 project I have a directory ${basedir}/autogen that contains some autogenerated source code files produced by wsdl2java.
When running mvn compile I get an compilation error, because of duplicate classes, that lives in ${basedir}/autogen. This is true. But what is the compilation phase doing in ${basedir}/autogen? I have not told maven to add this directory as a source directory.
And there seems to be no way of telling maven to ignore the directory.
I had the same problem when using the maven-processor-plugin and found that the solution was to configure the maven-compiler plugin as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
-proc:none means that compilation takes place without annotation processing and therefore no duplicate classes (which are typically generated in the generate-sources phase)
I hope that helps.
I've seen this a few times. In almost all cases, it is due to the generated classes being added to the main src tree then checked into version control.
In my case, it worked when I changed source directory.
New POM looks like,
<build>
<sourceDirectory>src</sourceDirectory>
Pointing just a src folder with sourceDirectory tag.
Earlier it was
<build>
<sourceDirectory>.</sourceDirectory>
Note that earlier it was working in IntellIJ, but not on cmd.
Now it works on both.
I had a similar problem with JPA model generator. It occurred on this dependency:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa.modelgen</artifactId>
<version>2.1.1</version>
</dependency>
I wrongly added the scope=provided and that resulted in:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project mocker: Compilation failure: Compilation failure:
[ERROR] \Projects\entity\MockVehicle_.java:[10,7] duplicate class: entity.MockVehicle_
I had the exact same issue. In my case the problem was that I called maven with -f=./pom.xml. I have no idea why this leads to a different result (would be nice if someone can explain) but maybe good to know if someone else has the same issue.
I resolve it by remove generateAsync from my pom.xml the the GWT plugin will look like
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>${gwtVersion}</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
<!-- <goal>i18n</goal> -->
</goals>
</execution>
</executions>
Its hard to change default maven behaviour, i think its better to go with it - you could generate those files with maven wsdl2java-maven-plugin
I my case helped this:
<!-- https://mvnrepository.com/artifact/javax.annotation/javax.annotation-api -->
<dependency>
<groupId>javax.annotation</groupId>
<artifactId>javax.annotation-api</artifactId>
<version>1.3.2</version>
</dependency>
All answers here where not helpful. This may be the correct answer:
Another StackOverflow user wrote:
I have found an JetBrains Team member comment stating that:
IDEA automatically excludes the build 'target' folder, providing that
there are no generated sources under it, otherwise it excludes all
sub-folders but the generated.
Avro by standard in a generated-sources folder. This folder it not ignored by maven ans the generated classes in there will count as duplicate.
Maven will only igonre the target folder by default.
To fix add this line in the pom.xml:
<sourceDirectory>${project.basedir}/src/main/target/resources/avro</sourceDirectory>
Context:
<groupId>org.apache.avro</groupId>
<artifactId>avro-maven-plugin</artifactId>
<version>${avro.version}</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>schema</goal>
<goal>protocol</goal>
<goal>idl-protocol</goal>
</goals>
<configuration>
<sourceDirectory>${project.basedir}/src/main/target/resources/avro</sourceDirectory>
<stringType>String</stringType>
<createSetters>false</createSetters>
<outputDirectory>${project.basedir}/target/</outputDirectory><enableDecimalLogicalType>true</enableDecimalLogicalType>
<fieldVisibility>private</fieldVisibility>
</configuration>
</execution>
</executions>
This will put the generated-resources folder under the target folder.
I resolve the same issue
cleaning maven project :-mvn clean
delete com folder from src then compile
copy com from generated to src->main-->java
again compile
Hope this Help..