Home > grails, plugins, structuring > Structuring Grails Projects

Structuring Grails Projects

A Plain Project

Creating a Grails project is damn easy. Just run

grails create-app

and Grails will create the initial project structure with the grails-app folder. The grails-app folder indeed is not just a simple folder but resembles the “convention over configuration” approach – meaning that each folder within it has a predefined meaning to the grails web application framework.


So far so good. But there are times when you are working on applications that go beyond the simple CRUD application style – some call them “enterprise applications”. I guess there is no unique definition of what it really means for an application to be an “enterprise application”, but there is at least one thing you as a software developer will have to come up with: structuring your application into several components.


Grails indeed has a neat mechanism that supports structuring your applications into several components: plugins.


The Plugin Concept


You might already know that there are hundreds of Grails plugins available – just take a look at http://grails.org/plugins. Even we know plugins of being an integration gateway to other frameworks such as Compass, Spring WebFlow, etc. they can be seen as a great mechanism to create independent components within your application too. 


Let’s assume i wanted a component which encapsulates and holds my application’s business domain. In my project’s folder I already created the main project by running 


grails create-app GrailsEnterpriseApplication


In order to create a separate component for my domain model, i would create a new plugin with


grails create-plugin GrailsEnterpriseDomain


After executing these steps, the overall project’s structure will look like this (i.e. in IntelliJ)





Hint: just ignore the two tomcat plugin projects, Grails 1.2.1 defines dependencies on it when creating apps and plugins. 


Since every Grails plugin in fact is a Grails application we can use all the creation and generation commands available in Grails from within that project. For example, running


grails create-domain-class org.ast.User


on the GrailsEnterpriseDomain project will create a new domain class User and the according unit tests in our application’s domain plugin. This means that it’s possible for another group of developers to work independently on that component, without any restrictions on testing, creating artifacts and so forth.


So far we have not defined a reference between the main project and the plugin. In Grails 1.2.1 this can be done with an entry in the application.properties file in the main project:


plugins.grails-enterprise-domain=0.1


This line in fact means that our GrailsEnterpriseApplication depends on version 0.1 (the initial version) of our GrailsEnterpriseDomain plugin.


The last step for being able to reference our custom plugin at runtime is the execution of the 


grails package-plugin


command on the GrailsEnterpriseDomain project. This command create a zip archive of your plugin but more importantely a plugin.xml file which later on is used by the main application on bootstrap, for loading and resolving possible dependencies of our domain plugin. So if our domain plugin would depend on other plugins, Grails would resolve those dependencies on application startup.


There are several commands and configuration settings to define plugin repositories and push plugins to them, but as it is the case here we just want to use our domain plugin without packaging and deploying it, as this is the case when the initial development work is done. Luckily there is a configuration setting in Grails 1.2.1’s BuildConfig.groovy which allows the specification of local unpackaged plugins:


grails.plugin.location.’grails-enterprise-domain’ = “../GrailsEnterpriseDomain”


When adding this line to the GrailsEnterpriseApplication’s BuildConfig.groovy, Grails on startup instead of using plugin repositories makes a local file system lookup to load the grails-enterprise-domain plugin.


As a consequence running i.e. 


grails generate-controller org.ast.User


in the GrailsEnterpriseApplication project (!) automatically will reference the User class in your domain plugin. Meaning that separating the business model from the MVC part of your application can be done easily.


Summary


Of course, the example just showed a very simple use-case but I think you got the idea. Through Grail’s plugin mechanism it is possible to create structured applications with explicit dependencies/automatic dependency resolution and even with revision management included.


[0] Grails Plugin Portal – http://grails.org/plugins
[1] Grails Plugins Introduction – http://grails.org/doc/latest/guide/12.%20Plug-ins.html



Advertisements
Categories: grails, plugins, structuring
  1. ew
    April 9, 2010 at 11:32 am

    Hi,
    nice article, similar to another one i read lately (http://www.nslms.com/2010/03/10/modularizing-your-grails-application-domain-classes/)

    I have a simple scenario, which I would really value your opinion on.

    I have modularized my app into a grails web app, a domain plugin and a services plugin. (the services plugin is doing some complicated stuff I want to seperate out and maybe reuse again)

    Naturally the controllers of my web app are doing some crud – so the web app will need the domain plugin.
    My services plugin will also need db access so it will also need the domain plugin.

    I then have two questions
    1) the fact that i am using the domain plugin twice, does this mean 2 spring app contexts and 2 hibernate caches will be created ?
    2) would it be a better idea to just have the services plugin depend on the domain plugin and then just have the grails app depend on the services plugin.

    • April 9, 2010 at 12:05 pm

      hi,

      ad 1) after all, each Grails application is a Spring application. The Grails plugin-mechanism adds modularization and versioning to certain code parts of your application, but that is purely a Grails feature. If you take a look at your application’s applicationContext.xml, there is a bean called pluginManager. This bean bootstraps all registered Grails plugins during the application’s startup. In a nutshell: there is only a single application context, since Grails itself is based on Spring beans building a separate logical layer above the Spring container.

      ad 2) if there is a chance your domain plugin can be used without the services, do it that way (domain <- services <- app). if domain classes are always used in conjunction with service classes (which I would, in a DDD sense, assume to be part of the domain model) , bundle them together: less plugins mean reduced complexity (and less trouble with class-loading).

  1. April 11, 2010 at 6:29 pm
  2. April 13, 2010 at 5:30 am
  3. July 23, 2010 at 7:10 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: