We Keep Coding

How to change JAR build path in Jenkins?

I am building a Java project via Jenkins. The JAR is being created (after I execute maven clean install in Jenkins) in C:\Windows\System32\config\systemprofile.m2\repository\com\other folders.
Is there any way to change this path? I want to sent the JAR to a VM via SSH. However, I am not able to access this folder since this is system directory.
Thank you.

For some reason, your Jenkins uses this directory as local Maven repository. I would define a different local repository in Jenkins or in the settings.xml. It is also important that you make sure that no two running builds use the same local repository at the same time because local repositories cannot be used concurrently.

If you are using maven to build, add the below to your pom.xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<outputDirectory>your custom location</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>

By default, maven should create your build artifacts (including the JAR file) in target directory next to your pom.xml.
You can change this behavior in pom.xml by specifying the build directory:
<build>
<directory>/some/other/dir</directory>
</build>
The directory you are referring to is your local maven repository, which contains all JAR files maven is working with. You can read more about local maven repository here.

How to generate separate jar files for application, source, and documentation (for central.sonatype.org)

Sonatype has a repository that I want to deploy a jar file to, and they ask for separate files for application, sources, and javadocs:
Example:
example-application-1.4.7.pom
example-application-1.4.7.jar
example-application-1.4.7-sources.jar
example-application-1.4.7-javadoc.jar
In Scala SBT, I have a command called "package" that generates the jar file for the project, but that only generates "example-application-1.4.7.jar".
Question: What should I do to generate the other two jar files?

In Maven, in order to get the additional -sources and -javadoc artifacts, add to your POM file the following:
<build>
<plugins>
<!-- additional plugin configurations, if any.. -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Note the snippet above:
We are invoking the Maven Source Plugin to create an additional jar files for sources
We are invoking the Maven Javadoc Plugin to create an additional jar files for javadoc
Executing
mvn clean package
You will find these two additional jars in the target folder.
The .pom file instead is generated during the install phase, but it is not placed under the target folder. Basically, it is a copy of your pom.xml file, with a different extension and used by Maven during the dependency mediation process to check which transitive dependencies are required by the concerned artifact.
Executing
mvn clean install
Maven will install the artifact in your local cache (in your machine), under path_to_cache/.m2/repository/your_groupId/your_artifactId/your_version/. In this folder, you will also find the .pom file, which normally you don't need to distribute (it is created automatically by Maven).
Further note: you probably don't want to generate these additional jar files at each and every build, so to speed up normal builds and have them only on demand, you could wrap the snippet above in a Maven profile.
You can achieve this by removing the snippet above from your build section and add a further section at the end of your pom:
<profiles>
<profile>
<id>prepare-distribution</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.3</version>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
So that normal builds would not create these jars anymore, but when executing the following:
mvn clean install -Pprepare-distribution
You would instead get them back. the -P option is actually activating on demand the profile defined with the id prepare-distribution.
With Maven 3 a default profile already comes as part of the super pom which perform exactly the same actions (sources and javadoc artifact), hence no need to add anything to your existing project. Simply run:
mvn clean install -Prelease-profile
Or, to activate it via a property
mvn clean install -DperformRelease=true
However, as also specified in the super pom, this profile may be removed in future releases (although there since first Maven 3 version till version 3.3.9 so far)
NOTE: The release profile will be removed from future versions of the super POM
The main reason behind this warning is most probably to push for the usage of the Maven Release Plugin, which indirectly makes use of this profile via the useReleaseProfile option of the release:perform goal.
As highlighted by comments, if you are not familiar with maven (especially via console) I would definitely recommend to
Go through the official Maven in 5 minutes documentation for a quick but worthy look.
Play with Maven from the command line, is there where Maven gives you its best. IDE integrations are great, but command line is the real turning point.
Then play with the POM customization above, to get familiar with some concepts and behaviors, first directly as part of your default build, then moved to a profile.
Then, and only then, move to the Maven Release Plugin usage. I recommend it as last step because you would already have acquired more confidence and understanding and see it as less magic and more reasonable approach.

Deploying Java project to Heroku without Maven-supported dependencies

