Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Plug-in Developer Guide
Previous Page Home Next Page

Contributing tasks and types

When your plug-in contributes Ant tasks and types, the tasks and types have access to all of the classes inside the contributing plug-in. For example, the eclipse.refreshLocal task contributed by org.eclipse.core.resources plug-in is a wrapper for the IResource.refreshLocal() method.

Tasks and types contributed by plug-ins must not be placed in any of the plug-in libraries. They have to be in a separate JAR. This means that the plug-in classes do not have access to the tasks and types provided by the plug-in.  (See Why a separate JAR for tasks and types? for more information.)

The org.eclipse.ant.core.antTasks extension point provides an example of how to specify a new task in the plugin.xml file.

Progress Monitors

The Eclipse Ant support provides access to an IProgressMonitor if one is passed when invoking the AntRunner. One of the advantages of having access to a progress monitor is that a long-running task can check to see if the user has requested its cancellation. The progress monitor object is obtained from the Ant project's references.  Note that a monitor is only made available if the method AntRunner.run(IProgressMonitor) was called with a valid progress monitor. The following code snippet shows how to obtain a progress monitor from the task's project:

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Task;
import org.eclipse.ant.core.AntCorePlugin;
import org.eclipse.core.runtime.IProgressMonitor;

public class CoolTask extends Task {

public void execute() throws BuildException {
	IProgressMonitor monitor = 
		(IProgressMonitor) getProject().getReferences().get(AntCorePlugin.ECLIPSE_PROGRESS_MONITOR);
	if (monitor == null) {
		...
	} else {
		...
	}
}
}

Important rules when contributing tasks and types

The following should work as a checklist for plug-in developers:

  • The JAR containing the tasks must not be a plug-in library (declared in <library></library>).
  • The task or type can reference any class available for the plug-in but plug-in classes must not access the tasks or types.
  • Native libraries should be loaded by the plug-in library classes and not tasks or types.

Why a separate JAR for tasks and types?

There are basically two requirements for running Ant in Eclipse that do not fit the plug-in model very well:

  • Change the Ant classpath at runtime
  • Change the Ant version at runtime

During runtime plug-in classloaders cannot have their classpaths expanded and plug-ins cannot change their dependencies. At the same time having separate JARs for the tasks and types is a good isolation from the plug-in classloading mechanism. Having these extra JARs declared by a plug-in permits adding the contributing plug-in to the Ant classpath as well.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire