Hi guys : I noticed that there is an ant task for checkstyle
http://checkstyle.sourceforge.net/anttask.html
I want checkstyle to run in my Ant build, which is on jenkins.
Unfortunately, the instructions are somewhat cryptic - with references to enabling project dependencies , modules, and other ant-specific configurations. I have a massive build file and I'm not really a build engineer - so I want to keep it simple without adding too much bload to the script.
Jenkins has a nice little button which supports displaying the checkstyle results, however, jenkins requires that you run the checkstyle and configure it yourself when you run a build.
What is the simplest way to modify my build.xml and ivy.xml ( i assume i will need to add checkstyle to ivy to get the jar remotely) to enable a basic checkstyle analysis of all the code base when builds are run ?
The sample of how to do it with help of just Ant:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Build" default="build" basedir=".">
<property file="props.properties"/>
<taskdef resource="checkstyletask.properties" classpath="${checkstyle.jar.path}"/>
<target name="build" depends="checkstyle">
<echo>Starting build</echo>
<echo>Build finished</echo>
</target>
<target name="checkstyle">
<echo>Starting checkstyle</echo>
<checkstyle config="rules/sun_checks.xml" failOnViolation="false">
<fileset dir="src" includes="**/*.java"/>
<formatter type="plain"/>
<formatter type="xml" toFile="build/checkstyle_errors.xml"/>
</checkstyle>
<echo>Checkstyle finished</echo>
</target>
</project>
The quote from Checkstyle site:
failOnViolation - Specifies whether the build will continue even if
there are violations. Defaults to "true".
You can download checkstyle-5.4-bin.zip from here.
The distribution package contains sun_checks.xml - checkstyle configuration that checks the sun coding conventions and checkstyle-x.x-all.jar library with task engine.
Related
I have an testsuite of API testing in SOAP UI.
I want an HTML report of testcases results. I am using basic SOAP UI version. Give me a solution apart from SOAP UI Pro.
Yes, it is possible to generate Junit Style HTML reports using SoapUI Opensource Edition as well.
All you need to do is the execution of tests has to be done
use Apache-Ant software, more details on installing and configuring here
write build script
Here is the sample build script(build.xml):
Note that modify the SOAPUI_HOME(or define environment variable), soapui project file path, results directory path according to your environment.
<project basedir="." default="testreport" name="ant script for testing soapui project">
<property environment="env"/>
<property name="soapui.project" value="/app/demo-soapui-project.xml"/>
<property name="results.dir" value="/tmp/results"/>
<property name="reports.dir" value="${results.dir}/Reports"/>
<property name="html.dir" value="${reports.dir}/html"/>
<target name="execute.project">
<exec dir="${env.SOAPUI_HOME}" executable="testrunner.sh">
<arg line="-raj -f ${results.dir} ${soapui.project}" />
</exec>
</target>
<target name="testreport" depends="execute.project">
<mkdir dir="${reports.dir}"/>
<junitreport todir="${reports.dir}">
<fileset dir="${results.dir}">
<include name="TEST-*.xml"/>
</fileset>
<report format="frames" todir="${html.dir}" />
</junitreport>
</target>
</project>
and execute following command (run soapui project and generate report):
ant
There is also simple way (i.e., every thing configured and readily available envrionment) if you are willing to use this docker image.
Short video also available there on how to.
So, let's assume that I have an already installed SVN and installed ANT / Ivy locally.
I want to have the "shared" part of the ivy config point to some kind of share on a server. How would I need to set this up?
I know I have to dig through the ivy jar and pull out the ivysettings file and modify shared repositories.
So let's assume that I have a server on my intranet at MyServer.intranet.net and my team's folder was under /path/to/NetAdmin (thus the full path would be MyServer.intranet.net/path/to/NetAdmin ) How would I get this set up as a team repository for shared libraries? Would I just specify it and when I package the projects it writes the dependencies there?
Thanks
Here what I did:
I created a Subversion project called ivy.dir.
In this ivy.dir project, I have the latest ivy.jar.
In the ivy.dir, I have the ivysettings.xml setup for our environment. For example, we use a local Artifactory Maven repository for our own jars. The ivysettings.xml in the ivy.dir project points to that.
I created a file called ivy.tasks.xml. This is an Ant build file.
The ivy.tasks.xml looks like this:
<project name="Ivy.Tasks"
xmlns:ivy="http://ant.apache.org/ivy"
xmlns:jacoco="antlib:org.jacoco.ant">
<property environment="env"/>
<!-- Add Ivy Tasks -->
<taskdef uri="http://ant.apache.org/ivy"
resource="org/apache/ivy/ant/antlib.xml">
<classpath>
<fileset dir="${ivy.dir}">
<include name="ivy*.jar"/>
</fileset>
</classpath>
</taskdef>
<ivy:settings file="${ivy.dir}/ivysettings.xml"/>
</project>
Notice that I have my own Ivy settings, thank you. I didn't have to munge up the one in the ivy.jar (although I could have since everyone will use my ivy.jar file!). My ivysettings.xml looks like this:
<ivysettings>
<!-- I'll explain this part below -->
<property name="env.EXECUTOR_NUMBER" value="0" override="false"/>
<caches
defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}"
resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/>
<!-- Just the standard stuff you find in the `ivysettings.xml in the ivy.jar -->
<settings defaultResolver="default"/>
<include file="${ivy.dir}/ivysettings-public.xml"/> <!-- This one is different -->
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
The big change is the ivysetting-public.xml file:
<ivysettings>
<resolvers>
<ibiblio name="public"
m2compatible="true"
checkmodified="true"
root="http://repos.vegicorp.com/artifactory/libs-release" />
</resolvers>
</ivysettings>
It's pointing to my local Maven repository -- my Artifactory server.
Now, for a developer to use Ivy, all they have to do is:
In the root of their project in Subversion, add a svn:external. This svn:external will be used to bring my ivy.dir project into their Subversion project.
In the build.xml
Add an Ivy namespace definition to their build.xml in the <project> definition.
Set the property ivy.dir to `${basedir}/ivy.dir.
Use the <import> task to import ${ivy.dir}/ivy.tasks.xml into their build.xml file.
Something like this:
<project name="post-a-matic" default="package" basedir="."
xmlns:ivy="http://ant.apache.org/ivy">
<property name="ivy.dir" value="${basedir}/ivy.dir"/>
<import file="${ivy.dir}/ivy.tasks.xml"/>
<!-- A whole bundle of properties are set -->
<target name="clean">
<delete dir="${target.dir}"/>
<ivy:cleancache/> <!-- Look: They have access to Ivy! -->
</target>
<target name="-resolve">
<ivy:resolve/>
</target>
<target name="compile"
depends="-resolve">
<ivy:cachpath
pathid="main.classpath"
conf="compile,provided"/>
<!-- Boy that's easy! -->
<javac srcdir="${main.srcdir}"
destdir="${main.destdir}"
classpathref="main.classpath"/>
</target>
<!-- On and on -->
This solves a lot of problems:
You can update the ivy.settings and everyone will have the updated settings. This ended up being very important to us because we use Jenkins and I wanted Jenkins to clean the ivy cache on each build. Whoops! That cleans out the ivy cache on builds that are being executed at the same time! I solved the problem by changing the ivysettings.xml file to define a different Ivy cache for each Jenkins build executor. One the Jenkins server, you have Ivy caches called $HOME/.ivy2/cache-0, $HOME/.ivy2/cache-1, etc. Each executor can delete it's own Ivy cache without affecting the others. Users, meanwhile will just have $HOME/.ivy2/cache-0.
You also can update Ivy when a new jar comes out. You update your Ivy jar file, and everyone gets the lated.
Big one of course is that Ivy installs itself when a project is checked out.
And an extra special bonus: You could use your ivy.dir and ivy.tasks.xml file to install other tasks. For example, each of our projects must run itself through Findbugs, PMD, CPD (part of the PMD project, Checkstyle, and use JaCoCo. for test coverage.
Each one of these projects consist of a jar file, and a <taskdef> to pull the task definitions into Ant. And, how do you use these tasks too? They're not defined in the standard Ant model. Developers don't know how to use them.
I've added these jars into my ivy.dir project, and installed all of those task definitions into my ivy.tasks.xml file. I also defined easy to use <macrodef> for most of these tasks, so it's easy for the developers to use them. In fact, I've even included the old Ant-Contrib tasks just for fun.
Now, once you add ivy.dir into your project, you have all of these extra tasks, and you have nothing to install on your machine.
You don't need to change the ivy jar. Just create a filesystem resolver in an ivysettings file and publish to this. Here's an example:
good ivy tutorial for local repository?
You'll find that ivy is very flexible and can support pretty much any mechanism for hosting files.
Personally, I'd consider installing a Maven repository manager like Nexus or Artifactory and use this to host both your builds dependencies and build outputs. In the long run it's a lot easier, especially if you're doing Java development.
I am using sonar to measure code quality. One thing that I do not know is the steps to measure code coverage using Cobertura.
I followed the steps from http://cobertura.sourceforge.net/anttaskreference.html and was able to generate xml files. How do I get these xml files into SONAR?
Is there an easier way to use Cobertura in SONAR?
I am running the code coverage (Cobertura) in a different server than my SONAR server. Both servers are running under LINUX.
Thanks for the help!
You configure the Sonar task to upload unit test and cobertura reports generated by other parts of your build logic.
This is in contrast to Maven which has a standard build life-cycle that Sonar is able to leverage.
Unit test and code coverage
The following logic runs the unit tests with cobertura instrumented classes. An XML coverage report is generated by cobertura at the end:
<target name="instrument-classes" depends="compile-tests">
<taskdef resource="tasks.properties" classpathref="test.path"/>
<cobertura-instrument todir="${instrumented.classes.dir}" datafile="${build.dir}/cobertura.ser">
<fileset dir="${classes.dir}"/>
</cobertura-instrument>
</target>
<target name="junit" depends="instrument-classes">
<junit printsummary="yes" haltonfailure="yes">
<classpath>
<path refid="test.path"/>
<pathelement path="${instrumented.classes.dir}"/>
<pathelement path="${test.classes.dir}"/>
</classpath>
<formatter type="xml"/>
<batchtest fork="yes" todir="${test.reports.dir}">
<fileset dir="${test.src.dir}">
<include name="**/*Test*.java"/>
<exclude name="**/AllTests.java"/>
</fileset>
</batchtest>
</junit>
</target>
<target name="test" depends="junit">
<cobertura-report format="xml" datafile="${build.dir}/cobertura.ser" destdir="${cobertura.reports.dir}"/>
</target>
Invoking Sonar
I normally use a very simple Sonar target:
<target name="sonar" depends="test">
<taskdef uri="antlib:org.sonar.ant" resource="org/sonar/ant/antlib.xml" classpathref="sonar.path"/>
<sonar:sonar key="${sonar.project.key}" version="${sonar.project.version}" xmlns:sonar="antlib:org.sonar.ant"/>
</target>
And use a properties file to control all aspects of Sonar's behaviour:
sonar.project.key=org.demo:demo
sonar.project.version=1.0-SNAPSHOT
sonar.projectName=Demo project
sonar.host.url=http://myserver:9000
sonar.jdbc.url=jdbc:mysql://myserver:3306/sonar?useUnicode=true&characterEncoding=utf8
sonar.jdbc.driverClassName=com.mysql.jdbc.Driver
sonar.jdbc.username=sonar
sonar.jdbc.password=sonar
sonar.sources=${src.dir}
sonar.tests=${test.src.dir}
sonar.binaries=${classes.dir}
sonar.dynamicAnalysis=reuseReports
sonar.surefire.reportsPath=${test.reports.dir}
sonar.java.coveragePlugin=cobertura
sonar.cobertura.reportsPath=${cobertura.reports.dir}/coverage.xml
Demonstrates how Sonar can be configured to pick up the unit test reports created by junit and the code coverage report generated by cobertura.
The build does not have to run on the same server as Sonar. In that case one must provide the remote Sonar URL and JDBC credentials.
You would have to add these properties to Sonar's pom.xml:
<properties>
<sonar.dynamicAnalysis>false</sonar.dynamicAnalysis>
<sonar.phase>generate-sources</sonar.phase>
<sonar.surefire.reportsPath>target/reports/test/</sonar.surefire.reportsPath>
<sonar.cobertura.reportPath>../project/target/reports/coverage/coverage.xml</sonar.cobertura.reportPath>
</properties>
(with paths appropriate to your environment)
And run:
mvn sonar:sonar
Check the user list for more details.
if you're using Maven, then you do not have anything special to specify in your POM file. Just run "mvn clean sonar:sonar" and Sonar will automatically compile your code, run your tests with Cobertura (which is the default coverage engine in Sonar) and push all the results in the DB.
Same if you're using Ant [1] or the simple java runner [2] instead of Maven.
I do insist on the fact that you do not have to manually run Cobertura (with an Ant task for instance) previously to running Sonar.
[1] http://docs.codehaus.org/display/SONAR/Analyzing+with+Sonar+Ant+Task
[2] http://docs.codehaus.org/display/SONAR/Analyse+with+a+simple+Java+Runner
Fabrice,
SonarSource
I have a build.xml(ant based) which requires some jar from nexus to get copied in existing lib folder. i.e when it builds it should copy the jar from nexus with some version defined & then copy in lib & do compilation.
like happen in maven we define the artifact & its version . If changed will automatically download it from maven repo.
how can i do this in ant based builds?
experts pls advice.
I have taken the example listed in this thread one step further and created a macrodef to clean things up a bit for re-use. See below for downloading two artifacts from nexus (one snapshot, one release).
<project>
<target name="get-all">
<mkdir dir="lib" />
<nexus-get
groupId="foo.bar"
artifactId="some-artifact"
version="1.0.28"
repo="releases"
extension="jar"
dest="lib"
/>
<nexus-get
groupId="foo.bar"
artifactId="another-artifact"
version="1.0.0-SNAPSHOT"
repo="snapshots"
extension="jar"
dest="lib"
/>
</target>
<macrodef name="nexus-get">
<attribute name="groupId"/>
<attribute name="artifactId"/>
<attribute name="version"/>
<attribute name="repo"/>
<attribute name="extension"/>
<attribute name="dest"/>
<sequential>
<get src="http://my-nexus:9999/nexus/service/local/artifact/maven/redirect?r=#{repo}&g=#{groupId}&a=#{artifactId}&v=#{version}&e=#{extension}" dest="#{dest}/#{artifactId}.#{extension}" usetimestamp="true" />
</sequential>
</macrodef>
You would probably be interested in Ivy. It is a sub-project of Ant for dependency management. It is perfect for your situation because it can read Maven repositories and provides Ant tasks for downloading the published artifacts, constructing class paths from them, etc. It supports your use case of getting the most recent version of a dependency if you configure it to ask for the "latest.release" revision of the module.
Although there are surely specific ways to combine ant and maven the simplest thing (if you know the nexus URL and your artifact parameters to construct the download URL) would be just to use the ant Get task.
<project name="MyProject" default="resolveDependencies" basedir=".">
<target name="resolveDependencies">
<mkdir dir="lib" />
<get src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar" dest="lib/log4j-1.2.9.jar" usetimestamp="true" />
</target>
</project>
Perhaps use the Maven Ant Tasks.
As shown on http://maven.apache.org/ant-tasks/examples/dependencies.html
Can list dependencies in ant, and also do things like copy them
I think the section Using FileSets and the Version Mapper covers your need
You can use is filesetId, which will give you a fileset reference that can be used to copy files into a particular location. For example, to populate WEB-INF/lib with your dependencies you could use the following:
<artifact:dependencies filesetId="dependency.fileset" useScope="runtime">
<dependency groupId="junit" artifactId="junit" version="3.8.2" scope="test"/>
</artifact:dependencies>
<copy todir="${webapp.output}/WEB-INF/lib">
<fileset refid="dependency.fileset" />
<!-- This mapper strips off all leading directory information -->
<mapper type="flatten" />
</copy>
I am executing lot of scp and sshexec and other remote commands from an ant build script. These commands don't work if jsch.jar isn't in the ant lib directory. To make it work, I copied the JAR into the ant lib directory, but this is not a good solution, as anyone else wanting to run the script would have to do the same thing. To run the ant target from Teamcity, we will have to explicitly set the path of the lib file.
Is there a way I can specify the path of the JAR in the ant build XML itself?
Thanks all for your answers. I am managed to get it work with classloader task. This is what I did.
<project basedir="." >
<property environment="env"/>
<taskdef resource="net/jtools/classloadertask/antlib.xml">
<classpath>
<fileset dir="${basedir}/lib" includes="ant-classloader*.jar"/>
</classpath>
</taskdef>
<!--Add JSCH jar to the classpath-->
<classloader loader="system">
<classpath>
<fileset dir="${basedir}/lib" includes="jsch*.jar"/>
</classpath>
</classloader>
<target name="Test">
<scp todir="user1:pass1#server1:/tmp" trust="true" >
<fileset dir="dir1">
<include name="test.txt" />
</fileset>
</scp>
</target>
</project>
As you can see here, I didn't have to give any dependant target for my "Test" target, it just works. It uses classloader, which appends jsch.jar to the system classloader.
One possible work around would be to use the -lib command line option to tell ant where to look for additional jars. Perhaps you could create a wrapper script that calls ant with this option set.
Another way would be to move the ant-jsch.jar file (this is the jar that comes with ant that defines the tasks, not the jsch.jar file you need to download separately) out of your ant lib directory, and create a taskdef for your ssh task separate to the built in one, then set the classpath for this task to the jsch.jar and the ant-jsch.jar:
<taskdef name="sshexec"
classname="org.apache.tools.ant.taskdefs.optional.ssh.SSHExec">
<classpath>
<pathelement location="jsch-0.1.44.jar"/>
<pathelement location="ant-jsch.jar" />
</classpath>
</taskdef>
I'm not sure this will help you though, since it also involves making changes to the lib directory.
As far as I'm aware, it's not currently possible to specify the extra jars required for the built in tasks in the build file itself in general. There are some special cases, like junit for instance.
To ensure your build is more cross platform I'd suggest using dependency management. The ivy plug-in can automatically install the version of your build's plugin at build-time.
This approach means the last jar you'll ever need to install into your ANT lib is ivy-2.2.0.jar :-)
First declare your project's dependencies in the file ivy.xml
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<configurations>
<conf name="anttask" description="Jars implementing ANT tasks"/>
</configurations>
<dependencies>
<dependency org="com.jcraft" name="jsch" rev="0.1.42" conf="anttask->default"/>
</dependencies>
</ivy-module>
Within your build.xml run ivy and use it to populate a custom classpath based on the ivy configuration:
<target name='init' description='Resolve project dependencies and set classpaths'>
<ivy:resolve/>
<ivy:cachepath pathid="anttask.path" conf="anttask"/>
</target>
Finally, elsewhere in your build declare your ANT tasks using the class path now automatically populated by ivy.
<target name='dosomething' depends="init">
<taskdef name="sshexec"
classname="org.apache.tools.ant.taskdefs.optional.ssh.SSHExec"
classpathref="anttask.path"/>
..
..
</target>
This approach works for all ANT plug-ins, most of which are available in the central Maven repository. The second benefit is that it's easy to upgrade the plug-in versions across all builds.