Is anyone working with Heroku for Java?
I have one Java project which I want to deploy on Heroku. That project uses some external JAR files which contains important dependencies.
Can anyone tell me how to deploy my project with these JAR files to Heroku? Maven is not able to download these JAR files on Heroku.

We just published a guide showing how to add dependencies like this to your project:
http://devcenter.heroku.com/articles/local-maven-dependencies
Let me know if this works for you.

You need to setup a local Maven repository containing your jars. Include that repo in your git repo. And add the repo to the pom.xml file:
<repositories>
<repository>
<id>local-libs-dir</id>
<name>locallib</name>
<url>file:${project.basedir}/libs</url>
</repository>
</repositories>
The jar files must be in the standard Maven repo layout and have md5 & sha1 checksums.

You can use jcabi-heroku-maven-plugin, which automates the entire deployment process:
<plugin>
<groupId>com.jcabi</groupId>
<artifactId>jcabi-heroku-maven-plugin</artifactId>
<version>0.4.1</version>
<configuration>
<name>my-test-app</name>
<artifacts>
<artifact>com.example:example-app:jar::${project.version}</artifact>
</artifacts>
<procfile>web: java -Xmx256m -jar ./example-app.jar \${PORT}</procfile>
</configuration>
<executions>
<execution>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
Besides that, you have to deploy your artifact (JAR/WAR) to your repository, so that Maven inside Heroku can download it during deployment.

Integrating Maven reporting plugins

I need to setup Maven plugins. I have downloaded the JARs. Can anyone please tell me what do I do next in order to integrate or setup the plugins with Maven?
Should I copy the JARs into the parent directory or do I need to edit any file?
The plugins are:
Java2HTML
JDepend
Checkstyle
Clover
Cobertura
EMMA
Findbugs
JavaNCSS
PMD
QALab
Xradar
Sonar

If Maven has access to the central repository it will download most plugins (some are not hosted on central, to access those you need to define an additional repository in your pom or settings).
If the dependencies are configured in your POM, Maven will automatically attempt to download them when you run a relevant goal. For the dependencies you listed this is mvn site.
The majority of those jars you've listed are reports, so should be declared in the reporting section of the POM, for example (I would also declare the versions to be sure you're getting the expected plugin):
<reporting>
<plugins>
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<linkXref>true</linkXref>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<formats>
<format>html</format>
<format>xml</format>
</formats>
<outputDirectory>target/site/cobertura</outputDirectory>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-report-plugin</artifactId>
<configuration>
<outputDirectory>${basedir}/target/surefire-reports</outputDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jdepend-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<configuration>
<xmlOutput>true</xmlOutput>
<effort>Max</effort>
</configuration>
</plugin>
</plugins>
</reporting>
Some background on Maven's plugin execution model:
When you run mvn site, this is short hand for "run the site goal from the latest version of the site plugin", i.e. it is equivalent to mvn site:site, which is in turn shorthand for mvn org.apache.maven.plugins:maven-site-plugin:LATEST:site
Maven will attempt to contact the central repository, determine the LATEST version from the maven-metadata.xml, then download it (and any of its dependencies that are also missing) before executing it.
If you are behind a proxy you may see an error message in your build log like this:
[INFO] The plugin 'org.apache.maven.plugins:maven-site-plugin' does not exist or no valid version could be found
To address this you can declare proxy settings in your Maven settings.xml (in [MVN_HOME]/conf/settings.xml). They are commented out by defualt, but look something like this:
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net,some.host.com</nonProxyHosts>
</proxy>
Replace the username, password, host, and port values with the relevant for your environment and Maven will be able to download the required dependencies.
For more details on using Maven, check out the Maven: The Definitive Guide by Sonatype, it is online and free.

