Gradle, Artifactory, and Groovy Taking a Long Time to Resolve Dependencies

Hi everyone,

I’ve looked around on the gradle forum, but nothing really seems to perfectly match the exact issue we’re having. We’re using artifactory for local jar caching, and building using gradle pointing at our artifactory instance.

For some reason, though - the build we’re running still takes over 2 hours, if we’re behind our work proxy server on a specific windows machine. In the same network, running on a linux machine, the build finishes very rapidly. Running it from a home machine, the build finishes in about 6 seconds. It’s getting stuck during the dependency management step.

I’m actually writing about one of my coworkers’ machines, I’ve only been trying to help him troubleshoot it because it’s a big hangup for him. I might be able to get some logs, but I don’t have easy access to them - otherwise I’d just drop them in here.

So - if someone could help me run the right commands to get the right log messages I’m happy to insert them here. Otherwise - has anyone run into something like this before? He’s on a Windows 7 machine, which does have a corporate antivirus in it - if that matters at all.

Also, if he runs it with the -offline flag, everything seems to cooperate nicely.

you can run your build with the --profile option to generate a html report that contains more information where the time is spent.

Does it even take that long when you triggered it the second time? Maybe the network connection to artifactory is really slow in your coorporate environment.

Another thing that is often an issue in a coorporate environment is the virus scanner. During a gradle build a lot of files are generated (cache information, jars, etc.). Running virus scanner on the gradle cache and the current project directory can really be a big perfomance issue.


I wonder if virus scan might be the problem. All the rest of the development team aren’t using Windows, so they haven’t forced virus scan down on us yet.

can you provide more information (maybe provide the output of the --profile option) to understand where the huge time overhead is spent? cheers!