I am trying to setup a maven project such that I will be able to run checkstyle using two distinct rule sets: one for main, and one for test. What I would like to do is something along the lines of:
<reporting>
<plugins>
<!-- One configuration for main -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>checkstyle</configLocation>
</configuration>
</plugin>
<!-- But a different set of rules for test -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<sourceDirectory>${project.build.testSourceDirectory}</sourceDirectory>
<configLocation>checkstyle-test.xml</configLocation>
</configuration>
</plugin>
</plugins>
</reporting>
I have been successfully able to run one version or the other, but not both at the sames time. Including trying to bind them to different executions phases, but it seems the rule of thumb is the last definition is the only one used.
So I would either like to:
-Ideally - have two seperate checkstyle configuration files that can be run independently
OR
-Have a single checkstyle config, use the config property includeTestSourceDirectory to check main and test at the same time, but have some rules selectively applied to one of main/test or the other.
I have been unable to find any mechanism by which different checkstyle rules can be applied to different source roots at compile time (the other answer may work for report generation, but my needs are specifically compile time checking). The solution implemented is to have the rules that apply to source and then use the checkstyle supressions mechanism to exclude certain rules on the test classes i.e.
<suppress checks="CheckInappropiateForTests" files=".*Test\.java"/>
What about the following:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.6</version>
<reportSets>
<reportSet>
<id>main_checks</id>
<reports>
<report>checkstyle</report>
</reports>
<configuration>
<sourceDirectory>${project.build.sourceDirectory}</sourceDirectory>
<includeTestSourceDirectory>false</includeTestSourceDirectory>
<configLocation>config/maven_checks.xml</configLocation>
<outputDirectory>${project.reporting.outputDirectory}/main-checks/</outputDirectory>
</configuration>
</reportSet>
<reportSet>
<id>test_checks</id>
<reports>
<report>checkstyle</report>
</reports>
<configuration>
<sourceDirectory></sourceDirectory>
<testSourceDirectory>${project.build.testSourceDirectory}</testSourceDirectory>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<configLocation>config/sun_checks.xml</configLocation>
<outputDirectory>${project.reporting.outputDirectory}/test-checks/</outputDirectory>
</configuration>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
I found using this tip, applied to checktyle plugin, simpler.
In my case, it looks like this :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<executions>
<execution>
<id>checkstyle</id>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
<configuration>
<configLocation>some location</configLocation>
</configuration>
</execution>
<execution>
<id>checkstyle2</id>
<goals>
<goal>check</goal>
</goals>
<phase>verify</phase>
<configuration>
<configLocation>some other location</configLocation>
</configuration>
</execution>
</executions>
</plugin>
Related
I have the following configuration settings under my pom.xml to generate reports for PMD code analysis:
<pluginManagement>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.4</version>
<executions>
<execution>
<goals>
<goal>pmd</goal>
</goals>
<configuration>
<outputDirectory>code-analysis/reports/html</outputDirectory>
<targetDirectory>code-analysis/reports/</targetDirectory>
<aggregate>true</aggregate>
<rulesets>
<ruleset>code-analysis/rulesets/pmd-custom-rules.xml</ruleset>
</rulesets>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
But after I run mvn pmd:pmd I didn't get the report in the outputDirectory I want. Does setting the aggregate=true only generates 1 report for all the sub-projects under maven? How do I configure it so that it will only generate 1 report to the output directory that I want?
With Maven it is not possible to run a goal by execution(Id), that's only possible by calling it by phase. So if you want to run pmd:pmd from commandline AND have specific configuration, move the configuration outside the executions-block. Now it becomes general configuration. It'll be like:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.4</version>
<configuration>
...
</configuration>
</plugin>
I have been trying to figure out why yuicompressor-maven-plugin is not executed during "mvn package". I can execute it in an independent task as described in the link below but somehow the plugin does not get called from maven life cycle.
http://davidb.github.com/yuicompressor-maven-plugin/usage_compress.html
and here is the sample pom.xml I use,
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
<!-- yuicompressor-maven-plugin -->
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.3.0</version>
<executions>
<execution>
<id>compress</id>
<phase>process-resources</phase>
<goals>
<goal>compress</goal>
</goals>
</execution>
</executions>
<configuration>
<linebreakpos>-1</linebreakpos>
<encoding>UTF-8</encoding>
<nosuffix>true</nosuffix>
<force>true</force>
<jswarn>false</jswarn>
<webappDirectory>${project.build.directory}/minified</webappDirectory>
<aggregations>
<aggregation>
<insertNewLine>true</insertNewLine>
<output>${project.build.directory}/${project.build.finalName}/js/abc-min.js</output>
<includes>
<include>${basedir}/src/main/webapp/js/comments.txt</include>
<include>${project.build.directory}/minified/js/def.js</include>
</includes>
</aggregation>
</aggregations>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.2</version>
<configuration>
<warSourceExcludes>js/**/*.js,js/**/*.txt,css/**/*.css,css/**/*.txt</warSourceExcludes>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
I have read similar posts but could not figure out why it's not bounded to "process-resources". Phase and Goal are explicitly set so not sure why it's not called. Is there a way to debug why yuicompressor-maven-plugin is not called during "mvn package"? I use maven 2.2.1. Perhaps the version of my Maven won't work with the plugin?
thanks for your help,
syamashi
You simply need to put the running out of the pluginManagement area into the usual plugins area like:
<build>
<plugins>
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.3.0</version>
....
</plugin>
</plugins>
</build>
In pluginManagement you define only the default for plugin in particular the verison but you really don't bound to real execution. For other plugins etc. this works cause the are alreay defined in the build area of the supoer pom so this give you the opportunity to redefine them via pluginManagement but not with a plugin which never has been part of any build area.
I'm trying to build a jar file using 2 different source directories. So I'm using the maven-compiler-plugin. Here is my config:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<includes>
<include>**/*</include>
<include>src/main/java/**/*.java</include>
<include>../syncrpc/src/main/java/**/*.java</include>
</includes>
</configuration>
</plugin>
It builds alright but my jar file is empty (almost)... and my usual "target/classes" dir is empty. I suppose by default the compiler creates this directory and puts all the packages with the built classes. Can I do manually when I use the maven-compiler-plugin?
Thank you
Found a solution:
build-helper-maven-plugin
Basically, use the helper plugin instead, and it works perfectly.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals><goal>add-source</goal></goals>
<configuration>
<sources>
<source>../syncrpc/src/main/java/com/gdevelop/gwt/syncrpc</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
Can I download some files from http while maven lifecycle? any plugin?
If the file is a Maven dependency, you could use the Maven Dependency Plugin which has a get goal.
For any file, you could use the Antrun plugin to call Ant's Get task.
Another option would be the maven-download-plugin, it has been precisely created to facilitate this kind of things. It's not very actively developed and the documentation only mentions an artifact goal that does exactly the same thing as dependency:get but.. If you look at the sources, you'll see that is has a WGet mojo that will do the job.
Use it like this in any POM:
<plugin>
<groupId>com.googlecode.maven-download-plugin</groupId>
<artifactId>download-maven-plugin</artifactId>
<version>1.3.0</version>
<executions>
<execution>
<!-- the wget goal actually binds itself to this phase by default -->
<phase>process-resources</phase>
<goals>
<goal>wget</goal>
</goals>
<configuration>
<url>http://url/to/some/file</url>
<outputFileName>foo.bar</outputFileName>
<!-- default target location, just to demonstrate the parameter -->
<outputDirectory>${project.build.directory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Key benefits of this plugin are caching of the download and checking against a signature, such as MD5.
Note that this answer has been heavily updated to reflect changes in the plugin as noted in the comments.
Seems like wagon-maven-plugin from CodeHaus allows to download files over HTTP (though this is not is original goal).
Here is an example downloading GlassFish zip before integration tests:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>wagon-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>download-glassfish</id>
<phase>pre-integration-test</phase>
<goals>
<goal>download-single</goal>
</goals>
<configuration>
<url>http://download.java.net</url>
<fromFile>glassfish/3.1/release/glassfish-3.1.zip</fromFile>
<toDir>${project.build.directory}/glassfish</toDir>
</configuration>
</execution>
</executions>
</plugin>
The maven-antrun-plugin is a more direct solution:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>download-files</id>
<phase>prepare-package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<!-- download file -->
<get src="http://url/to/some/file"
dest="${project.build.directory}/downloads/"
verbose="false"
usetimestamp="true"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
I'd like to add a few thing about the download-maven-plugin:
Project is now hosted on GitHub https://github.com/maven-download-plugin/maven-download-plugin
Its releases are available on Maven Central, and the SNAPSHOTs are available on the oss.sonatype.org snapshot repository
Compared to other suggestions mentioned here, the download-maven-plugin adds the following interesting feature: caching of files (to avoid always redownloading big files) and signature verification to make sure download got the right bits.
If available, wget can be used directly with exec-maven-plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>wget</executable>
<arguments>
<argument>http://example.com/file.zip</argument>
<argument>destination.zip</argument>
</arguments>
</configuration>
</plugin>
You can use the download-single goal in the wagon plugin. Here is an example to download an HTML page (notice that the URL have to be split in a "directory" url and a "file name")
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>wagon-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>validate</phase>
<goals><goal>download-single</goal></goals>
<configuration>
<url>http://www.mojohaus.org/wagon-maven-plugin</url>
<fromFile>download-single-mojo.html</fromFile>
<toFile>[my dir]/mojo-help.html</toFile>
</configuration>
</execution>
</executions>
</plugin>
I managed to create main jar, copy dependencies to a single directory, the only step left is to sign all jars.
I can sign my own produced jar as a part of jar:sign, but how do i sign dependencies?
Thanks
Here are a couple of options:
Use the Maven ant task to run jarsigner from the JDK against all the dependencies.
Use the webstart plugin which can sign all your JARs, even if you aren't using it for the purpose of JNLP-izing your app. I'm using it to actually JNLPize one app.
Look at what the webstart plugin source is doing to iterate over all dependencies and sign them and start a new Maven Plugin/Mojo that does the same thing, sans JNLP.
Onejar your app and its dependencies and just sign that.
add to plug-in config <archiveDirectory>target</archiveDirectory>
If you are using maven-jar-plugin, you can specify which single jar to sign using the "jarPath" setting. The following configuration causes the jar-with-dependencies file to be signed instead of the dependency-less jar file:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>sign</goal>
</goals>
</execution>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- NOTE: The secret key is in shared version control. The
password is in shared version control. This IS NOT
SECURE. It's intended to help avoid accidentally
loading the wrong class, nothing more. -->
<jarPath>${project.build.directory}/${project.build.FinalName}-${project.packaging}-with-dependencies.${project.packaging}</jarPath>
<keystore>${basedir}/keystore</keystore>
<alias>SharedSecret</alias>
<storepass>FOO</storepass>
</configuration>
</plugin>
If you want to sign both, I don't know how to do that with maven-jar-plugin, so you may need to look into the other options mentioned above.
One can also create a single JAR using the maven-assembly-plugin.
Together with the other suggestion by Eric Anderson (of signing another JAR) one can then sign this assembled JAR (instead of the original JAR). Note that the order of the plugin definitions matters here.
It is assumed that sign.keystore.file etc are set elsewhere (e.g. in a profile).
<build>
<plugins>
<!-- It seems that maven-assembly-plugin must be declared before the maven-jar-plugin,
so that it is executed first in the package phase,
and then the signing of the packaged jar can succeed. -->
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifestEntries>
<!-- ... -->
</manifestEntries>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>sign</goal>
</goals>
<configuration>
<jarPath>${project.build.directory}/${project.build.FinalName}-${project.packaging}-with-dependencies.${project.packaging}</jarPath>
<keystore>${sign.keystore.file}</keystore>
<type>${sign.keystore.type}</type>
<storepass>${sign.keystore.storepass}</storepass>
<alias>${sign.keystore.alias}</alias>
<verify>true</verify>
<verbose>false</verbose>
<removeExistingSignatures>true</removeExistingSignatures>
</configuration>
</execution>
</executions>
<configuration>
<archive>
<manifest>
<!-- <addClasspath>true</addClasspath> -->
</manifest>
<manifestEntries>
<!-- ... -->
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>