1

My 'resolving dependencies' is up around 30 seconds for a lightening fast computer and network.

I've looked at this question Grails: Very slow deploy time. 'Resolving Dependencies...' takes 10+ seconds, and I don't appear to have any 'snapshot' dependencies. I've cleared out my ivy cache and forced a redownload of everything, no help. Enabling logging, these few lines are the offenders. Nothing is being downloaded, but it appears that attempts are made to look for something remotely every time, given my network traffic. Note these are the ONLY entries that have the [some number] version before them, and then a different one after - that can't be coincidence - what does it mean? How can I stop grails from trying to find these slightly different versions?

    .... these lines take 20+seconds, everything else is in the milliseconds ...
found commons-logging#commons-logging;1.1.1 in grailsPlugins
[1.1.1] commons-logging#commons-logging;[1.1, 2.0)
found org.apache.httpcomponents#httpclient;4.1.2 in default
[4.1.2] org.apache.httpcomponents#httpclient;[4.1, 5.0)
found org.apache.httpcomponents#httpcore;4.1.2 in default
found org.codehaus.jackson#jackson-core-asl;1.9.1 in default
[1.9.1] org.codehaus.jackson#jackson-core-asl;[1.4,)
found javax.mail#mail;1.4.4 in default
[1.4.4] javax.mail#mail;[1.4,)

I am using two plugins that must be the offenders, and have listed their dependencies.groovy below. I've tried commenting out any explicit remote URLs. 

SimpleDB:

    grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"

grails.project.dependency.resolution = {

    inherits "global"

    log "warn"

    String datastoreVersion = "1.0.0.M9"

    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()
        mavenRepo "http://repo.grails.org/grails/core" //tried commenting this out, no help
        mavenLocal()
        mavenCentral()
        mavenRepo 'http://repository.codehaus.org'  //tried commenting this out, no help

}

dependencies {

    def excludes = {
        transitive = false
    }
    compile("org.grails:grails-datastore-gorm-simpledb:$datastoreVersion",
             "org.grails:grails-datastore-gorm-plugin-support:$datastoreVersion",
             "org.grails:grails-datastore-gorm:$datastoreVersion",
             "org.grails:grails-datastore-core:$datastoreVersion",
             "org.grails:grails-datastore-simpledb:$datastoreVersion",
             "org.grails:grails-datastore-web:$datastoreVersion") {
         transitive = false
     }        

    runtime("stax:stax:1.2.0", excludes)
    runtime('com.amazonaws:aws-java-sdk:1.2.0')

    test("org.grails:grails-datastore-gorm-test:$datastoreVersion",
         "org.grails:grails-datastore-simple:$datastoreVersion") {
        transitive = false
    }
}

plugins {
    build ":release:1.0.0.RC3", {
        exported = false
    }
}

}

Ajax uploader:

 grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.release.scm.enabled=false

grails.project.dependency.resolution = {
    // inherit Grails' default dependencies
    inherits("global") {
        // uncomment to disable ehcache
        // excludes 'ehcache'
    }
    log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()

        // uncomment the below to enable remote dependency resolution
        // from public Maven repositories
        mavenLocal()
        mavenCentral()
        //mavenRepo "http://snapshots.repository.codehaus.org"
        //mavenRepo "http://repository.codehaus.org"
        //mavenRepo "http://download.java.net/maven/2/"
        //mavenRepo "http://repository.jboss.com/maven2/"
    }
    dependencies {
        // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.

        test 'org.gmock:gmock:0.8.1'
    }
    plugins {

        //build ':release:1.0.0.RC3'

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

2 Answers2

6

and I've found the culprit. If a plugin you use relies on a library in maven that has 'open ended' dependencies, grails will go and look each time if there are newer versions to download in the range. I have no idea why anyone would specify it like this. It seems it would lead to unreliable behaviour. For me, the culprit is Amazon's java aws library, naturally required by the simpledb plugin that talks to Amazon's cloud.

http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10

note how some of its dependencies are like this

org.apache.httpcomponents httpclient [4.1, 5.0)

it appears that every time, grails is looking for a newer version (and downloading if it exists, I just noticed 4.2-alpha1 of httpclient come down when I ran this time).

By removing that dependency from the plugin and manually adding the required libraries to my .lib folder, I reduced my startup time from >30sec to <1sec

Peter
  • 29,498
  • 21
  • 89
  • 122
  • 1
    If your grails startup time is <1sec, I want your computer! What on earth are your system specs? My startup time on a quad core with 8gb ram, and fast SSD is about 15 seconds at best. – virtualeyes Nov 23 '11 at 09:26
  • I can almost guarantee you still have dependencies that are trying to call over the wire to resolve everytime like I've mentioned above. My specs are similar (newer macbook pro, 8gigs ram, SSD) – Peter Nov 27 '11 at 16:55
  • Could be the be the case, but nonetheless, I find it very hard to believe that you are getting <1sec startup time, that's absurd. On 2.0 RC1 with a vanilla create-app'd app, startup time with #grails followed by grails> run-app is @10 seconds and that is with BuildConfig's repositories {...} block commented out – virtualeyes Nov 27 '11 at 18:28
  • 1
    Can you please clarify what exactly you did to achieve such blazing fast startup times?? My biggest gripe with Grails to-date is the slow startup time (as you inevitably must restart on domain class change, src/groovy change, etc. despite the improved reloading agent) – virtualeyes Nov 27 '11 at 18:30
  • whoah, wait a sec, doing 'exit' instead of ctrl-c made for a blazing fast restart, ha ha, that is more like it! – virtualeyes Nov 27 '11 at 18:32
  • Glad you got somewhere! I really didn't do anything special. Note I'm still using 1.3.7 not 2.0 RC1. I am doing everything from withing Intelli-J and not the console but that shouldn't make any difference as all it does is invoke 'grails' commands' – Peter Nov 28 '11 at 19:38
  • I believe on 2.0 the suggested approach is via console and not IDE, at least for STS last I checked. At any rate, literally dropped grails due to the slow restart issue alone (have been checking out scala and scala frameworks for the past 2 months). When I heard 2.0 RC1 was out, I thought I'd see if anything changed re: restart times, same deal, dog slow. Then I chanced across your post and the eureka moment happened ;-) – virtualeyes Nov 29 '11 at 18:18
  • 3
    virtualeyes - can you clarify what you mean by 'exit instead of ctrl-c' ? That doesn't make any sense to me. :/ – kimsal Jan 04 '12 at 00:20
3

If you run grails --offline run-app, then dependency resolution gets (at least partially) disabled and startup time is much quicker.

Of course you have to be sure that you don't need any new dependencies to be downloaded - I've had spent time scrounging around for a solution for a problem which turned out to be because I was running grails offline. I learnt quickly though :)

I agree that Grails startup times are horribly slow, luckily the rest of the framework improves productivity - mostly to the point where you're more productive than plain old java :-)

bvanklinken
  • 207
  • 2
  • 8