Developer Cloud Service: Continuous Integration with JDeveloper 12.2.1

The last blog showed that the Oracle Developer Cloud Service is now available for JDeveloper and ADF 12.2.1 (Developer Cloud Service with JDeveloper 12.2.1 available). The missing part is the connection of the DCS to the newly created JCS for version 12.2.1. This we show in the blog.

The ground work, how to set up a build system for the DCS has been shown in Fasten your seat belts: Flying the Oracle Development Cloud Service (3 – Take Off – ROTATE). We now have to find out which environment variable to use for the 12.2.1 installation. At the time I wrote the mentioned blog there where only environment variables for and available. Looking at the documentation Using Hudson Environment Variables we find that the variables

  • ORACLE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/jdeveloper
  • MIDDLEWARE_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1
  • WLS_HOME_SOA_12_2_1=/opt/Oracle/MiddlewareSOA_12.2.1/wlserver

Are the right ones (and the only ones which point to 12.2.1). In the file (from the ‘… Take Off…’ blog) we exchange

# Don't change anything below!


# Don't change anything below!

This change will use the JDeveloper 12.2.1 to run ojdeploy and configure the application to run on a WebLogic Server 12.2.1. This should do the trick and we can use the DCS build system to create application using ADF 12.2.1. As the application I used for the ‘Fasten your seat belts…’ blog series was pretty simple I like to show the result using the application I used for a presentation at the DOAG DevCamp2016, named AppsClouUIKit. You can read all about this application in a blog I wrote here DOAG DevCamp2016.

The application was build using JDeveloper and has been migrated during the DevCamp to 12.1.3. This was the DCS version which was available at the time of the DevCamp. The first task is to migrate the source to 12.2.1 by creating a new branch in the GIT repository for the new 12.2.1 version.

We Clone the repository and create a new branch 12_2_1 which we use to build the AppsCloudUIKit for 12.2.1. As we are now running JDeveloper 12.2.1 we can use the Team-Server to get the sources from the DCS GIT repository

But we can use any other GIT client to get it. As this is covers in other blogs I’ll skip the details here. In the end we have this branch tree

Where the green marked local branch 12_2_1 is the one we are working on.

After changing the application.properies as shown above we can run the build using ant on the local machine

By selecting the ‘deploy’ target.

The result is an EAR file in the deploy folder

Setting up the build job

Let’s check-in the changes and setup the build in the DCS. Here are the steps for the build job

With this we can build the application to get the result

Setting up the Deployment

The final task is to set up the deploy task to deploy the application on the JCS_12_2_1. When we select the ‘Deploy’ tab we see the existing deployment configuration for the 12.1.3 JCS.

For the JCS 12.2.1 we created a new JCS instance with a different IP (public). Before we can create a new configuration for the 12.2.1 JCS instance we have to allow the Hudson user access to the JCS. This process is described in detail at Deploying an Application from Oracle Developer Cloud Service to Oracle Java Cloud Service

It’s absolutely necessary to get the Oracle Developer Cloud Service SSH public key and add this key to the JSC 12.2.1 instance as authorized key. Please follow the instructions given in the link above to do so.

After this is done we can create a new deployment configuration

Start filling in the dialog by giving the configuration a name. Next we create a new ‘Deployment Target’

In the dialog fill in the public IP address from the new JC 12.2.1 and select SSH Tunnel. The user name and password is the one you selected when you created the JCD instance. Test the connection and close the dialog by clicking ‘Use Connection’

Finally we can complete the Deployment dialog

We choose ‘On Demand’ here which let us specify which job/Build and artifact to use. A click to ‘Save and Deploy’ closes the dialog and the artifact will be deployed to the JCS 12.2.1. The URL to open the application is AppsCloudUIKit 12.2.1

And we should see

Fasten your seat belts: Flying the Oracle Development Cloud Service (3 – Take Off – ROTATE)

The last part of the series 3 – Take Off – V1 we finished when we could build hte application using ANT on the local machine. In this part we are going to try this on the Oracle Developer Cloud. Finally we should see how Continuous Integration and Continuous Delivery works in the cloud.

I created a fresh set of ANT build scripts named ‘buildlocal.xml’ and ‘’ from the project to demonstrate the process. The original ones name ‘build.xml’ and ‘’ are the final result which I didn’t want to revert. So when you create the ANT scripts yourself you can user the default names ‘build.xml’ and ‘’. When I talk about build files I now mean the ones named ‘buildlocal.*’.

Demo Build Files

Demo Build Files

For the same reason we create a new build job in the cloud names ADFTestBuild to show the steps to take. The final build job is named ADFCommunuityFrkExt.
Demo Build Job

Demo Build Job

We pushed the files local build files already to the remote repository. Let’s run the build on the could. First we log into the Oracle Developer Cloud as team member and switch to the build tab and create a new build job (ADFTestBuild)

Note that we use JDK 7 to build the project. The Oracle Developer Cloud offers JDK 6-8 to work with. As we use JDev 12.1.3 we use JDK 7
JDK's available

JDK’s available

In the Source Code Management section we select the repository and branch to use for this job. The advanced section can be left blank as it’s filled by the system when you save the job. There are more advanced option you can set but they are not part of this post. All we nach to remember

Builds are dependent on ONE branch

The Build Trigger defines that each minute the CI system checks the SCM if something has changed. If yes, it schedules to execute the build job.

When we are finished with the feature we have to change the build job or to create a new one which uses the master or default branch to build on. In our situation where we implement the CI we set the branch to the one we are working on named ‘feature-setup-build’.

After saving the new job we can start it by clicking on the ‘Run Now’ button

Hm, the build did not work as it did on the local machine. This is shown by the icon in the first column of the job history table. To find out what went wrong we look at the output of the build by clicking on the ‘console’ button in the last column of hte table
Build output

Build output

In the first marked section we see the build file ‘buildlocal.xml’ which was used and in the second marked section the error message. It looks liek the build job can’t find the task ‘OJDeployAntTask’. A look into the buildlocal.xml file at line 40 reveals

   <taskdef name="ojdeploy" classname="oracle.jdeveloper.deploy.ant.OJDeployAntTask" uri="oraclelib:OJDeployAntTask"

where line 40 is the classpath in the above listing. This means that the variable “${oracle.jdeveloper.ant.library}” is not found. A look into the Oracle Developer Cloud at Developing Oracle ADF Applications with Oracle Developer Cloud Service give the needed information. We have to alter the build files
1. add a line

<property environment="env"/>

to the build.xml file before loading the
2. change the file to use information from the now loaded environemnt
The second part is a bit confusing. From the link above we learn to set a variable as
which is misleading a bit. The problem is that the developer cloud offers two environments to the user. One for 11g and one for 12c. As we use the one for 12c we have to use a different setup which can be found in the docs too at a different location Using Hudson Environment Variables. The second link tells us to use

Add property environment="env" to your build.xml to load the environment of the server
to the file to make use of hte servers environment.

With this info we can make the needed changes. The resulting is

#Fri Jul 24 15:06:08 CEST 2015
#Change the next three properties to match your projects names

# Don't change anything below!



