themavenfiles-blog

[themavenfiles-blog]

jacoco test coverage plugin

What is different in the jacoco plugin is that it uses the jvm running code to create metrics. This is a different approach from the one used by Cobertura, which will provide metrics using offline code.

The maven plugin needs to instrument code before generating the reports. The instrumentation is achieved with jacoco:prepare-agent which uses initialize build lifecycle. The report is generated with jacoco:report. 

<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.6.3.201306030806</version> <executions> <execution> <id>jacoco-initialize</id> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>jacoco-site</id> <phase>prepare-package</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>

[themavenfiles-blog]

playframework 2 + maven

In order to build playframework 2 apps using maven you need to install playframework in the same machine, or the maven build will get stuck looking for 'play in the system path'.

here is the snippet:

<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/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>group</groupId> <artifactId>artifact</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>play2</packaging> <repositories> <repository> <id>typesafe</id> <url>http://repo.typesafe.com/typesafe/releases/</url> </repository> </repositories> <dependencies> <dependency> <groupId>play</groupId> <artifactId>play_2.10</artifactId> <version>2.1-10082012</version> <scope>provided</scope> <exclusions> <exclusion> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-iphone-driver</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>play</groupId> <artifactId>play-test_2.10</artifactId> <version>2.1-10082012</version> <scope>provided</scope> </dependency> </dependencies> <build> <!-- Play source directory --> <sourceDirectory>app</sourceDirectory> <testSourceDirectory>test</testSourceDirectory> <plugins> <plugin> <groupId>de.akquinet.innovation.play2</groupId> <artifactId>play2-maven-plugin</artifactId> <version>1.2.0</version> <extensions>true</extensions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.1</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </build> </project>

[themavenfiles-blog]

enforcing project compliance

I have worked in a few projects where we decided to enforce code standards since the inception including test coverage, duplication, code style, and etc. Enforcing validations using verify lifecycle goal is a good way to start. 

The snippet below is doing just that.

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-pmd-plugin</artifactId> <version>2.6</version> <configuration> <failOnViolation>true</failOnViolation> <targetJdk>1.6</targetJdk> </configuration> <executions> <execution> <phase>compile</phase> <goals> <goal>pmd</goal> <goal>cpd</goal> <goal>check</goal> <goal>cpd-check</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <version>2.8</version> <configuration> <configLocation>src/main/resources/checkstyle.xml </configLocation> </configuration> <executions> <execution> <phase>verify</phase> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> <version>2.5.1</version> <configuration> <check> <totalLineRate>70</totalLineRate> <haltOnFailure>true</haltOnFailure> </check> </configuration> <executions> <execution> <phase>pre-integration-test</phase> <goals> <goal>cobertura</goal> <goal>clean</goal> <goal>check</goal> </goals> </execution> </executions> </plugin> </plugins> </build>

The checkstyle plugin can be customized to your projects:

<?xml version="1.0"?> <!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.2//EN" "http://www.puppycrawl.com/dtds/configuration_1_2.dtd"> <module name="Checker"> <module name="NewlineAtEndOfFile" /> <module name="Translation" /> <module name="TreeWalker"> <property name="cacheFile" value="${checkstyle.cache.file}" /> <!-- Checks for Naming Conventions. --> <!-- See http://checkstyle.sf.net/config_naming.html --> <module name="ConstantName" /> <module name="LocalFinalVariableName" /> <module name="LocalVariableName" /> <module name="MemberName" /> <module name="MethodName" /> <module name="PackageName" /> <module name="ParameterName" /> <module name="StaticVariableName" /> <module name="TypeName" /> <!-- Checks for imports --> <!-- See http://checkstyle.sf.net/config_import.html --> <module name="AvoidStarImport" /> <module name="IllegalImport" /> <!-- defaults to sun.* packages --> <module name="RedundantImport" /> <module name="UnusedImports" /> <!-- Checks for Size Violations. --> <!-- See http://checkstyle.sf.net/config_sizes.html --> <module name="MethodLength" /> <module name="ParameterNumber" /> <!-- Modifier Checks --> <!-- See http://checkstyle.sf.net/config_modifiers.html --> <module name="ModifierOrder" /> <module name="RedundantModifier" /> <!-- Checks for blocks. You know, those {}'s --> <!-- See http://checkstyle.sf.net/config_blocks.html --> <module name="AvoidNestedBlocks" /> <module name="EmptyBlock" /> <module name="LeftCurly" /> <module name="NeedBraces" /> <module name="RightCurly" /> </module> </module>

IMPORTANT: be aware that the team may nickname you "The Code Nazi"

[themavenfiles-blog]

single command for not related projects

(For UNIX based OS only)

Sometimes you want run commands on projects that are no related: projects that are not bound by the reactor plugin or modules. One easy way is to accomplish it is to use "find". Example:

find . -name pom.xml -execdir mvn clean install  \;

find . -name pom.xml -execdir mvn eclipse:eclipse \;

[themavenfiles-blog]

android maven properties

The Maven Android plugin builds the resources and assets before the process resources life cycle is triggered. In order to set properties through maven the resources processing phase needs to happen in a different way.

<build> <finalName>${project.artifactId}-${project.version}-${platform}-${api.domain}</finalName> <sourceDirectory>${project.basedir}/src</sourceDirectory> <resources> <resource> <directory>${project.basedir}/res</directory> <filtering>true</filtering> <targetPath>${project.build.directory}/filtered-res</targetPath> <includes> <include>**/*.*</include> </includes> </resource> </resources> <plugins> <plugin> <artifactId>maven-resources-plugin</artifactId> <executions> <execution> <phase>initialize</phase> <goals> <goal>resources</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.1.1</version> <configuration> <androidManifestFile>${project.basedir}/AndroidManifest.xml</androidManifestFile> <assetsDirectory>${project.basedir}/assets</assetsDirectory> <resourceDirectory>${project.build.directory}/filtered-res</resourceDirectory> <nativeLibrariesDirectory>${project.basedir}/src/main/native</nativeLibrariesDirectory> <sdk> <platform>10</platform> </sdk> <undeployBeforeDeploy>true</undeployBeforeDeploy> <emulator> <avd>avd1</avd> <wait>10000</wait> </emulator> </configuration> <extensions>true</extensions> </plugin> </plugins> </build>

One thing to keep in mind is that the maven resources filtering plugin corrupts binary files. See: http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html 

[themavenfiles-blog]

properties and resources

Sometimes you need to set variables to you application depending on the environment in which the app will run. Example: database connection strings or rest endpoints. 

First you will need a file. In this case applicaton.properties. It will look like:

app.datasource.driverClass=${datasource.driverClass} app.datasource.jdbcUrl=${datasource.jdbcUrl} app.datasource.user=${datasource.user} app.datasource.password=${datasource.password}

In the maven pom.xml you will need indicate the file which will hold the configuration + the property and values. 

<profile> <id>staging</id> <properties> <datasource.driverClass>com.mysql.jdbc.Driver</datasource.driverClass> <datasource.jdbcUrl>jdbc:mysql://localhost/db</datasource.jdbcUrl> <datasource.user>root</datasource.user> <datasource.password /> </properties> <build> <resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <includes> <include>application.properties</include> </includes> </resource> </resources>

[themavenfiles-blog]

deploying to amazon (AWS)

Using beanstalk-maven-plugin is a easy way to deploy to AWS. Before deploying it necessary to create a bucket in S3 service ( and of cours, you got to be registered https://console.aws.amazon.com)

<profile> <id>beanstalk</id> <build> <plugins> <plugin> <groupId>br.com.ingenieux</groupId> <artifactId>beanstalk-maven-plugin</artifactId> <version>0.2.5</version> <configuration> <accessKey>accesskey</accessKey> <secretKey>secretkey</secretKey> <environmentName>dev</environmentName> <applicationName>appname</applicationName> <s3Bucket>bucketname</s3Bucket> <s3Key>${project.artifactId}/${project.build.finalName}-${maven.build.timestamp}.war</s3Key> </configuration> </plugin> </plugins> </build> </profile>

then use mvn beanstalk:upload-source-bundle beanstalk:create-application-version beanstalk:create-environment

If you need to set extra configurations like ssh certificate, or an default image you need to provide options settings. It goes like this:

<plugin> <groupId>br.com.ingenieux</groupId> <artifactId>beanstalk-maven-plugin</artifactId> <version>0.2.7-RC4</version> <executions> <execution> <phase>package</phase> </execution> </executions> <configuration> <dryRun>false</dryRun> <environmentName></environmentName> <applicationName></applicationName> <s3Bucket>elasticbeanstalk-bucket</s3Bucket> <s3Key>${project.build.finalName}.war</s3Key> <versionLabel>${project.version}.${maven.build.timestamp}</versionLabel> <versionsToKeep>0</versionsToKeep> <optionSettings> <optionSetting> <namespace>aws:elasticbeanstalk:container:tomcat:jvmoptions</namespace> <optionName>Xmx</optionName> <value>512m</value> </optionSetting> <optionSetting> <namespace>aws:elasticbeanstalk:application</namespace> <optionName>Application Healthcheck URL</optionName> <value>/healthcheck</value> </optionSetting> <optionSetting> <namespace>aws:autoscaling:launchconfiguration</namespace> <optionName>ImageId</optionName> <value></value> </optionSetting> <optionSetting> <namespace>aws:autoscaling:launchconfiguration</namespace> <optionName>EC2KeyName</optionName> <value></value> </optionSetting> </optionSettings> </configuration> </plugin>

[themavenfiles-blog]

deploying to cloudbees

When I was looking for a place to publish my projects I found cloudbees.com. They have a really cool integration with maven. To start playing see: http://wiki.cloudbees.com/bin/view/RUN/MavenGuide

My configuration end up very simple:

<build> <plugins> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.26</version> </plugin> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>tomcat-maven-plugin</artifactId> <version>1.1</version> </plugin> <plugin> <groupId>com.cloudbees</groupId> <artifactId>bees-maven-plugin</artifactId> <configuration> <appid>codenuance/meboard</appid> <environment>dev</environment> <apikey>yourkey</apikey> <secret>yoursecret</secret> </configuration> </plugin> </plugins> </build>

[themavenfiles-blog]

javadocs including dependencies

When you generate the javadocs for a project that uses other projects as dependencies it's necessary to:

have source files for dependency projects

configure javadoc plugin to include dependencies  

Creating javadocs with maven is trivial. The challenging part is to include the project dependencies as the javadocs...

First in the dependency projects you need: 

<build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <executions> <execution> <goals> <goal>jar</goal> </goals> </execution> </executions> </plugin>

the project that creates the website needs:

<reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <version>2.8</version> <configuration> <includeDependencySources>true</includeDependencySources> <dependencySourceIncludes> <dependencySourceInclude> your.package.com </dependencySourceInclude> </dependencySourceIncludes> </configuration> </plugin>

to finally deploy to a remote apache:

<build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-site-plugin</artifactId> <version>3.0</version> <dependencies> <dependency> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh</artifactId> <version>2.2</version> </dependency> </dependencies> </plugin>

and add the server to you distribution management section

<distributionManagement> <site> <id>apache-server</id> <url>scp://hostname/var/www/DOCS</url> </site>

[themavenfiles-blog]

dealing with manifest resource problems

The problem happens when creating a jar file and the project has multiple module using same manifest resources.

This problem happened to me twice when using spring framework as transitive dependencies. The spring metainfo that gets copied into the .jar file gets overwritten and possibly invalid.

The fist time I faced this problem shade plugin was not available and I ended up harcoding the manifest file.

Last time, thanks to maven-shade-plugin the solution was easier.

<plugins> <plugin> <groupId>org.apache.camel</groupId> <artifactId>camel-maven-plugin</artifactId> <configuration> <applicationContextUri>META-INF/spring/application-context.xml</applicationContextUri> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>1.6</version> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>org.apache.camel.spring.Main</mainClass> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.handlers</resource> </transformer> <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> <resource>META-INF/spring.schemas</resource> </transformer> </transformers> </configuration> </execution> </executions> </plugin>

[themavenfiles-blog]

dependency manager

Maven dependency management can be used in different ways. It can work with a local repository in your computer where the dependencies will be downloaded and stored inside /home/m2./repository/ by default, A.K.A. the simplistic approach. Or alternatively, maven can be configure to work with a repository manager like archiva, artifactory, and nexus.

The simplistic local dependency management has drawbacks. All the development workstation will be downloading artifacts that may disappear from internet repositories making building unstable. Execution time and network bandwidth usage are also issues due to the fact that all development workstations will be downloading artifacts from the internet.  

Usually, on a enterprise environment it is necessary to cache dependencies internally inside the repository manager, increasing execution speed, since the dependencies will be managed internally over a faster network. A recommended approach to achieve this is to crete a settings.xml using a mirror to point to the repository manager.

<?xml version=”1.0” encoding=”UTF-8”?><settings xsi:schemaLocation=”http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd” xmlns=”http://maven.apache.org/SETTINGS/1.0.0”

    xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance“>   <mirrors>     <mirror>       <mirrorOf>*</mirrorOf>       <name>libs-release</name>       <url>http://artifactory-host:8081/artifactory/repo</url>       <id>libs-release</id>  </mirror>   </mirrors>   <profiles>     <profile>       <repositories>         <repository>           <snapshots>             <enabled>false</enabled>           </snapshots>           <id>central</id>           <name>libs-release</name>           <url>http://artifactory-host:8081/artifactory/libs-release</url>         </repository>         <repository>           <snapshots />           <id>snapshots</id>           <name>libs-snapshot</name>           <url>http://artifactory-host:8081/artifactory/libs-snapshot</url>         </repository>       </repositories>       <pluginRepositories>         <pluginRepository>           <snapshots>             <enabled>false</enabled>           </snapshots>           <id>central</id>           <name>plugins-release</name>           <url>http://artifactory-host:8081/artifactory/plugins-release</url>         </pluginRepository>         <pluginRepository>           <snapshots />           <id>snapshots</id>           <name>plugins-snapshot</name>           <url>http://artifactory-host:8081/artifactory/plugins-snapshot</url>         </pluginRepository>       </pluginRepositories>       <id>artifactory</id>     </profile>   </profiles>   <activeProfiles>     <activeProfile>artifactory</activeProfile>   </activeProfiles> </settings>

The <mirrors> will be responsible for locking the requests to the repository manager. The repository manager will be then responsible for retuning the dependencies and if they are not existing, it will try to find/download them in external repositories most of the times over the internet.

The <repositories> are the locations inside the repository manager where maven will look for the dependencies.

The final piece is to deploy the project to the repo manager. Inside the project pom.xml it will be necessary to add the <distributionManagement> tag.

<distributionManagement> <repository> <id>artifactory-host</id> <name>artifactory-host-releases</name> <url>http://artifactory-host:8081/artifactory/libs-release-local</url> </repository> <snapshotRepository> <id>artifactory-host</id> <name>artifactory-hostsnapshots</name> <url>http://artifactory-host:8081/artifactory/libs-snapshot-local</url> </snapshotRepository></distributionManagement>

The section above will work only when deploy goal is executed. If the project version is a marked as SNAPSHOT, it will deploy to the snapshot-libs. Otherwise, it the project will be deployed to release-libs.

[themavenfiles-blog]

android project

It uses android-maven-plugin needs maven 3.0.3. 

To create a new project:

mvn archetype:generate   -DarchetypeArtifactId=android-quickstart   -DarchetypeGroupId=de.akquinet.android.archetypes   -DarchetypeVersion=1.0.8   -DgroupId=your.company   -DartifactId=my-android-application

Upon inspecting the project, you will see

<plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.1.1</version> <configuration> <androidManifestFile>${project.basedir}/AndroidManifest.xml </androidManifestFile> <assetsDirectory>${project.basedir}/assets</assetsDirectory> <resourceDirectory>${project.basedir}/res</resourceDirectory> <nativeLibrariesDirectory>${project.basedir}/src/main/native </nativeLibrariesDirectory> <sdk> <platform>10</platform> </sdk> <undeployBeforeDeploy>true</undeployBeforeDeploy> </configuration> <extensions>true</extensions> </plugin>

To mavenize an existing project use something like this:

<packaging>apk</packaging> <properties> <platform.version>2.3.3</platform.version> </properties> <dependencies> <dependency> <groupId>com.google.android</groupId> <artifactId>android</artifactId> <version>${platform.version}</version> <scope>provided</scope> </dependency> </dependencies> <build> <sourceDirectory>${project.basedir}/src</sourceDirectory> <plugins> <plugin> <groupId>com.jayway.maven.plugins.android.generation2</groupId> <artifactId>android-maven-plugin</artifactId> <version>3.2.0</version> <configuration> <androidManifestFile>${project.basedir}/AndroidManifest.xml</androidManifestFile> <assetsDirectory>${project.basedir}/assets</assetsDirectory> <resourceDirectory>${project.basedir}/res</resourceDirectory> <nativeLibrariesDirectory>${project.basedir}/src/main/native</nativeLibrariesDirectory> <sdk> <platform>10</platform> </sdk> <undeployBeforeDeploy>true</undeployBeforeDeploy> </configuration> <extensions>true</extensions> </plugin> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </build>

[themavenfiles-blog]

linux remote deployment of executable jar

Motivation: The need deploy an executable jar file to a remote computer. In this case, it will be necessary to use wagon and exec plugin.

If we were dealing with a webapp (war file) we could have used a webserver specific plugin. Example: tomcat plugin: http://tomcat.apache.org/maven-plugin.html 

First we need to copy the file using scp.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>wagon-maven-plugin</artifactId> <dependencies> <dependency> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh</artifactId> <version>2.2</version> </dependency> </dependencies> <executions> <execution> <phase>install</phase> <goals> <goal>upload-single</goal> </goals> </execution> </executions> <configuration> <serverId>apache1</serverId> <fromFile>target/appwithdependencies.jar</fromFile> <url>scp://host/dir/app</url> </configuration> </plugin>

The copy may fail due to ssh certificate that needs to be created. <serverid> need to be match a configured server in settings.xml. Example:

<servers> <server> <id>apache1</id> <username>usertest</username> <privateKey>${user.home}/.ssh/apache1-usertest</privateKey>

Optionally, you will need to start/stop a service. For that, use exec plugin. Example:

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>1.2.1</version> <executions> <execution> <id>ssh-server1</id> <phase>install</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>ssh</executable> <arguments> <argument>user@host</argument> <argument>sudo service app stop; sudo service app start</argument> </arguments> </configuration> </execution> </executions> </plugin>