Hoàng Long
Hoàng Long

Reputation: 10848

Overview of Grails project structure

I'm trying to find the overview about Grails project structure, as fully as possible. As I see, not all projects used the default structure generated by "grails create-app"

%PROJECT_HOME%
    + grails-app
       + conf                 ---> location of configuration artifacts 
           + hibernate        ---> optional hibernate config
           + spring           ---> optional spring config
       + controllers          ---> location of controller artifacts
       + domain               ---> location of domain classes
       + i18n                 ---> location of message bundles for i18n
       + services             ---> location of services
       + taglib               ---> location of tag libraries
       + util                 ---> location of special utility classes 
       + views                ---> location of views
           + layouts          ---> location of layouts
   + lib
   + scripts                  ---> scripts
   + src
       + groovy               ---> optional; location for Groovy source files
                                   (of types other than those in grails-app/*)
       + java                 ---> optional; location for Java source files
   + test                     ---> generated test classes
   + web-app
       + WEB-INF

Is there any more default folder by Grails? (For instance, I saw grails-app/jobs)

Upvotes: 13

Views: 10328

Answers (1)

Burt Beckwith
Burt Beckwith

Reputation: 75681

The directory structure is followed for the most part by all applications because artifacts are defined primarily by their root folder. Controller class names end in 'Controller', and taglibs and services have similar naming conventions, but domain classes don't have any name restrictions. So it's the location under grails-app/domain that defines a groovy class as a domain class.

Grails allows applications and plugins to define extra artifact types however, and that's what you're seeing with the 'jobs' folder. That's created by the Quartz plugin. I do something similar in the dynamic-controllers plugin where I add a new controllerMixins folder under grails-app where controller mixin classes are kept.

The benefit of creating a new artifact rather than keeping code under src/groovy is that it's simple to support reloading in development mode, and it groups code logically rather than dumping everything into one folder (src/groovy) and relying on packages to keep things separate. You also have quick access to all artifacts of any type. application.getDomainClasses() returns all domain classes, but the method is dynamically resolved so if you have Quartz installed you automatically get support for application.getJobClasses() without having to register or configure anything beyond the standard artifact registration.

Upvotes: 9

Related Questions