and the build.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!--Ant buildfile generated by Oracle JDeveloper-->
<!--Generated Aug 22, 2015 3:15:37 PM-->
<project xmlns="" name="FrkExtModel" default="all" basedir=".">
  <property environment="env"/>
  <property file=""/>
  <path id="library.ADF.Model.Runtime">
    <pathelement location="${oracle.commons}/modules/oracle.idm_12.1.3/identitystore.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adfm.jar"/>
    <pathelement location="${oracle.commons}/modules/groovy-all-2.1.6.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adftransactionsdt.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.view_12.1.3/adf-dt-at-rt.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adfdt_common.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/adflibrary.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.xdk_12.1.3/xmlparserv2.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/db-ca.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.model_12.1.3/jdev-cm.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.ldap_12.1.3/ojmisc.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/commons-el.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/jsp-el-api.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.share_12.1.3/oracle-el.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.security_12.1.3/adf-share-security.jar"/>
    <pathelement location="${oracle.commons}/modules/oracle.adf.security_12.1.3/adf-controller-security.jar"/>
    <pathelement location="${oracle.commons}/modules/javax.mail_2.0.0.0_1-4-4.jar"/>
  <path id="classpath">
    <path refid="library.ADF.Model.Runtime"/>
  <target name="init">
    <mkdir dir="${output.dir}"/>
  <target name="info">
    <echo level="info">build: env.ORACLE_HOME=${env.ORACLE_HOME_12C3}</echo>
    <echo level="info">build: env.WORKSPACE=${env.WORKSPACE}</echo>
    <echo level="info">build: workspace=${workspace}</echo>
    <echo level="info">build: install.dir=${env.ORACLE_HOME_12C3}</echo>
    <echo level="info">build: oracle.commons=${oracle.commons}</echo>
    <echo level="info">build: oracle.jdeveloper.ant.library=${oracle.jdeveloper.ant.library}</echo>
    <echo level="info">build: oracle.jdeveloper.ojdeploy.path=${oracle.jdeveloper.ojdeploy.path}</echo>
    <echo level="info">build: oracle.jdeveloper.deploy.dir=${oracle.jdeveloper.deploy.dir}</echo>
    <echo level="info">build:${}</echo>
    <echo level="info">build: oracle.jdeveloper.workspace.path=${oracle.jdeveloper.workspace.path}</echo>
    <echo level="info">build: oracle.jdeveloper.deploy.outputfile=${oracle.jdeveloper.deploy.outputfile}</echo>
  <target name="all" description="Build the project" depends="info,deploy,compile,copy"/>
  <target name="clean" description="Clean the project">
    <delete includeemptydirs="true" quiet="true">
      <fileset dir="${output.dir}" includes="**/*"/>
  <target name="deploy" description="Deploy JDeveloper profiles" depends="init">
    <taskdef name="ojdeploy" classname="oracle.jdeveloper.deploy.ant.OJDeployAntTask" uri="oraclelib:OJDeployAntTask"
    <ora:ojdeploy xmlns:ora="oraclelib:OJDeployAntTask" executable="${oracle.jdeveloper.ojdeploy.path}"
        <ora:parameter name="workspace" value="${oracle.jdeveloper.workspace.path}"/>
        <ora:parameter name="project" value="${}"/>
        <ora:parameter name="profile" value="${}"/>
        <ora:parameter name="nocompile" value="false"/>
        <ora:parameter name="outputfile" value="${oracle.jdeveloper.deploy.outputfile}"/>
  <target name="compile" description="Compile Java source files" depends="init">
    <javac destdir="${output.dir}" classpathref="classpath" debug="${javac.debug}" nowarn="${javac.nowarn}"
           deprecation="${javac.deprecation}" encoding="UTF8" source="1.7" target="1.7" includeantruntime="false">
      <src path="src"/>
  <target name="copy" description="Copy files to output directory" depends="init">
    <patternset id="copy.patterns">
      <include name="**/*.GIF"/>
      <include name="**/*.JPEG"/>
      <include name="**/*.JPG"/>
      <include name="**/*.PNG"/>
      <include name="**/*.cpx"/>
      <include name="**/*.dcx"/>
      <include name="**/*.ejx"/>
      <include name="**/*.gif"/>
      <include name="**/*.ini"/>
      <include name="**/*.jpeg"/>
      <include name="**/*.jpg"/>
      <include name="**/*.png"/>
      <include name="**/*.properties"/>
      <include name="**/*.sva"/>
      <include name="**/*.tag"/>
      <include name="**/*.tld"/>
      <include name="**/*.wsdl"/>
      <include name="**/*.xcfg"/>
      <include name="**/*.xlf"/>
      <include name="**/*.xml"/>
      <include name="**/*.xsd"/>
      <include name="**/*.xsl"/>
      <exclude name="build.xml"/>
    <copy todir="${output.dir}">
      <fileset dir="src">
        <patternset refid="copy.patterns"/>
      <fileset dir=".">
        <patternset refid="copy.patterns"/>

The files above are the original ones and can be run from the build console to get this

Great, we now have successfully enabled CI in the cloud for the ‘Framework Extension’ project. Well, there is something more to think about. Can’t we use the same ANT build scripts on the local machine too?

Yes, we can but we have to make some adjustments for this.

Now that we read the environment from the server the ANT script is running on to set the some of the variables we need to set these environment variables on the local machine too. this can be done easily by altering the jdev start file (Linux) or using a batch to first set the environment variables and then start jdev (Windows). Below is my changes jdev start script


