5

Every time I make a minor change to my Grails app it takes 10-15 seconds to deploy it. The majority of the time is in 'Resolving Dependencies'...

Welcome to Grails 1.3.7 - http://grails.org/
...
Resolving dependencies...
Dependencies resolved in 9868ms.

Here are some details of my setup:

  • MacBook (OS X 10.5.8) 2.4Ghz Core 2 Duo with 4GB RAM + plenty of disk space
  • SpringSource Tool Suite - Version: 2.6.1.RELEASE Build Id: 201105041000
  • Grails 1.3.7
  • A small Grails project with only a few domain models
  • Just a few plugins: hibernate 1.3.7, mail 1.0, spring-security-core 1.1.3, spring-security-open id 1.0.2, spring-security-ui 0.1.2, webtest 3.0.1

Areas Investigated Already:

  • Deleting the .ivy2 directory and forcing a complete external refresh did bring it down by around 5 seconds.
  • My .ivy2 directory is on my local machine so it's not this problem
  • I did have some dependency problems similar to these however I've now fixed them and I'm not getting any errors.
  • I've turned the logging on in BuildConfig.groovy by setting log "info" in the grails.project.dependency.resolution section. It appears to be spending most of the time 'resolving' the dependencies rather than actually downloading items, so I don't think mavenCentral or other public Maven repositories are a problem.

Extract from log...

resolution report  resolve 802ms  artifacts dl 86ms
resolution report resolve 8492ms  artifacts dl 150ms
Dependencies resolved in 9909ms.

Extra Info: By deploy I mean using 'run-app', by redeploy I mean changing a file that forces Grails to automaticaly do a 'run-app.' I don't have any other network related performance issues and have a 32MB down, 1MB up broadband internet connection.

For benchmarking I have worked on a similarly sized app in the past where the 'Resolving Dependencies' took around 1 second. That setup was Grails 1.3.6, Shiro security plugin, a similarly small project with a few domain models on a Windows XP service Pack 3 machine (Intel Core 2 Duo 2.2Ghz, 2GB RAM) Then I was using NetBeans 6.9.1.

Extra Info 2: The full ivy log is attached here

I'm changing very few files each time so it is extremely frustrating when it takes 15 seconds to do a redeploy.

Does anyone have any tips on how to reduce the time needed for 'Resolving Dependencies...'?

Chris
  • 3,552
  • 2
  • 26
  • 36
  • Are you experiencing any other network related issues (slowness) outside of Grails? How are you benchmarking the fact that 15 seconds is too long? Compared to what? Also, you might clarify what you mean by "redeploy". When I think of deploying, I think of dropping a WAR file in a servlet container. I believe you might just mean "restarting" the app with run-app? – Gregg Jun 08 '11 at 00:49
  • 1
    @Gregg, I've added the extra info directly into the question. – Chris Jun 08 '11 at 11:15
  • @Chris are there any snapshot dependencies? What do you see when you turn up the ivy logging level in your BuildConfig.groovy? For example I am 99% positive that the webtest plugin depends on snapshot dependencies. – Ben Doerr Jun 10 '11 at 14:07
  • @Tiggerizzy, The full ivy log is attached [here](https://docs.google.com/document/d/1mqeo_FIe9zeizmC_U0O53dqDDqZ6-7Mwbdrvzas_kpI/edit?hl=en_US&pli=1) and yes the htmlunit and webtests plugin filenames end with -SNAPSHOT – Chris Jun 10 '11 at 19:49
  • @Tiggerizzy, does the fact that some of the dependencies are 'snapshots' cause extra delays? What's the easiest way to fix this? – Chris Jun 14 '11 at 14:19
  • @Chris sorry for taking so long to get back to you. In theory each time you resolve your dependencies, Ivy is going to need to check the external repo to see if there is a new snapshot of the dependency. If you remove the webtest plugin does your dependency resolution quicken up? – Ben Doerr Jun 20 '11 at 15:31
  • @Tiggerizzy, thanks. That has made a big improvement! However, I want to use the plugin. Is there anyway to force it so that an external check is NOT made? – Chris Jun 23 '11 at 19:21

3 Answers3

4

Following up on our conversation in the comments.

The best way that I know of to reduce dependency resolution time if you have determined that the problem is not your network is make sure you don't have any snapshot dependencies. Snapshot dependencies are versions of a dependency in active development, so Ivy will need to actually go out to the external server to check if a new version of that snapshot is available.

I noticed that you mentioned that you are using the webtest 3.0.1 gr ails plugin. I know that this plugin depends on two snapshot jars. So removing this plugin should improve the time required for dependency resolution. I don't know of a way to override the dependencies specified in a plugin. In the case of the webtest plugin I don't think that there is a version of the dependency that would be acceptable other than the one specified. The best thing you can do is to nag the plugin author to remove the snapshots.

Ben Doerr
  • 1,655
  • 1
  • 13
  • 23
  • 1
    thanks. That has made a big improvement! However, I still want to use the plugin. If anyone else knows of a way to force Grails not to do external checks then please please let me know here!! – Chris Jun 29 '11 at 12:21
  • Is there a convenient way to check whether any of your plugin's use the snapshot dependencies? – Bagira Apr 09 '12 at 11:39
1

Just found out (through asking) that you can use a local repository to resolve your snapshot dependencies. This could be faster than over the network:

Grails: working offline with snapshot dependencies

Community
  • 1
  • 1
rdmueller
  • 10,742
  • 10
  • 69
  • 126
0

Please see my answer here. A plugin relying on a poorly defined maven artifact can cause grails to go and look every time for a newer version.

Grails very slow to resolve certain dependencies

Community
  • 1
  • 1
Peter
  • 29,498
  • 21
  • 89
  • 122