Community
Participate
Working Groups
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.
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.
*** Bug 177756 has been marked as a duplicate of this bug. ***
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?
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.
*** Bug 329721 has been marked as a duplicate of this bug. ***
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.
Odd that marking as a dup does not bring over the "Blocks" bug numbers...
(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.
applied patch to HEAD, thanks Michal and Jeff.