#  Launcher for Oracle JDeveloper 12c (

export MIDDLEWARE_HOME_12C3=/opt/jdev/
export ORACLE_HOME_12C3=/opt/jdev/
export WORKSPACE=/data/development/ENTW_12.
/opt/jdev/ $1

As you see I set the environment variables which are later read through the build.xml file before starting jdeveloper.
The one line
need special attention. It’s only necessary if you run JDev using different operating systems (Linux and Windows). The build file has one variable pointing to the the ojdeploy executable
Users using Windows need to add the suffix ‘.exe’ to this variable as ojdeploy can’t be started otherwise under Windows.
The problem is that we can’t add it for Linux systems as they don’t know this suffix. The solution I found is to add ${env.EXEC_SUFFIX} to the executable and set it to an empty string for Linux systems. For Windows systems you have to set this environment variable to ‘.exe’. For this I use a batch file where I use
~~~setx EXEC_SUFFIX .exe~~~
before starting JDev. In the same batch I set the other variables too

setx ORACLE_HOME_12C3 r:\Java\\Oracle\Middleware\jdeveloper
setx MIDDLEWARE_HOME_12C3 r:\Java\\Oracle\Middleware
setx EXEC_SUFFIX .exe

To make the build files work under Windows and Linux and iOS add an environment variable defining the suffix for executable files.

One final trick is to set the workspace directory. The file has one more environment variable workspace=${env.WORKSPACE} which we need to set.
As the workspace isn’t fix on a local machine, at least if you have more than one workspace, you can’t set this variable before you start JDev. This has to be done per workspace, when you change the workspace.
JDev has a solution for this in the ANT properties section

ANT Project Properties

ANT Project Properties

You can shoose from different variables JDev sets according to the workspace and project you are working with.
JDeveloper Variables

JDeveloper Variables

Set the env.WORKSPACE environment variable in the ANT properties of the project.

This concludes this part of the series. In the next post we finish the feature ‘feature-setup-build’ by introducing the code review function of the Oracle Developer Cloud. This will be followed by a post about building a simple ADF application with a UI which you use to show the Continuous Delivery (CD) option of the Oracle Developer Cloud.

Fasten your seat belts: Flying the Oracle Development Cloud Service (1- Boarding)

I’ll begin new a series about my findings on working with the Oracle Development Cloud Service. I’m not sure how many post will finally be part of this series, but I guess you’ll see a couple. Before we begin lets ask the big question:

What is the Oracle Oracle Development Cloud Service and what do you get from it?
The Oracle Development Could Service is one of the offerings around a whole bunch of other cloud services Oracle put out lately. It is one of the ‘Platform as a Service’ (PaaS) offerings

Platform as a Service - OverviewPlatform as a Service - Overview

Platform as a Service – Overview

