Problem description:
The setup is executing Ant build script with TestNG target, which then loads testng.xml file. There is a possibility to specify listeners in both Ant file and testng.xml.
The questions arising are following:
Will both set up ways be supported? Will all the listeners specified in both configuration location be used during test execution?
Will any of listeners be prioritized over another? If yes, how?
Sample set up:
Ant file:
<project>
<property name="classes.dir" path="<my_classes_dir>" />
<property name="test.dir" path="<my_test_dir>" />
<target name="run-test">
<testng useDefaultListeners="false"
listeners="org.testng.reporters.EmailableReporter, org.testng.reporters.XMLReporter, com.example.MyCustomReporter">
<classpath>
<path path="${classes.dir}" />
</classpath>
<xmlfileset dir="${test.dir}" includes="testng.xml" />
</testng>
</target>
</project>
TestNG.xml:
<suite name="MyTestSuite">
<listeners>
<listener class-name="com.example.MyListener" />
<listener class-name="org.testng.reporters.FailedReporter" />
</listeners>
<test name="MyTest1">
<classes>
<class name="com.example.MyTest1" />
</classes>
</test>
</suite>
Background:
I have to support existing project which uses set up similar to the one described above. The Ant build file disables default reporters. Without touching Ant build file, I would like to specify additional report listeners (FailedReporter and/or any custom ones) for my tests in testng.xml.
I believe all listeners should be run, in your build file as well as in your testng.xml.
The testng.xml listeners would be executed second.
If the same listener is listed in both, build file and testng.xml, it would be executed twice.
This is based on my experience with Maven, but I guess, with ant it should be the same.
Also the order of listeners specified in testng.xml cannot be guaranteed in case both are implementing the same set of interfaces.
Hope it helps.
Related
I am trying to invoke tests of a testng.xml file from ant.
My testng.xml looks like the following:
<suite name="testsuite">
bunch of parameters here
<test name="test1">
</test>
<test name="test2">
</test>
</suite>
Now, I want to run only the "test1" tests and not those of "test2". Is there a way (parameter?) to tell the ant build.xml file to do this?
<testng classpathref="testng.class.path" delegateCommandSystemProperties="true"
outputDir="${test-output}" haltOnfailure="false" useDefaultListeners="true"
parallel="methods"
failureproperty="test.failure">
<xmlfileset file="testng.xml"/>
<!--forked JVM OOM issue-->
<jvmarg value="-Xmx512M"/>
<jvmarg value="-Xms512M"/>
<jvmarg value="-Xmn192M"/>
<jvmarg value="-XX:PermSize=128M"/>
<jvmarg value="-XX:MaxPermSize=128M"/>
</testng>
Look up -testnames in the documentation (note: plural).
The xml files are there for exacly that: not running all tests from a class file containing tests. As I see it, the intended way to go would be to change the existing xml file, or create a new one.
Still, if your tests are included in different class files (I cannot see this from your example code), you could specify a classfileset instead of an xmlfileset, e.g.:
<testng workingDir="../../" outputdir="${output_dir}"
verbose="2" listeners="org.uncommons.reportng.HTMLReporter,org.uncommons.reportng.JUnitXMLReporter"
classpathref="testsClasspath">
<classfileset dir="./${test_classes}/com/my/organization" includes="MyTest.class" />
</testng>
I wrote a small macrodef in separate file:
macrodefs.xml
<macrodef name="do-cool-stuff">
<attribute name="message"/>
<sequential>
<echo message="#{message}" />
</sequential>
</macrodef>
I got a second file, my main build file:
build.xml
<target name="build">
<!-- do this and that -->
<!-- cheking out macrodefs.xml via CVS -->
<ant antfile="macrodefs.xml" target="do-cool-stuff" >
<property name="message" value="Hello, World!" />
</ant>
</target>
As you might guess this dosen't work. The error message is something like:
Target 'do-cool-stuff' does not exist in this project.
The only possible solution I found is to provide a extra target in the macrodefs.xml to forward the ant calls.
Is there a possibility to invoke the macrodef from within another file?
Thanks in advance.
You can import the file and use the macro like this:
<import file="macrodefs.xml" />
<do-cool-stuff message="Hello, World!" />
Note that in the macro definition you should use #{curlybrackets} when referencing macro attributes:
<sequential>
<echo message="#{message}" />
</sequential>
There are some examples at the end of the Ant macrodef task docs.
More
What you're trying to do isn't well supported by Ant. The ant and antcall tasks don't allow the 'callee' to affect the caller directly. You can write files in the called task, then load those in the caller. But as you have observed, the pre-process tasks import and include cannot be called from within a target. The ant/antcall tasks only allow you to run targets in subsidiary builds, not macros.
One workaround method (this might be similar to the one you mention, but allows you to put all the real work in the top-level build) would be to have an inner buildfile that includes the top-level import of the macrodefs.xml.
Something like the following. The macrodefs.xml file is as before. (But note that the imported files - including the macro definitions - need to be complete Ant project files, so they must include a project element.)
build.xml:
<target name="build">
<!-- cvs actions -->
<ant antfile="inner-build.xml" target="target-runner">
<property name="target" value="top-target" />
</ant>
</target>
<!-- this target will fail unless invoked from the inner build -->
<target name="top-target">
<do-cool-stuff message="Hello, World!" />
</target>
inner-build.xml:
<project>
<import file="macrodefs.xml" />
<target name="target-runner">
<ant antfile="build.xml" target="${target}" />
</target>
</project>
Effectively you would be doing
build.xml --> inner-build.xml --> build.xml (again)
(cvs) (import macros) (use macros)
The inner buildfile could potentially be generated on-the-fly by the main build - say if you wanted to import multiple macro definition files - but that's getting perhaps too unwieldy.
I want create Ivy Ant tasks in xml editor in IDE (Intellij iDEA) with autocomplete based on xsd , but I cannot find xsd for register XML namespace xmlns:ivy="antlib:org.apache.ivy.ant"
Where I can find it?
I just copied the ivy jar to INTELLIJ_HOME/lib/ant and now intellij can resolve the ivy tasks.
Or import this ant file to your ant project, its actually the first ivy example in ivy documentation, make sure to always depend on install-ivy target, add your ant file to idea in the ant build window and you dont even have to install ivy and idea recognizes ivy tasks.
<property name="ivy.jar.dir" value="${user.home}/.ivy2/jars" />
<property name="ivy.jar.file" value="${ivy.jar.dir}/ivy.jar" />
<property name="ivy.install.version" value="2.2.0" />
<target name="check-ivy-installed" unless="INTERN-ivy.jar.exists">
<available property="INTERN-ivy.jar.exists" file="${ivy.jar.file}"/>
</target>
<target name="download-ivy" depends="check-ivy-installed" unless="INTERN-ivy.jar.exists">
<echo message="downloading and installing ivy"/>
<mkdir dir="${ivy.jar.dir}"/>
<!-- download Ivy from web site so that it can be used even without any special installation -->
<get src="http://repo1.maven.org/maven2/org/apache/ivy/ivy/${ivy.install.version}/ivy-${ivy.install.version}.jar"
dest="${ivy.jar.file}" usetimestamp="true"/>
<echo message="ivy installed"/>
</target>
<!-- =================================
target: install-ivy
this target is not necessary if you put ivy.jar in your ant lib directory
if you already have ivy in your ant lib, you can simply remove this
target and the dependency the 'go' target has on it
================================= -->
<target name="install-ivy" depends="download-ivy" description="--> install ivy">
<!-- try to load ivy here from local ivy dir, in case the user has not already dropped
it into ant's lib dir (note that the latter copy will always take precedence).
We will not fail as long as local lib dir exists (it may be empty) and
ivy is in at least one of ant's lib dir or the local lib dir. -->
<echo message="Installing ivy"/>
<path id="ivy.lib.path">
<fileset dir="${ivy.jar.dir}" includes="*.jar"/>
</path>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
uri="antlib:org.apache.ivy.ant" classpathref="ivy.lib.path"/>
</target>
To complete Shalom's answer, the location where to add the ivy.jar for the IntelliJ IDEA Community Edition is INTELLIJ_HOME/lib/ant/lib (one more folder to go).
Maybe it also apply to the full version.
might be, there was no xsd in the past time this discussion started, but at least since may 2011 the ivy scheme is well documented at
http://ant.apache.org/ivy/schemas/ivy.xsd
which is linked right from the documentation in http://ant.apache.org/ivy/
so, to start over using the scheme, you just need:
<?xml version="1.0" encoding="UTF-8"?>
<project name="yourproject"
xmlns:ivy="antlib:org.apache.ivy.ant"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ant.apache.org/ivy/schemas/ivy.xsd"
>
<!-- … -->
I guess this discussion might help you. It appears that there is no xsd for the ivy ant tasks, but Eclipse does autocomplete.
yes, no xsd for ivy ant tasks avialable. but i found the way to make autocomplete in Intellij IDEA
in ant build file need to define additional task:
<property name="ivy.jar.dir" value="C:/Apache/apache-ivy-2.2.0/"/>
<taskdef resource="org/apache/ivy/ant/antlib.xml"
uri="antlib:org.apache.ivy.ant">
<classpath>
<fileset dir="${ivy.jar.dir}" includes="*.jar"/>
</classpath>
</taskdef>
XML plugin for jEdit defines AntCompleteTask (ant task) that produces an xml file called ant-complete.xml. The resulting file looks as follows:
<element-list>
<!-- ... -->
<element name="classpath"
content="(fileset|dirset|extdirs|existing|filelist|pathelement|path)">
<attribute name="id" type="ID" />
<attribute name="location" type="CDATA" />
<attribute name="cache" type="(true|false|on|off|yes|no)" />
<attribute name="refid" type="CDATA" />
<attribute name="description" type="CDATA" />
<attribute name="path" type="CDATA" />
</element>
<!-- ... -->
The generated file may be downloaded as XML plugin archive. Open XML.jar and browse to xml/completion directory. It's syntax is defined in xml-completion-info.dtd.
The task code does not contain an explicit license, but it's at least GPL. Anyway you probably don't need to distribute that task, only to use it and this doesn't require any license.
I can't assess the usability of the resulting xml file, but jEdit uses it for autocompletion.
I have setup an ant script as eclipse builder to automatically run all my tests, like below:
<project name="auto-test" default="test">
<property name="tst-dir" location="C:\STAF\services\custom\TopCoder\bin" />
<path id="classpath.base" />
<path id="classpath.test">
<pathelement location="D:\eclipse\eclipse\plugins\org.junit4_4.3.1\junit.jar" />
<pathelement location="${tst-dir}" />
<path refid="classpath.base" />
</path>
<target name="test" description="Run the tests">
<junit>
<classpath refid="classpath.test" />
<formatter type="brief" usefile="false" />
<test name="testDataGenerator.test.AllTests" />
</junit>
</target>
</project>
It was all good before I changed a test fixture file from absolute path to relative path:
SAXReader reader = new SAXReader();
Document document = reader.read(new File(".").getCanonicalPath()+"\\conf\\TestData.xml");
The ant task now try to open D:\eclipse\eclipse\conf\TestData.xml, instead of C:\STAF\services\custom\TopCoder\conf\TestData.xml, I've also try to run AllTests manually from Eclipse and it's all good.
Has anyone met similar problem before?
Thanks in advance.
PS. ANT_HOME=D:\eclipse\eclipse\plugins\org.apache.ant_1.7.0.v200706080842
Follow up:
I tried to run the ant script from command line, and find below:
C:\STAF\services\custom\TopCoder>ant -f c:\STAF\services\custom\TopCoder\task\build.xml, the ant script works correctly.
C:>ant -f c:\STAF\services\custom\TopCoder\task\build.xml, the script will claim: [junit] C:\conf\TestData.xml (The system cannot find the path specified)
I've also checked eclipse builder setting, there seems nothing to change the path to D:\eclipse\eclipse.
Java resolves relative paths against the current user directory, which is typically the directory from where the java program was invoked.
One way to overcome this issue is to define an environmental variable for your base path. Then, you could easily use "relative paths" (meaning, create absolute paths by concatenating the base path and the relative path).
Here is the solution I find:
Just as kgiannakakis mentioned, Ant also start executing its task from the location it was invoked, so we just need to change the working directory setting of our custom eclipse builder.
In the JRE tab, choose "Execution Environment".
Change the Working directory to your current workspace.
Looks like I've missed the karma but anyway...
We do this:-
Build.xml
<project name="whatever">
<property file="build.${env.COMPUTERNAME}.properties"/>
<property file="build.properties"/>
build.properties
project.root=..
build.file.dir=${project.root}/buildfiles
deploy.dir=${project.root}/deploy
which of course you can override by creating your OWN build.computername.properties to allow for developer path differences etc
I have a number of file/executable locations that are likely to be different depending on which computer I am running them on, and I would like to abstract these out through ant properties somehow. What's the best way to do this? Is there a system-wide ant setup script that gets called? Or can I make such a script?
In addition to Vladimir's solution you might have a default properties file for each of the OS or other you might deploy your build system on. Use the ${os.name} (and other Java system properties) to set up a path. For example
<property file="build-${os.name}.properties">
These files can be maintained and checked in into your version control system as well.
I use the more or less standard build.properties and build-local.properties files.
The first contains default values, common to all environments, the second only the exceptions. The first one is checked into subversion while the other is not.
EDIT : copy/pasting Akr's excellent idea
In addition you might have a default properties file for each of the OS or other you might deploy your build system on. These files can be checked in into your version control system as well.
The Ant script would then include all the files as follow (remember: in Ant the first definition wins):
<property file="build-local.properties"/>
<property file="build.properties"/>
<property file="build-${os.name}.properties">
Setup an ant build file called properties.xml, in which you should define the properties that you want to customize.
Here is properties.xml boilerplate I am using for my projects ( I've adapted it from one of the books on Ant ):
<?xml version="1.0" encoding="UTF-8"?>
<project
name="workspace-properties"
>
<dirname
property="workspace-properties.basedir"
file="${ant.file.workspace-properties}"
/>
<!--
==========================================================
Load Environment Variables
==========================================================
-->
<!-- #Load environment variables -->
<property environment="env" />
<!-- this is here to deal with the fact that an IntelliJ IDEA build
has no ant home
-->
<property
name="ant.home"
value="${env.ANT_HOME}"
/>
<!-- get Unix hostname, and set to Windows comparable name -->
<!-- #Trick to get host name x-platform -->
<property
name="env.COMPUTERNAME"
value="${env.HOSTNAME}"
/>
<!--
==========================================================
Load property files
Note: the ordering is VERY important.
==========================================================
-->
<!-- #Allow even users property file to relocate -->
<property
name="user.properties.file"
location="${user.home}/.build.properties"
/>
<!-- Load the application specific settings -->
<!-- #Project specific props -->
<property file="build.properties" />
<!--
==========================================================
Define your custom properties here.
You can overwrite them through build.properties and
${user.home}/.build.properties
==========================================================
-->
<property name="myexec1" location="/usr/bin/myexec1"/>
<property name="myexec2" location="/usr/bin/myexec2"/>
</project>
Important thing here is to come up with as many useful default property values as possible, then you may even never come up with custom build.properties files.
Then you just <import> this file in your project's build.xml.
<project
name="my-project"
>
<!-- this is done, so you may import my-project somewhere else -->
<dirname
property="my-project.basedir"
file="${ant.file.my-project}"
/>
<import file="${my-project.basedir}/relative/path/to/properties.xml"/>
<target name="using.myexec1">
<echo message="myexec1=${myexec1}"/>
</target>
</project>
If you want a custom value for myexec1 in my-project, just drop a custom flat build.properties file in the same directory where build.xml is located.
The build.properties file may look like this:
myexec1=c:/custom/path/to/myexec1.exe