Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 327769

Summary: Support for directory based ant task libraries
Product: [Eclipse Project] Platform Reporter: Michal Ruzicka <michal.ruza>
Component: AntAssignee: Jeff McAffer <jeffmcaffer>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: c_lalyre, darin.eclipse, jeffmcaffer, Michael_Rennie
Version: 3.6Keywords: contributed
Target Milestone: 3.7 M4   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 327899    
Attachments:
Description Flags
org.eclipse.ant.core-directory_based_ant_libraries.patch
none
org.eclipse.ant.core-directory_based_ant_libraries_v2.patch
none
Alternative patch Michael_Rennie: iplog+

Description Michal Ruzicka CLA 2010-10-14 09:20:40 EDT 
Currently when a new task or an extra classpath entry is contributed (via the org.eclipse.ant.core.antTasks and org.eclipse.ant.core.extraClasspathEntries extension points respectively) to the org.eclipse.ant.core plugin, it is assumed that the respective contributed library is a jar file.
This is not always desirable, there are situations when it is advantageous/necessary for the classes making up the library not to be packed in a jar file but rather be present as plain files (either directly in a filesystem or as jar file entries in the contributing bundle's jar file depending on if the contributing bundle is drectory- or jar-based).

A notable example of a situation when this functionality would be necessary is a requirement to be able to use the bundle jar file as a *plain* jar file providing implementations of the ant tasks without having to use it through Eclipse. I.e. to be able to do something like the following in an ant script intended to be executed by a standalone ant (note that such a use assumes that the java packages/classes implementing the tasks are located in the root of the bundle jar file):

<taskdef name="contributed.task" classname="org.example.contributed.ant.Task">
	<classpath location="org.example.contributing.bundle.jar" />
</taskdef>

The functionality forms also a ground for supporting contributed ant tasks in a self hosted environment without the need to define custom builders used to create the currently required library jar files. Though some more work would have to be done on the ant classpath construction code to properly support that.
Comment 1 Michal Ruzicka CLA 2010-10-14 09:32:32 EDT 
Created attachment 180876 [details]
org.eclipse.ant.core-directory_based_ant_libraries.patch

A patch implementing the proposed functionality, including a small optimization of adding directly the bundle jar file to ant classpath in case the ant task library location happens to refer to the root ("/") of the bundle.
Comment 2 Darin Wright CLA 2010-10-14 09:49:37 EDT 
*** Bug 177756 has been marked as a duplicate of this bug. ***
Comment 3 Darin Wright CLA 2010-10-15 10:44:26 EDT 
Currently the Ant core bundle's execution environment is J2SE-1.4. The patch introduces references to StringBuilder which are not allowed. Can you update the patch?
Comment 4 Michal Ruzicka CLA 2010-10-15 19:45:09 EDT 
Created attachment 181027 [details]
org.eclipse.ant.core-directory_based_ant_libraries_v2.patch

Updated version of the patch in which StringBuffer is used instead of StringBuilder.
Comment 5 Darin Wright CLA 2010-11-09 09:37:10 EST 
*** Bug 329721 has been marked as a duplicate of this bug. ***
Comment 6 Jeff McAffer CLA 2010-11-09 10:19:53 EST 
Created attachment 182723 [details]
Alternative patch

Some comments on the current patch
- I'm not sure the File.SEPARATOR is the right thing to use in URI/URLs.  Don't they just say "/" and don't care what filesystem you are on?

- isBundleRoot() is too complex.  Here we can define the convention.  Simply say if (library.equals("/")) then it is the root.

- Since we have to copies of the same moderately subtle code, move it all into getClasspathEntry

I'm attaching an alternative patch that should have the same effect.
Comment 7 Jeff McAffer CLA 2010-11-09 10:23:35 EST 
Odd that marking as a dup does not bring over the "Blocks" bug numbers...
Comment 8 Michael Rennie CLA 2010-11-10 10:45:08 EST 
(In reply to comment #7)
> Odd that marking as a dup does not bring over the "Blocks" bug numbers...

Patch looks good and all of our junit / smoke test pass. It would be way more awesome(r?) if the patch included unit tests for the new functionality.
Comment 9 Michael Rennie CLA 2010-11-23 13:41:19 EST 
applied patch to HEAD, thanks Michal and Jeff.