Sirakov is right; Maven will download and install the plugins automatically when they are used.
You can either run them directly (for one-off jobs), or configure them in your pom.xml - this also allows you to configure then, and set the to run automatically, for example, to generate source code or report on test coverage. A major advantage of this is that you can define a single set of plugin configs in a shared parent pom, and reuse the same configurations across across all your projects, while still being able to override the inherited configuration in each subproject where necessary - this is one of the biggest advantages of using Maven on larger projects.
Each plugin has its own configuration parameters, the standard ones are documented at http://maven.apache.org/plugins/. Another good resource is the O'Reilly Maven book, online at http://www.sonatype.com/books/maven-book/reference/
An example configuration for cobertura:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.3</version>
<configuration>
<outputDirectory>${project.build.directory}/pmd</outputDirectory>
<targetDirectory>${project.build.directory}</targetDirectory>
<aggregate>true</aggregate>
<!-- CPD minimum tokens to report on (5 to 10 duplicate lines) -->
<minimumTokens>100</minimumTokens>
<minimumPriority>3</minimumPriority>
<!-- Exclude mock classes -->
<excludes>
<exclude>**/Mock.*</exclude>
<exclude>**/Dummy.*</exclude>
<exclude>**/*Mock.java</exclude>
<exclude>**/*Dummy.java</exclude>
</excludes>
<includeTests>true</includeTests>
<targetJdk>1.5</targetJdk>
<rulesets>
<ruleset>pmd_ruleset.xml</ruleset>
</rulesets>
</configuration>
</plugin>

You don't need to download the plugins manually. I'm not 100% sure, but if you want to use for example the checkstyle plugin, you need to start maven with checkstyle parameter form command line
something like:
mvn checkstyle:checkstyle
or
mvn checkstyle:check
edit1: But you can also put the jars into the local m2 repository with the specific folder structure to access them.
edit2: you can put all your plugins into your own repository and then you need to tell maven (using the pom), which repositories you want to use. Every plugin must be described in the pom.

Generating a maven site including a Cobertura Report

I've got some projects that are already doing site generation via maven, and I want to integrate cobertura reports in them, but no maven goal I seem to run will generate a local preview for me to look at that includes the Cobertura reports in the site. I want to be sure they're generating correctly before I commit the pom changes to the repo and have broken site generated.
Below is what I've added to the maven poms (parent and module), but the site I see when I run mvn site:run does not include the cobertura reports:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<configuration>
<check>
<haltOnFailure>false</haltOnFailure>
<regexes>
<regex>
<pattern>parent-package-name-here.*</pattern>
<branchRate>80</branchRate>
<lineRate>80</lineRate>
</regex>
</regexes>
</check>
<instrumentation>
<includes>
<include>parent-package-name-here/**/*.class</include>
</includes>
</instrumentation>
</configuration>
<executions>
<execution>
<id>clean</id>
<phase>pre-site</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
<execution>
<id>instrument</id>
<phase>site</phase>
<goals>
<goal>instrument</goal>
<goal>cobertura</goal>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
...
</project>
What maven command should I use to generate the site with cobertura reports? Or, what should I add (additionally) to get the site generation to include the cobertura reports?

Should do:
mvn site
To elaborate, running mvn a:b runs the goal b in plugin a. Saying mvn c means to run the lifecycle phase c, which runs all of the bound goals in all of the phases up to c. As a result, this will trigger a lot more things to happen (such as doing the necessary preparation to produce cobertura reports).

I figured out how to do this.
It seems there are a lot of bugs in the link generation within the maven site generation plugin.
The only way I've found to make maven generate a local copy of the site with working module links is to modify the distributionManagement/site tag to point to some local directory instead of the real-live deploy directory, then use maven site:deploy.
Every attempt to use mvn site:stage generates broken links. Same goes for mvn site:run.
The report links work with mvn site:run / mvn site:stage but the links to modules do not.

mvn site
should do what you are looking for. You configure the plugin to run in the pre-site and site phases of the life cycle but your are then executing the site:run goal not site. We are doing similar things with clover (commercial coverage tool) and mvn site does the trick.

site:stage module links don't work in my experience either for multi module builds but site:deploy does. Try this:
Use a property for the site URL in the parent pom, e.g. ${site.url}. Then call this
mvn clean site site:deploy -Dsite.url=file://`pwd`/target/site-deployed
The pwd is a -nix command that will substitute the current directory. This is because the URL that you use must be absolute.

We use
mvn site-deploy
This builds the site and deploys it (copies it to the place we have configured).

mvn site:site should produce what you are after, in the target directory, there will be a site directory containing all reports linked with an index.html in that directory.