Test classpath gets too long for windows

(Phil Swenson) #1

We have a gradle test that forks off an new process in java code and because of the deeply nested nature of the gradle cache, the classpath gets way too long.

Does anyone have a suggestion on how to handle this?


JavaExec fails for long classpaths on Windows
(Peter Niederwieser) #2

You mean your own code forks off a new Java process whose class path gets too long? Which files does it put on the class path?

(Phil Swenson) #3

yes. It puts all the dependencies in the classpath of this forked process. Since the gradle libs are deeply nested in the gradle cache, this blows up on windows.

(Peter Niederwieser) #4

You could use symlinks (also on Windows), or copy the artifacts into a ‘lib’ directory.

(Phil Swenson) #5

I think in general, the answer is a pathing jar. However, my solution ended up being finding a bunch of unused dependencies and removing them.

(bak2k2) #6

Can you tell us how you made that pathing.jar worked? on windows we are not able to make that work… we are creating the pathing jar… but gradle is including that as additional jar instead of replacing all the jars within it…