views:

247

answers:

3

Hi all, A Grails app I'm working on is becoming pretty big, and it would be good to refactor it into several modules, so that we don't have to redeploy the whole thing every time.

In your opinion, what is the best practice to split a Grails app in several modules? In particular I'd like to create a package of domain classes + relevant services and use it in the app as a module. Is this possible? Is it possible to do it with plugins?

Cheers, Mulone

+3  A: 

Hi Mulone,

that's what plugins are for. In case of splitting up a large app into several modules, using the "inline plugin" feature is extremly useful. Just add

 grails.plugin.location."<plugin-name>" = "<path to plugin dir>" 

to your app's grails-app/conf/BuildConfig.groovy. By doing so, you no longer have to run 'package-plugin' and 'install-plugin' after every modification inside a plugin. For details on using plugins, see Grails reference docs, or one of the available books: "Definitive Guide to Grails" or "Grails in Action". Both are absolutely worth their costs.

Regrads, Stefan

Stefan
+1  A: 

Grails' plugins are a good packaging mechanism for code/design/schema reusability across apps, or for clarifying code ownership across multiple authors (which seems likely for a large app), but I don't think they'll save you much in terms of deployment pain - after all, the code is still there in the app, and the app still has to configure the plugins, etc.

Yes, you'll save a little time due to caching of the plugin on the deployment target, but you'll pay that back with extra complications in code, test and in managing the versioning of the plugins themselves.

That said, I do think putting a domain+services plugin is a good module for reuse - we've just done that - but it more hurt than helped with deployment problems.

IMO, a 'best practice' for a big Grails app would be to think about splitting the app into smaller apps with communication either through the database or a memcache or via some form of messaging - lots cleaner for "don't have to redeploy the whole thing" and tends towards better scalability. Use plugins in each app where you want code/design reuse or schema isolation and are going to get enough reuse to justify the various overheads.

Wayne
A: 

Agreed, plugins are the accepted way to do this. This will help manage your code dependency graph and split your app into sections that are easier to test and understand independently. However plugins are still meant to knit together as one application when deployed. I'm not sure what pattern you're looking for for deployment.

John Stoneham