Clarification on classpath for Ant task OR Gradle Plugin running in Gradle

I’ve been running a custom ant task successfully for a while and it works pretty good.
Recently I updated the code for the ant task so that it relies on a library which loads a config file from the classpath.

The interesting thing is that the config file was not loadable and when I looked into it further by printing out the classpath from within the ant task’s java implementation I see only one entry instead of the 30 or so I have set in the build.gradle file.

This is weird because the ant task itself is not even in the classpath so I am puzzled how it is running that even.
Printing out the classpath from within the java implementation of the ant task is just this:

here is java.class.path:

/home/someuser/.gradle/wrapper/dists/gradle-4.7-bin/73xux3q4721jgr4pjvqf9o30/gradle-4.7/lib/gradle-launcher-4.7.jar

The classpath which is set in the build.gradle file which actually has the ant task class as well as the other dependencies (which I had thought I would see printed out in the tasks execution) looks like this when printed from the build.gradle itself:

/home/someuser/development/someuser-core/legacylibs/commons-net-2.0.jar:/home/someuser/development/someuser-core/legacylibs/commons-vfs-1.0.jar:/home/someuser/development/someuser-core/legacylibs/customizer.jar:/home/someuser/development/someuser-core/legacylibs/jamon-2.6.jar:/home/someuser/development/someuser-core/legacylibs/jdic.jar:/home/someuser/development/someuser-core/legacylibs/jdic_native_applet.jar:/home/someuser/development/someuser-core/legacylibs/jdic_stub_unix.jar:/home/someuser/development/someuser-core/legacylibs/jdic_stub_windows.jar:/home/someuser/development/someuser-core/legacylibs/jdo2-api-2.3-ea.jar

Anyone have some knowledge to share regarding:

  1. how is the task even running at all when it’s helloworld prints the classpath but it doesn’t include the stuff setup in the build.gradle
  2. what is the proper way to get a classpath setup for the custom ant task

In build.gradle I am doing this (which works but it doesn’t have the “real” classpath in the executing code so it can’t load resources properly):

task "all-hello-world" {
logging.level = LogLevel.DEBUG
  description "prints classpath as seen from inside ant task."
  doFirst {
    ant.taskdef(name: 'helloworld',
      classname: 'someuser.antlink.HelloWorld',
      classpath: (configurations.helloworldabc + configurations.compile).asPath
	)
    ant.helloworld() {     
    }
  }
}

Here is the custom ant task:

package someuser.antlink;
import java.net.URL;
import java.net.URLClassLoader;
/**
	https://discuss.gradle.org/t/clarification-on-classpath-for-ant-task-running-in-gradle/28741
*/
public class HelloWorld {
	public void execute() {
		System.out.println("Hello World");
		printClasspath();
		System.out.println("classpath should have been printed just now.");
		
		System.out.println("that should have been bigger??????????????????????????");
		System.out.println("here is java.class.path:" + System.getProperty("java.class.path"));
		System.out.println("how can this not have even this HelloWorld class on the classpath?? something bootstrappy or weird going on...");
	}
	
	public void printClasspath() {
		URL[] urls = ((URLClassLoader)ClassLoader.getSystemClassLoader()).getURLs();
		for(int i=0; i< urls.length; i++) {
			System.out.println(urls[i].getFile());
		}
	}
}

I encounter the same single classpath entry when attempting to use a custom gradle plugin as well.