Jump to: navigation, search

Difference between revisions of "Ant/User Guide"

< Ant
 
(One intermediate revision by one other user not shown)
Line 13: Line 13:
 
# Extract the new version of Ant and rename the folder to ant-1.8.4 - or whatever the version is you are trying to update to. This name can be anything, I just kept it in the same form as what the Mac names it.
 
# Extract the new version of Ant and rename the folder to ant-1.8.4 - or whatever the version is you are trying to update to. This name can be anything, I just kept it in the same form as what the Mac names it.
 
# Move this new version of Ant to the shared java folder <pre>/usr/share/java</pre> by running <pre>sudo mv ant-1.8.4 /usr/share/java/ant-1.8.4</pre>
 
# Move this new version of Ant to the shared java folder <pre>/usr/share/java</pre> by running <pre>sudo mv ant-1.8.4 /usr/share/java/ant-1.8.4</pre>
# The last step pis to make sure that the system links for Ant get updated to the new version. To do this we have to move the symlink from the old version by running <pre>sudo ln -s -n -f /usr/share/java/ant-1.8.4/ /usr/share/ant</pre>
+
# The last step is to make sure that the system links for Ant get updated to the new version. To do this we have to move the symlink from the old version by running <pre>sudo ln -s -n -f /usr/share/java/ant-1.8.4/ /usr/share/ant</pre>
 
# Then we can confirm the new version is in use by once again running <pre>ant -version</pre>
 
# Then we can confirm the new version is in use by once again running <pre>ant -version</pre>
  
Line 32: Line 32:
 
When developing an ant task to be included in an Eclipse plug-in, you can debug the task using self hosting.
 
When developing an ant task to be included in an Eclipse plug-in, you can debug the task using self hosting.
  
1) Start a runtime workbench
+
# Start a runtime workbench same as you would when debugging any other plug-in.
 
+
# Create a new ant script, it doesn't matter what kind of project you put the script in. Fill in the script with the proper targets and properties.  When calling your tasks, you will have to put in their full name as defined in the org.eclipse.ant.core.antTasks extension.  When running from a built jar, just the name of the class is satisfactory, but when self hosting we need the full name.
Same as you would when debugging any other plug-in.
+
# Create a new ant launch configuration by right-clicking on the script and hold down Ctrl while clicking "Debug > Ant Script".  You can also open the launch config dialog from the main menu, "Run > External Tools > External Tools Configurations".
 
+
# Set up configuration options and give the configuration a name.  On the JRE tab, select "Run in the same JRE as the workspace".  If you don't change this option, debugging won't work correctly.
2) Create a new ant script
+
# Run the configuration and if there is a problem running the task, check that you have the full name of the task written in.  You can also check that Ant knows about your task by looking on the Ant > Runtime preference page (the Tasks tab will list all known tasks).
 
+
# Start debugging by setting some breakpoints in the host workspace.  Make sure you debug your ant script (not just run it). Note: Hot Code Replace does not work when debugging this way as the jar containing the tasks must be rebuilt.
It doesn't matter what kind of project you put the script in.
+
 
+
Fill in the script with the proper targets and properties.  When calling your tasks, you will have to put in their full name as defined in the org.eclipse.ant.core.antTasks extension.  When running from a built jar, just the name of the class is satisfactory, but when self hosting we need the full name.
+
 
+
3) Create a new ant launch configuration
+
 
+
Right click on the script and hold down Ctrl while clicking "Debug > Ant Script".  You can also open the launch config dialog from the main menu, "Run > External Tools > External Tools Configurations".
+
 
+
4) Set up configuration options
+
 
+
Give the configuration a name.  On the JRE tab, select "Run in the same JRE as the workspace".  If you don't change this option, debugging won't work correctly.
+
 
+
5) Run the configuration
+
 
+
If there is a problem running the task, check that you have the full name of the task written in.  You can also check that Ant knows about your task by looking on the Ant > Runtime preference page (the Tasks tab will list all known tasks).
+
 
+
6) Start debugging
+
 
+
Set some breakpoints in the host workspace.  Make sure you debug your ant script (not just run it).
+
 
+
Note: Hot Code Replace does not work when debugging this way as the jar containing the tasks must be rebuilt.
+
  
 
== The Ant View ==
 
== The Ant View ==

Latest revision as of 16:36, 30 December 2013

Platform Ant
Website
Download
Community
Mailing ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source

Updating Ant on Mac OSX

This section contains some simple steps to update the version of Ant being used by Mac OSX 10.8.2.

By default the version of Ant in 10.8.2 is 1.8.2, and at the time of this writing, the latest stable version of Ant is 1.8.4. Naturally, there is no simple way to just tell the Mac to update Ant so we have to hit up the command line (Terminal).

Steps:

  1. Grab the latest version of Ant
  2. Open the Terminal app
  3. Confirm what version of Ant you currently have installed by running
    ant -version
  4. Extract the new version of Ant and rename the folder to ant-1.8.4 - or whatever the version is you are trying to update to. This name can be anything, I just kept it in the same form as what the Mac names it.
  5. Move this new version of Ant to the shared java folder
    /usr/share/java
    by running
    sudo mv ant-1.8.4 /usr/share/java/ant-1.8.4
  6. The last step is to make sure that the system links for Ant get updated to the new version. To do this we have to move the symlink from the old version by running
    sudo ln -s -n -f /usr/share/java/ant-1.8.4/ /usr/share/ant
  7. Then we can confirm the new version is in use by once again running
    ant -version

Refactoring Buildfiles

There was some interesting ideas and work on buildfile refactorings here.

Debugging Buildfiles

Ant provides a debugger that allows you to step through you build scripts. You can add breakpoints, then step through the script. There is also support for mouse hovering and the variables view.

Debugging Ant Tasks with the Remote Debugger

See this blog post.

Debugging Ant Tasks with Self Hosting

When developing an ant task to be included in an Eclipse plug-in, you can debug the task using self hosting.

  1. Start a runtime workbench same as you would when debugging any other plug-in.
  2. Create a new ant script, it doesn't matter what kind of project you put the script in. Fill in the script with the proper targets and properties. When calling your tasks, you will have to put in their full name as defined in the org.eclipse.ant.core.antTasks extension. When running from a built jar, just the name of the class is satisfactory, but when self hosting we need the full name.
  3. Create a new ant launch configuration by right-clicking on the script and hold down Ctrl while clicking "Debug > Ant Script". You can also open the launch config dialog from the main menu, "Run > External Tools > External Tools Configurations".
  4. Set up configuration options and give the configuration a name. On the JRE tab, select "Run in the same JRE as the workspace". If you don't change this option, debugging won't work correctly.
  5. Run the configuration and if there is a problem running the task, check that you have the full name of the task written in. You can also check that Ant knows about your task by looking on the Ant > Runtime preference page (the Tasks tab will list all known tasks).
  6. Start debugging by setting some breakpoints in the host workspace. Make sure you debug your ant script (not just run it). Note: Hot Code Replace does not work when debugging this way as the jar containing the tasks must be rebuilt.

The Ant View