18.3 Providing Basic Artefacts - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari
Version: 3.1.4
18.3 Providing Basic Artefacts
Add Command Line Commands
A plugin can add new commands to the Grails 3.0 interactive shell in one of two ways. First, using the create-script you can create a code generation script which will become available to the application. Thecreate-script
command will create the script in the src/main/scripts
directory:+ src/main/scripts <-- additional scripts here + grails-app + controllers + services + etc.
create-command
command:$ grails create-command MyExampleCommand
grails-app/commands/PACKAGE_PATH/MyExampleCommand.groovy
that extends ApplicationCommand:import grails.dev.commands.*class MyExampleCommand implements ApplicationCommand { boolean handle(ExecutionContext ctx) { println "Hello World" return true } }
ApplicationCommand
has access to the GrailsApplication
instance and is subject to autowiring like any other Spring bean.For each ApplicationCommand
present Grails will create a shell command and a Gradle task to invoke the ApplicationCommand
. In the above example you can invoke the MyExampleCommand
class using either:$ grails my-example
$ gradle myExample
ApplicationCommand
instances is that the latter has full access to the Grails application state and hence can be used to perform tasks that interactive with the database, call into GORM etc.In Grails 2.x Gant scripts could be used to perform both these tasks, in Grails 3.x code generation and interacting with runtime application state has been cleanly separated.Adding a new grails-app artifact (Controller, Tag Library, Service, etc.)
A plugin can add new artifacts by creating the relevant file within thegrails-app
tree.+ grails-app + controllers <-- additional controllers here + services <-- additional services here + etc. <-- additional XXX here
Providing Views, Templates and View resolution
When a plugin provides a controller it may also provide default views to be rendered. This is an excellent way to modularize your application through plugins. Grails' view resolution mechanism will first look for the view in the application it is installed into and if that fails will attempt to look for the view within the plugin. This means that you can override views provided by a plugin by creating corresponding GSPs in the application'sgrails-app/views
directory.For example, consider a controller called BookController
that's provided by an 'amazon' plugin. If the action being executed is list
, Grails will first look for a view called grails-app/views/book/list.gsp
then if that fails it will look for the same view relative to the plugin.However if the view uses templates that are also provided by the plugin then the following syntax may be necessary:<g:render template="fooTemplate" plugin="amazon"/>
plugin
attribute, which contains the name of the plugin where the template resides. If this is not specified then Grails will look for the template relative to the application.Excluded Artefacts
By default Grails excludes the following files during the packaging process:grails-app/conf/logback.groovy
grails-app/conf/application.yml
(renamed toplugin.yml
)grails-app/conf/spring/resources.groovy
- Everything within
/src/test/**
- SCM management files within
**/.svn/**
and**/CVS/**
UrlMappings.groovy
file is excluded to avoid naming conflicts, however you are free to add a UrlMappings definition under a different name which will be included. For example a file called grails-app/controllers/BlogUrlMappings.groovy
is fine.The list of excludes is extensible with the pluginExcludes
property:// resources that are excluded from plugin packaging
def pluginExcludes = [
"grails-app/views/error.gsp"
]