I am trying to integrate Sonar into my ant build script. I am able to make it work if I edit the build file of respective child projects by adding
<!-- Define the SonarQube project properties. removing the rest of properties for representing the problem-->
<property name="sonar.sources" value="src" />
<!-- Define SonarScanner for Ant Target -->
<target name="sonar" xmlns:sonar="antlib:org.sonar.ant">
<taskdef uri="antlib:org.sonar.ant" resource="org/sonar/ant/antlib.xml">
<!-- Update the following line, or put the "sonarqube-ant-task-*.jar" file in your "$HOME/.ant/lib" folder
<classpath path="path/to/sonar/ant/task/lib/sonarqube-ant-task-*.jar" />-->
</taskdef>
<!-- Execute SonarScanner for Ant Analysis -->
<sonar:sonar />
</target>
as defined in https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-ant/
Now I want to move this config a level up from the sub project level to the root level so that I need to edit just one build file.
I was not able to move the above block as such since root project does not have a src folder and ant complained about that. So I tried to have a subant task for this
<subant target ="sonar" xmlns:sonar="antlib:org.sonar.ant">
<taskdef uri="antlib:org.sonar.ant" resource="org/sonar/ant/antlib.xml">
<!-- Update the following line, or put the "sonarqube-ant-task-*.jar" file in your "$HOME/.ant/lib" folder
<classpath path="path/to/sonar/ant/task/lib/sonarqube-ant-task-*.jar" />-->
</taskdef>
<!-- Execute SonarScanner for Ant Analysis -->
<sonar:sonar />
</subant>
But for this I get the following error:
subant doesn't support the nested "taskdef" element.
Is there any workaround for this?
Related
Let me first provide the background of the problem I'm facing.
I have a directory structure as below.
c:\myDirectory
c:\myDirectory\Project1
c:\myDirectory\Scripts
Under the c:\myDirectory\Scripts there is a script that download the source code (from svn) and creates the c:\myDirectory\Project1 directory.
I have another ant scripts ( c:\myDirectory\Scripts**compile-source.xml ) that compiles the Project1
from an ant script build.xml that is downloaded to c:\myDirectory\Project1
Snippet for c:\myDirectory\Scripts\compile-source.xml
<project name="compile" default="buildAll" basedir=".">
<property file=".\build.properties">
</property>
.......
<import file="${project.home.path}/${project.name}/build.xml"/>
<target name="buildAll">
<antcall target="jar-pack"/>
</target>
</project>
Snippet for c:\myDirectory\Project1\build.xml.
<project name="CommonFeatures" default="jar-pack" basedir=".">
<description>
A build file for the Common Features project
</description>
....
</project>
Note that the basedir for the project is set as "." for both the above ant scripts.
When I execute the script c:\myDirectory\Scripts\compile-source.xml from the c:\myDirectory\Scripts directory the target "jar-pack" present in the c:\myDirectory\Project1\build.xml gets executed.
However, the problem is that basedir attribude in build.xml ( basedir="." ) is the current working directory and in this case its c:\myDirectory\Scripts. Hence the script build.xml errors out since the basedir for build.xml is expected to be c:\myDirectory\Project1. The build.xml script would have worked, if basedir="." were set to "c:\myDirectory\Project1", but unfortunately build.xml file comes from the source code that is downloaded and I'm unable to edit.
So here's my question, Is it possible to do any of the following.
Override the value of the attribude basedir="." in build.xml when the is done in c:\myDirectory\Scripts\compile-source.xml ?
Is it possible to change the basedir in build.xml by any other mechanism so that the script c:\myDirectory\Project1\build.xml is executed under directory c:\myDirectory\Project1 ?
Any other way to resolve this issue?
Any help from Ant experts to overcome this issue is highly appreciated.
You can update basedir using subant task. Check this answer
Create the following build.xml file (assuming it is in Z:/any/folder):
<?xml version="1.0" encoding="UTF-8"?>
<project name="project">
<target name="mytarget">
<subant target="debug">
<property name="basedir" value="X:/any/dir/with/project"/>
<fileset dir="Y:/any/folder/with" includes="build.xml"/>
</subant>
</target>
</project>
The you can execute ant mytarget from Z:/any/folder
You can specifically reference the location of your build file, which is described in this stack overflow thread. This would allow you to get and use the directory your build file resides in as a reference point.
For your case the usage of the subant or ant tasks may be better suited, but nevertheless...
You can (but you should know/consider the side-effects!) extend ant with the common ant-contrib task definitions and use the var task which is able to override properties. Make sure to use the latest version (> 1.0b3).
<!-- adjust to your path and include it somewhere at the beginning of your project file -->
<taskdef resource="net/sf/antcontrib/antlib.xml" classpath="lib/ant-contrib-1.0b3.jar" />
<!-- works e.g. for basedir = /foo/bar to update it to /foo/bar/.. ~ /foo -->
<var name="basedir" value="${basedir}/.." />
update: but one has to be careful, because this does not change . (current working directory) (so <property name="x" location="tmp" /> would be relative to . and not to basedir anymore ; update: setting basedir outside of ant or via <project basedir= also sets . to basedir!). Here is some test target proving the effect on both:
<target name="tst.dummy.basedir-override">
<!-- example output:
tst.dummy.basedir-override:
[echo] basedir before: basedir=D:\tst, '.'=D:\tst\.
[echo] updating it via 'var' to '..'
[echo] basedir now: basedir=D:\tst/.., '.'=D:\tst\.
-->
<property name="cur" location="." /> <!-- makes the relative path absolute -->
<echo message="basedir before: basedir=${basedir}, '.'=${cur}" />
<echo message="updating it via 'var' to '..'" />
<var name="basedir" value="${basedir}/.." />
<property name="cur2" location="." /> <!-- makes the relative path absolute -->
<echo message="basedir now: basedir=${basedir}, '.'=${cur2}" />
</target>
I have a build process is in NAnt and resembles the following structure (a lot has been abreviated). I'm having some confussion on what I can put into Workflow from my NAnt Script and what I should convert to MSBuild(or not). Various targets within the NAnt script will set properties, copy files, delete files, make calls to external processes such as compiling VB6 projects. Any tips on porting this over to workflow would be greatly appreciated. Please let me know if you have questions.
<?xml ... >
<project ...>
<!-- Get and combine paths -->
<properties name="" value=""/>
<properties name="" value=""/>
<properties name="" value=""/>
.
.
.
.
<target name="Main">
<!--Set Log Folder Name to include date and time.
<mkdir dir="${LogDir}"/>
<call target="DeleteTicketsFile"/>
<call target="GetTickets"/>
<call target="WriteTicketsToFile"/>
<call target="WriteProperties"/>
<call target="DeleteFolders" failonerror="true"/>
<call target="GetLatest" failonerror="true"/>
<call target="BuildDOTNETSolution" failonerror="true"/>
<call target="BuildVB6Projects" failonerror="true"/>
.
.
.
<target name="BuildDOTNETSolution">
<property name="ProjectName" value="Localcache" />
<echo message="VCVarsAllBatFile = ${VCVarsAllBatFile}"/>
<exec program="${VCVarsAllBatFile}"/>
<property name="dotnetSlnFile" value="${path::combine(ProductDir, 'dot.net.sln')}"/>
<property name="dotnetOutFile" value="${path::combine(LogDir, 'dotnet.out.txt')}"/>
<echo message="dotnetSlnFile = ${dotnetSlnFile}"/>
<echo message="dotnetOutFile = ${dotnetOutFile}"/>
<delete file="${dotnetOutFile}" if="${file::exists(dotnetOutFile)}" failonerror="false"/>
<!-- Build .NET solution in Release mode -->
<exec program="${DevenvExe}">
<environment>
<variable name="COMSUPPORT" value="N"/>
<variable name="COPYEXECENV" value="N"/>
</environment>
<arg value='"${dotnetSlnFile}"'/>
<arg value='/Rebuild "Release|Any CPU"'/>
<arg value='/Out "${dotnetOutFile}"'/>
</exec>
</target>
</project>
My suggestion is to replace NAnt entirely and use TFS Build Workflow to customize and maintain your build. That said, if your NAnt script it pretty involved that can take some time (especially if you're new to TFS Workflow-based builds). My suggestion to start is to simply have the Workflow Build use the InvokeProcess Activity to execute the NAnt build via the command-line (nant.exe). Then you can incrementally move pieces of the build out of the NAnt script into the workflow.
For example, the entire BuildDotNETSolution target looks like it doesn't do anything special, all this is already included in the DefaultTemplate.xaml build workflow, you simply specify the SolutionsToBuild argument in the Build Definition.
I would like to do something like this
<target name="clean" description="clean">
<if>
<available file="${build}" type="dir" />
<then>
<delete dir="${build}" />
</then>
</if>
</target>
As per suggestions found on stackoverflow.com, i downloaded ant-contrib-1.0b3.jar and put it into my path
Additionally, under Ant Build configuration, in classpath, i have
When running my ANT script, i still get
BUILD FAILED
C:\Repositories\blah\build.xml:60: Problem: failed to create task or type if
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.
What am i missing? Please advise
Alternately, once can include the following line in your ANT script
<taskdef resource="net/sf/antcontrib/antlib.xml" />
As long as ant-contribs is in your path, nothing else is needed
This solution is a bit cleaner, as one gains access to ALL the tags, not just the ones manually specified
Same issue resolved in that way.
I put at the start of the buid XML file the following lines:
<taskdef resource="net/sf/antcontrib/antlib.xml">
<classpath>
<pathelement location="your/path/to/ant-contrib-${version}.jar" />
</classpath>
</taskdef>
The standard ant way would be something like =
<target name="check">
<condition property="delbuild">
<available file="${build}" type="dir"/>
</condition>
</target>
<target name="delbuild" depends="check" if="delbuild">
<delete dir="${build}"/>
<!-- .. -->
</target>
A snippet with the Ant Plugin Flaka, a recent alternative to antcontrib. Installation in Eclipse as usual via Preferences | Ant | Runtime | Global Entries | ant-flaka-1.02.-1.02.jar =
<project xmlns:fl="antlib:it.haefelinger.flaka">
<!-- some standalone if construct -->
<fl:when test=" '${build}'.isdir ">
<delete dir="${build}"/>
</fl:when>
<!-- some if/then/else construct -->
<fl:choose>
<!-- if -->
<when test=" '${buildtype}' eq 'prod' ">
<!-- then -->
<echo>..starting ProductionBuild</echo>
</when>
<when test=" '${buildtype}' eq 'test' ">
<!-- then -->
<echo>..starting TestBuild</echo>
</when>
<!-- else -->
<otherwise>
<fl:unless test="has.property.dummybuild">
<fail message="No valid buildtype !, found => '${buildtype}'"/>
</fl:unless>
<echo>.. is DummyBuild</echo>
</otherwise>
</fl:choose>
</project>
output with ant -f build.xml -Dbuildtype=prod or
ant -f build.xml -Dbuildtype=prod -Ddummybuild=whatever
[echo] ..starting ProductionBuild
output with typo => ant - build.xml -Dbuildtype=testt
BUILD FAILED
/home/rosebud/workspace/AntTest/build.xml:21: No valid buildtype !, found => 'testt'
output with ant -f build.xml -Ddummybuild=whatever
[echo] .. is DummyBuild
I got the same issue. I resolved in the following way.
Sometimes this might be compatibility problem.
Right click on build.xml.
Go to "Run As" --> 2 Ant... Select Classpath tab check Ant Home version (Sometimes eclipse selects default ant version).
If the version listed is different, then change Ant Home Classpath
to C:\XXXX\ant\X.X.X.
Finally click on the User Entries --> Add External JARS..--> add
ant-contrib.x.x.jar form C:\XXXX\ant\X.X.X\ant-contrib\ directory.
On the tasks tab for your Ant Runtime do you see the 'if' task?
export ANT_HOME=/path/to/ant/apache-ant-1.8.2
I couldn't get it to work until I had ANT_HOME set properly. Java kept picking another ant installed on the box.
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'm working on a library project that Blackberry Java developers can import into their projects. It uses protected RIM APIs which require that it be code-signed, which I have done. But, I can't get my Jar imported and working with a simple helloWorld app. I'm using the eclipse plug-in Blackberry-JDE.
EDIT : Solution found....
since I found the solution I removed the things I've tried, leaving only the solution ...
BUILDING THE SDK/Libary (use BB-ANT-TOOLS, either in eclipse or standalone)
steps:
A) I had to build my SDK's jar as an 'cldc' application not as a 'library'
project, using BB-ANT-TOOLS. This solved most of the issues I had above.
B) I then added an ANT task to take the resulting JAR from step A and
do the following:
unzip it,
edit the manifest file to remove the line "MicroEdition-Profile: MIDP-2.0" -- This line causes an error when you try to mark the jar for export.
then re-zipped the jar.
NOTE: I wrote a chopped down BB-ANT-TOOLS ant script to show how you could use
it to do these two steps above. The script is included below.
Consuming the SDK jar as an end-user or in your own project.
Then to integrate the jar in bb-eclipse you do the following:
A) Add the jar to the BuildPath
B) under "Java Build Path" on the "Order and Export" tab, Select the jar for
export. This causes rapc to build the jar into the COD file, so that you only
have one COD at the end.
now when a user builds this project the jar become integrated into the final
cod file, and it's very easy to deliver to the phone or sim.
<?xml version="1.0" encoding="UTF-8"?>
<project name="XXXXXMobileLib" default="full" basedir=".">
<description>
Description: Builds the BBLIB. Uses bb-ant-tools to build, sign and package for blackberry.
</description>
<taskdef resource="bb-ant-defs.xml" classpath="BIN/BB_ANT_lib/bb-ant-tools.1.x.x.jar" />
<property environment="env" />
<!-- User defined Vars -->
<property name="builderRoot" value="." />
<property name="SIG_PASSWORD" value="XXXXXXXXX" />
<property name="javaHome" value="${env.JAVA_HOME}" />
<echo>${javaHome}</echo>
<property name="jdehome" value="${env.BBJDE_HOME}\" />
<property name="simulator" value="${jdehome}\simulator" />
<property name="bin" value="${jdehome}\bin" />
<property name="releaseBuildOut" value="${builderRoot}\release_out\" />
<property name="srcBuildOut" value="${builderRoot}\srcBuild_out\" />
<property name="JarFixTemp" value="${builderRoot}\.tempZip\" />
<property name="buildVersion" value="${env.BUILD_VERSION}" />
<property name="application_id" value="com.XXXXX.foo.bar.${buildVersion}" />
<property name="application_name" value="XXXXX BBLIB v${buildVersion}" />
<property name="application_desc" value="XXXXX BBLIB v${buildVersion}" />
<property name="application_vendor" value="XXXXX" />
<property name="applicaiton_filename" value="XXXXXBBLIB${buildVersion}" />
<property name="applicaiton_srcs" value="${builderRoot}/src_in_location/" />
<property name="zipOutName" value="XXXXX-${buildVersion}BBLIB.zip" />
<property name="zipOutNameJavadocs" value="XXXXX-${buildVersion}BBLIBjavadoc.zip" />
<property name="jde.home" location="${jdehome}" />
<!--
MAIN ENTRY TARGET.
-->
<target name="full" depends="clean,javadoc,buildRIM,FixJarManifest,sign,distribute" />
<target name="FixJarManifest">
<tstamp/>
<mkdir dir="${JarFixTemp}"/>
<unzip src="${builderRoot}/release_out/${applicaiton_filename}.jar" dest="${JarFixTemp}"/>
<delete dir="${builderRoot}/release_out/${applicaiton_filename}.jar"/>
<!-- For some reason rapc puts this line into the manifest file, but it breaks the JDE plug-in when you try to
set the jar for export. Giving an error like this "Project {0} missing......"
To avoid having an empty line in the manifest, Im just injecting a new attribute BuildTime-->
<replace file="${JarFixTemp}/META-INF/MANIFEST.MF" token="MicroEdition-Profile: MIDP-2.0" value="Build-Time: ${DSTAMP}-${TSTAMP}"/>
<zip destfile="${builderRoot}/release_out/${applicaiton_filename}.jar"
basedir="${JarFixTemp}"
/>
<delete dir="${JarFixTemp}"/>
</target>
<!-- Cleanup any existing files in the outdir -->
<target name="clean">
<delete>
<fileset dir="${releaseBuildOut}" includes="**" />
</delete>
</target>
<!-- Generate the Javadocs -->
<target name="javadoc">
<javadoc access="public" destdir="${releaseBuildOut}/JavaDocs" author="true" version="true" use="true" defaultexcludes="yes" excludepackagenames="net.rim.*" windowtitle="FOO_BAR">
<fileset dir="${applicaiton_srcs}/XXXXXMobileLib">
<include name="src/**/*.java" />
</fileset>
</javadoc>
<zip destfile="${releaseBuildOut}/${zipOutNameJavadocs}" basedir="${releaseBuildOut}/JavaDocs" />
<delete dir="${releaseBuildOut}/JavaDocs"/>
</target>
<target name="buildRIM" description="Builds Project">
<rapc jdehome="${jdehome}" jdkhome="${javaHome}" destdir="${releaseBuildOut}" output="${applicaiton_filename}" quiet="false">
<!-- Building as a cldc applicaiton, so it can be packaged up with our final cod, as a single cod -->
<jdp type="cldc"
title="${application_desc}"
vendor="${application_vendor}"
version="${buildVersion}"
description="${application_desc}"
arguments=""
systemmodule="false"
runonstartup="false"
startuptier="7"
ribbonposition="0">
</jdp>
<src>
<fileset dir="${applicaiton_srcs}/MobileLib">
<include name="src/**/*.java" />
</fileset>
</src>
</rapc>
</target>
<target name="sign" depends="clean,buildRIM">
<sigtool password="${SIG_PASSWORD}">
<fileset dir="${releaseBuildOut}" includes="*.cod" />
</sigtool>
<echo>Contents of the signingtool's logfile: </echo>
<echo file="LogFile.txt" />
</target>
<!-- build and distribute the jar -->
<target name="distribute" depends="buildRIM" description="generate the distribution">
<alx destdir="${releaseBuildOut}" filename="${applicaiton_filename}.alx">
<application id="${application_id}" name="${application_name}">
<codset>
<fileset dir="${releaseBuildOut}" includes="*.cod" />
</codset>
</application>
</alx>
<!-- Create release zip -->
<delete file="${releaseBuildOut}/${zipOutName}" />
<zip destfile="${releaseBuildOut}/${zipOutName}">
<!-- zip up the BB jar and drop it for distribution -->
<zipfileset dir="${releaseBuildOut}" includes="**/*.jar" />
</zip>
<move todir="${releaseBuildOut}/UNUSED_BUILD_OUTPUT_FILES/"><!-- move unwanted files, leaving the zip behind -->
<fileset dir="${releaseBuildOut}">
<include name="**/*.*"/>
<exclude name="**/*.zip"/>
</fileset>
</move>
</target>
</project>
I have used your steps A & B to create a 'library' - thanks.
The latest Eclipse plugin for Blackberry (1.3.0.201102031007-19) has a "Blackberry | Package Project" command. I used this to create the jar file (it put it in a 'deliverables' folder in the project).
I then changed the manifest as you suggest to remove MIDP line (which apparently is a known bug). Finally, I followed the steps to add and deploy the lib to my project. (These, btw, are the same steps to adding the Banner / advertising library - very easy.)
I too have a stand-alone / external build script process that uses bb-ant-tools. I recently added the 'external library jar' feature to accommodate this. But using the new feature in Eclipse makes me question if I need to maintain my command-line build scripts as the GUI now does it for me.
The key for me was to switch the build of my library project to a "Blackberry Application" (e.g. CDLC app) as per your instructions. With it set as a 'Library' I was getting that "eviscerated" error.
Thanks for your post.