which consists of a ready to use Weblogic Server, a ready to use CI Server (Hudson), a source code repository (Git, Ant, Maven), issue tracking, wiki and a ready to use Oracle DB. All this services can be provisioned in two different versions 11g ( and 12c (12.1.3). All components or services are configured and ready to use, even the right ADF Runtime is installed on hte Weblogic Server.
In summary you get a development environment for the enterprise. No need to download tons of software, searching for the versions which play well together. No time consuming installation of the software (I most often need multiple tries until I get what I think works best for myself). So you save a lot of time you normally need to get up and running.

You should download the small E-Book available from the Developers Cloud Service landing page which gives a more comprehensive overview.
All this you get with a nice and fancy Web-UI which looks like Alta but seems to be Skyros. Sometimes it’s a bit confusing where the services can be reached from (which button or icon), but I guess with more experience this won’t be an issue.

From the homepage of the cloud services

Oracle Cloud Home Page

Oracle Cloud Home Page

you can sign into different parts of the cloud:
Sign In - Oracle Cloud

Sign In – Oracle Cloud

The first thing is to select the right data center, as not all data centers available know which services you are allowed to use. In my case I use the ‘Public Cloud Service – NA’ to get to the login screen

Finally we see the dashboard with all available services
My Services - Dashboard

My Services – Dashboard

We see all the services which are working in the background to build the developer cloud. There is the Database Backup Service, the Database Service, the Compute Service, the Storage Service and the Java Service.
The Compute Cloud Service provides elastic compute capacity and allows to flexibly configure capabilities for the virtual machine running your services. It allows to configure security, ssh key management, block storage and network configuration for the Database Cloud Service and the Java Cloud Service. Finally it provides monitoring capabilities for the instances.
Compute Cloud Service - Overview

Compute Cloud Service – Overview

The Java Cloud Service holds the servers (admin and managed servers) as well as a Coherence server and a Load Balancer
Detailed View to Java Cloud Service Nodes

Detailed View to Java Cloud Service Nodes

It allows to get to the underlying configurations web applications like Weblogic Admin Console or Enterprise Manager
Java Could Service Overview

Java Could Service Overview

The central part of this blog however is the Developer Cloud Service
Developer Cloud Service - Overview

Developer Cloud Service – Overview

A click on the button to open the service console will bring up the Welcome Page of the Developer Cloud Service where you see all projects you have access to. You can also create a new project.
Welcome to Oracle Developer Cloud Service!

Welcome to Oracle Developer Cloud Service!

The term project is a bit misleading for developers with a background in JDeveloper. A project in the developer cloud holds one or more Git repositories, a maven repository, an issue tracker, a wiki and the Continuous Integration (CI) part as build and deployment. In the next parts of the series we’ll see more.
Cloud Project Overview

Cloud Project Overview

The build part can be either done using Ant or Maven. The administration part allows to change various parameters of the project. The small button marked with the red arrow allows to manage the users or team members working with this project.

This concludes the boarding of the plane we fly over the Developer Cloud Service. Stay tuned for the next part!

JDeveloper: Way to show a Version Number in the UI

My last presentation at the German ADF Partner Community showed how to put a version number into an application ear and allows two versions of the same application to exist on a managed WebLogic Server. One question I got from the audience was how to show this version in the UI of the application. This blog post shows one way of doing this.
For those readers which do not know how to put a version number into an application EAR before deploying it to a WLS, lets start with this.
Andrejus Baranovskis has a blog post How to set EAR Version for ADF Application on WebLogic about this which uses a more hand coded approach. Edwin Biemond showed a small ant script to do is. I will show you a different solution using ANT.
This solution consists of a general GeneralVersionBuild.xml ANT script and a project dependent VersoinBild.xml ANT script which sets some properties (the version properties) for the GeneralVersionBuild.xml. The GeneralVersionBuild.xml defines the targets to alter the different version numbers you define for your applications and print out the version in the log like

     [echo] VERSION: V1.0.0.3 DB.V1 vom 2012/02/12 21:09
     [echo] Major: 1
     [echo] Minor: 0
     [echo] Fix: 0
     [echo] Build: 3
     [echo] Date: 2012/02/12 21:09
     [echo] DB-Schema Version: 1
     [echo] --------------------------------------------------------------------------------------------------

The information above is the complied from the file which defines the different parts of the version number:

#Build version info
#Sun Feb 12 16:06:18 CET 2012
buildDate=2012/02/12 16:06

To manipulate the properties we use the targets defined in the GeneralVersionBuild.xml ANT script. This is called by the project dependent VersionBuild.xml ANT script:

<?xml version="1.0" encoding="UTF-8" ?>
<project name="AVIVersionBuild" default="make" basedir=".">
    <!-- # Relativ path to the base of the application -->
    <property name="root.dir" value=".."/>
    <property name="earFileBaseName" value="BlogAccessVersionInfo"/>
    <!-- PATH TO VERSION.PROPERTIES FILE (e.g.: src/de/hahn/blogxxxx/view/ -->
    <property name="" value="src/de/hahn/blog/accessversioninfo/view/"/>
    <property file="${}"/>
    <property name="deployFolder" value="../deploy/"/>
    <import file="${root.dir}/Versionierung/GeneralVersionbuild.xml"/>

All we need to do is to set the Versionbuild.xml file as ANT”Project Buildfile” file

Setup Ant Project Buildfile

Setup Ant Project Buildfile

Now that the project has a file (at src/de/hahn/blog/accessversioninfo/view/ holding information about the current version of the application we need a way to access this information on a page in the UI. As we are using a property file we can bind this file as resource bundle into the project and access the parts (properties) with EL.
To add the file as resource bundle we open the project properties, select the “Resource Bundle” node and then set the properties from the bundle as outputText onto the page.

Make sure that you select the right project when you add a property file.

Add a property file as bundle

Add a property file as bundle

Next search for the file in the project


Now in the page we can access the property via EL. We drag an outputText component on the page and select its value from Resource bundle
Select a value from resource bundle

Select a value from resource bundle

Select value from property file

Select value from property file

This will create this entry in your page

<c:set var="aviviewcontrollerBundle"

and here is the resulting outputText:

<af:outputText value="Version: #{aviviewcontrollerBundle.majorVersion}.#{aviviewcontrollerBundle.minorVersion}.#{aviviewcontrollerBundle.fixVersion}.#{aviviewcontrollerBundle.buildNum} from #{aviviewcontrollerBundle.buildDate}" id="ot6"/>

and the resulting page when you run the application

Running application

Running application

As you see the name of the resource bundle is set to “aviviewcontrollerBundle” (the default bundle name). This happens if you don”t already have a default bundle defined which contains a key value pair. You can rename it to e.g. “versioninfo” to make clear what the bundle is used for. In this case you have to change the EL to access to properties too.

    <c:set var="versioninfo"
 <af:panelGroupLayout id="pgl2">
    <af:outputText value="Version: #{versioninfo.majorVersion}.#{versioninfo.minorVersion}.#{versioninfo.fixVersion}.#{versioninfo.buildNum} from #{versioninfo.buildDate}" id="ot6"/>

The sample workspace can be downloaded from here Please rename the file to ‘.zip’ after downloading it! It was build using JDeveloper and uses the HR schema.

JDeveloper Gem: Debug Ant Scripts

I’m not sure if this feature of JDeveloper is widely known, but JDev allows you to debug ANT scripts as if they where java classes of a project.

I guess you normally don’t need to debug an ANT script, but sometimes it comes handy. A use case which comes up quite often lately is the installation for the FOD sample application. A couple of users have run into trouble running the MasterBuildScript from the FOD sample application. You can download the FOD sample from here.Be sure to load the FOD version for the JDeveloper version you are using.

After unzipping the demo you open the ‘Infrastructre’ work space from within JDev, open the ‘MasterBuildScript’ project and open the ‘Resources’ node. Here you find the ‘’ file which you need to adapt with your environmental settings.
Here is my sample file:

# Master Ant properties file for Fusion Order Demo
# All build files refer to this master list of properties
# Continuous builds override these settings
# $Id: 812 2007-02-20 07:14:33Z lmunsing $

# Base Directory for library lookup

# JDBC info used to create Schema

# Information about the default setup for the demo user.

Now, to debug an ANT script, open the build.xml file in the MasterBuildScript project and search for the ‘init’ target. Here you set a break point as if this were a java source file.

'init' Taget

'init' Taget

Now right click the ‘build.xml’ file and select ‘Debug Ant Target…’ from the list. From the submenu you select the ‘buildAll’ traget.

Select Target to Debug

Select Target to Debug

You should quickly hit the break point set on the ‘init’ target. You can step over (F8) or step into (F7) like you can do with normal Java files. Best feature (which is the reason for the blog post) is that you can see and change the properties defined by the ANT script.

See and change ANT properties

See and change ANT properties

This should help you find bugs in ANT scripts and hopefully solve them too.

Chris Muir (in his comment) pointed to one more use case which should be mentioned. To get even more knowledge about the targets which are executed in an ANT script you can set more options. To get to the dialog you select ‘Advanced…’ from the list of targets

Select  'Advanced...' to get to more options

Select 'Advanced...' to get to more options

Then you select the target for which you want to set more options
Select target

Select target

and then go to the ‘Options’ step to set e.g. ‘Verbose’ output
Set 'Verbose' option

Set 'Verbose' option

When you finished the dialog the selected target starts running and produces this output
Verbose output

Verbose output

The interesting part is, that using the ‘Advances…’ target only sets the options for the one run or debug of the selected target. If you like to set one of the options permanently, you can do this in the ‘Manage Ant Settings…’ or the project settings
Permanent settings of options

Permanent settings of options