CODEWITHSUNDEEP
grailspluginsdependencies
Mikey
Mikey

Reputation: 4742

Grails wants to downgrade my plugins when I copy my app to a new machine

When I copy my app to a different machine and do 'grails run-app' grails seems to skip a step as far as updating its local plugins. (What I mean is the first computer has just done Downloading: plugins-list.xml, but when I run the app on the second machine, the new machine will not do that step.) I get this message: 

Loading Grails 2.0.3
Configuring classpath

Environment set to development.....
Packaging Grails application
You currently already have a version of the plugin installed [resources-1.1.6]. Do you want to update to [resources-1.1.5]? [y,n] n
Plugin resources-1.1.5 install aborted
Compiling 92 source files

Am I diagnosing this correctly, and how do I force an update? Also, if I do accept the downgrade my app breaks. Not sure whats up with that as it was working with 1.1.5 for a while..

What I feel like is happening is that grails makes a note in the project when grails' plugin magic was last updated, so that when I move the project the other grails mistakenly thinks it just updated. Is this at all correct?

Upvotes: 0

Views: 712

Answers (1)

ubiquibacon
ubiquibacon

Reputation: 10667

Are you specifying your plugins in your BuildConfig.groovy file or are you "installing" the plugins using the install-plugin command? My reading indicates usage of the install-plugin command isn't recommended anymore, you should instead specify the plugin as in your BuildConfig.groovy file then Grails will just handle it regardless of what machine you deploy on.

Example:

plugins {
    /*
    * build - dependency that is only needed by the build process
    * compile - dependency that is needed at both compile-time and runtime. This is the most common case
    * provided - dependency that is needed at compile-time but should not be packaged with the app (usually because it is provided by the container). An example is the Servlet API
    * runtime - dependency that is needed to run the application, but not compile it e.g. JDBC implementation for specific database vendor. This would not typically be needed at compile-time because code depends only the JDBC API, rather than a specific implementation thereof
    * test - dependency that is only needed by the tests
    */
    runtime ":cached-resources:1.0"
    runtime ":database-migration:1.1"
    runtime ":hibernate:$grailsVersion"
    runtime ":jquery:1.7.1"
    runtime ":resources:1.1.6"        
    runtime ":yui-minify-resources:0.1.4"
    runtime ":zipped-resources:1.0"

    compile ":cache-headers:1.1.5"
    compile ":commentable:0.8.1"
    compile ":jquery-ui:1.8.15"
    compile ":joda-time:1.4"
    compile ":searchable:0.6.3"
    compile ":spring-security-ldap:1.0.6" // Also installs spring-security-core

    build ":tomcat:$grailsVersion"

}

Note too that some plugins also require a special entry in the dependencies section of your BuildConfig.groovy file. The JodaTime plugin is one such plugin.

dependencies {
    compile "org.jadira.usertype:usertype.jodatime:1.9"
}

A plugin's docs should specify if any entry in the dependencies section is needed.

Upvotes: 3

Related Questions