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?
Thanks
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?
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.
You could use symlinks (also on Windows), or copy the artifacts into a ‘lib’ directory.
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.
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…