(Quick Reference)

4 La línea de comando - Reference Documentation

Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith

Version: null

4 La línea de comando

Grails' command line system is built on Gant - a simple Groovy wrapper around Apache Ant.

However, Grails takes it further through the use of convention and the grails command. When you type:

El sistema de comandos de Grails está construido sobre Gant, un envoltorio simple de Apache Ant.

Sin embargo, Grails lleva un paso más alla el uso de la convención y del comando grails. Cuando introduces:

grails [command name]

Grails searches in the following directories for Gant scripts to execute:

Grails busca en los siguientes directorios scripts de Gant para ejecutar:

  • USER_HOME/.grails/scripts
  • PROJECT_HOME/scripts
  • PROJECT_HOME/plugins/*/scripts
  • GRAILS_HOME/scripts

Grails will also convert command names that are in lower case form such as run-app into camel case. So typing

Grails convertirá también los nombres de los comandos que están en minúsculas tales como run-app en "camel case", así que introducir:

grails run-app

Results in a search for the following files:

Produce una busqueda de los siguientes ficheros:

  • USER_HOME/.grails/scripts/RunApp.groovy
  • PROJECT_HOME/scripts/RunApp.groovy
  • PLUGINS_HOME/*/scripts/RunApp.groovy
  • GLOBAL_PLUGINS_HOME/*/scripts/RunApp.groovy
  • GRAILS_HOME/scripts/RunApp.groovy

If multiple matches are found Grails will give you a choice of which one to execute.

When Grails executes a Gant script, it invokes the "default" target defined in that script. If there is no default, Grails will quit with an error.

To get a list of all commands and some help about the available commands type:

Si coincide con varios Grails le dejará elegir cúal se ejecuta.

Cuando Grails ejecuta un script de Gant, invoca el target por defecto en es script. Si no hay target por defecto, Grails dejará de ejecutarse y dará un error.

grails help

which outputs usage instructions and the list of commands Grails is aware of:

devuelve como salida instrucciones de uso y una lista de los comandos de Grails:

Usage (optionals marked with *):
grails [environment]* [target] [arguments]*

Examples: grails dev run-app grails create-app books

Available Targets (type grails help 'target-name' for more info): grails bootstrap grails bug-report grails clean grails compile ...

Refer to the Command Line reference in the Quick Reference menu of the reference guide for more information about individual commands

Consulte la referencia de línea de comandos en el menú de referencia rápida de la guía de referencia para obtener más información sobre cada uno de los comandos.

It's often useful to provide custom arguments to the JVM when running Grails commands, in particular with run-app where you may for example want to set a higher maximum heap size. The Grails command will use any JVM options provided in the general JAVA_OPTS environment variable, but you can also specify a Grails-specific environment variable too:

A menudo es útil proporcionar argumentos a la JVM cuando se ejecutan comandos de Grails, en particular con run-app donde se puede, por ejemplo, establecer un tamaño máximo más alto al "heap". El comando Grails utilizará todas las opciones JVM proporcionadas en la variable de entorno JAVA_OPTS, pero también se puede especificar una variable de entorno específica de Grails también:

export GRAILS_OPTS="-Xmx1G -Xms256m -XX:MaxPermSize=256m"
grails run-app

non-interactive mode

When you run a script manually and it prompts you for information, you can answer the questions and continue running the script. But when you run a script as part of an automated process, for example a continuous integration build server, there's no way to "answer" the questions. So you can pass the --non-interactive switch to the script command to tell Grails to accept the default answer for any questions, for example whether to install a missing plugin.

For example:

Modo no interactivo

Cuando se ejecuta un script manualmente, y se solicita información, se puede responder a las preguntas y continuar la ejecución del script. Pero cuando se ejecuta un script como parte de un proceso automatizado, por ejemplo, un servidor de integración continua, no hay manera de responder a las preguntas. Por lo que puede pasar el parámetro --non-interactive al script para decirle a Grails que acepte la respuesta por defecto para cualquier pregunta, por ejemplo, si se instala un plugin que falta.

Por ejemplo:

grails war --non-interactive

4.1 Modo interactivo

Interactive mode is the a feature of the Grails command line which keeps the JVM running and allows for quicker execution of commands. To activate interactive mode type 'grails' at the command line and then use TAB completion to get a list of commands:

If you need to open a file whilst within interactive mode you can use the open command which will TAB complete file paths:

TAB completion also works for class names after the create-* commands:

If you need to run an external process whilst interactive mode is running you can do so by starting the command with a !:

El modo interactivo es una característica de la línea de comandos Grails que mantiene la JVM funcionando y permite ejecutar comandos más rápidamente. Para activar el modo interactivo escriba "grails" en la línea de comandos y después use el tabulador para obtener una lista de comandos:

Si necesita abrir un archivo cuando esté en modo interactivo se puede utilizar el comando open usando el tabulador para completar las rutas de archivos:

El tabulador también funciona para las clases después del comando create-* :

Si necesita ejecutar un proceso externo, cuando esté en el modo interactivo, puede hacerlo a partir del comando con un !

4.2 Crear Scripts de Gant

You can create your own Gant scripts by running the create-script command from the root of your project. For example the following command:

grails create-script compile-sources

Will create a script called scripts/CompileSources.groovy. A Gant script itself is similar to a regular Groovy script except that it supports the concept of "targets" and dependencies between them:

target(default:"The default target is the one that gets executed by Grails") {
    depends(clean, compile)
}

target(clean:"Clean out things") { ant.delete(dir:"output") }

target(compile:"Compile some sources") { ant.mkdir(dir:"mkdir") ant.javac(srcdir:"src/java", destdir:"output") }

Puede crear sus propios scripts de Gant mediante la ejecución del comando create-script en la raíz de su proyecto. Por ejemplo, el siguiente comando:

grails create-script compile-sources

creará un script llamado scripts/CompileSources.groovy. Un script de Gant es muy similar a un script normal de Groovy, excepto que soporta el concepto de "targets" y las dependencias entre ellos:

target(default:"The default target is the one that gets executed by Grails") {
    depends(clean, compile)
}

target(clean:"Clean out things") { ant.delete(dir:"output") }

target(compile:"Compile some sources") { ant.mkdir(dir:"mkdir") ant.javac(srcdir:"src/java", destdir:"output") }

As demonstrated in the script above, there is an implicit ant variable (an instance of groovy.util.AntBuilder) that allows access to the Apache Ant API.
In previous versions of Grails (1.0.3 and below), the variable was Ant, i.e. with a capital first letter.

You can also "depend" on other targets using the depends method demonstrated in the default target above.

Como se demuestra en la secuencia anterior, hay una variable implícita ant (una instancia de groovy.util.AntBuilder) que permite el acceso a la Apache Ant API.
En las versiones anteriores de Grails (1.0.3 y anteriores), la variable era Ant, es decir, con una letra mayúscula en primer lugar.

También puede "depender" de otros targets utilizando el método depends mostrado en el valor default del target anterior.

The default target

In the example above, we specified a target with the explicit name "default". This is one way of defining the default target for a script. An alternative approach is to use the setDefaultTarget() method:

El target predeterminado

En el ejemplo anterior, se especifica un target con el nombre explícito "default". Esta es una manera de definir el target predeterminado para un script. Un enfoque alternativo es el uso del método setDefaultTarget():

target("clean-compile": "Performs a clean compilation on the app source") {
    depends(clean, compile)
}

target(clean:"Clean out things") { ant.delete(dir:"output") }

target(compile:"Compile some sources") { ant.mkdir(dir:"mkdir") ant.javac(srcdir:"src/java", destdir:"output") }

setDefaultTarget("clean-compile")

This lets you call the default target directly from other scripts if you wish. Also, although we have put the call to setDefaultTarget() at the end of the script in this example, it can go anywhere as long as it comes after the target it refers to ("clean-compile" in this case).

Which approach is better? To be honest, you can use whichever you prefer - there don't seem to be any major advantages in either case. One thing we would say is that if you want to allow other scripts to call your "default" target, you should move it into a shared script that doesn't have a default target at all. We'll talk some more about this in the next section.

Esto permite llamar al target predeterminado directamente desde otros scripts si así lo desea. Además, aunque hemos puesto la llamada a setDefaultTarget() al final de la secuencia de comandos en este ejemplo, puede ir en cualquier lugar, siempre y cuando esté después del objetivo que se refiere ("clean-compile" en este caso).

¿Qué enfoque es mejor? En realidad puede utilizar lo que prefiera, no parece haber ninguna ventaja importante en cualquier caso. Una cosa que diría es que si desea permitir que otros scripts llamen a su target por defecto, debe moverse en un script compartido que no tiene un target predeterminado. Hablaremos un poco más sobre esto en la siguiente sección.

4.3 Reusar scripts de Grails

Grails ships with a lot of command line functionality out of the box that you may find useful in your own scripts (See the command line reference in the reference guide for info on all the commands). Of particular use are the compile, package and bootstrap scripts.

The bootstrap script for example lets you bootstrap a Spring ApplicationContext instance to get access to the data source and so on (the integration tests use this):

Grails tiene un montón de funcionalidades de serie mediante la línea de comandos que pueden resultar útiles en sus propios scripts (consulte la referencia de la línea de comandos en la Guía de referencia para la información sobre todos los comandos). Particularmente útiles son los scripts compile, package y bootstrap.

El script bootstrap por ejemplo le permite iniciar una instancia del Contexto de aplicación de Spring para obtener acceso al origen de datos y así sucesivamente (las pruebas de integración utilizan esto):

includeTargets << grailsScript("_GrailsBootstrap")

target ('default': "Database stuff") { depends(configureProxy, packageApp, classpath, loadApp, configureApp)

Connection c try { c = appCtx.getBean('dataSource').getConnection() // do something with connection } finally { c?.close() } }

Pulling in targets from other scripts

Gant lets you pull in all targets (except "default") from another Gant script. You can then depend upon or invoke those targets as if they had been defined in the current script. The mechanism for doing this is the includeTargets property. Simply "append" a file or class to it using the left-shift operator:

includeTargets << new File("/path/to/my/script.groovy")
includeTargets << gant.tools.Ivy
Don't worry too much about the syntax using a class, it's quite specialised. If you're interested, look into the Gant documentation.

Usando targets de otros scripts

Gant permite usar todos los targets (excepto el "default") de otro script de Gant. Luego puede depender de o invocar esos targets como si se hubieran definido en el propio script. El mecanismo para hacerlo es el de la propiedad includeTargets. Simplemente anexe un fichero o una clase a él utilizando el operador de desplazamiento a la izquierda:

includeTargets << File("/path/to/my/script.groovy") nueva
includeTargets << gant.tools.Ivy
No se preocupe demasiado acerca de la sintaxis usada para una clase, es bastante especial. Si le interesa, busque en la documentación de Gant.

Core Grails targets

As you saw in the example at the beginning of this section, you use neither the File- nor the class-based syntax for includeTargets when including core Grails targets. Instead, you should use the special grailsScript() method that is provided by the Grails command launcher (note that this is not available in normal Gant scripts, just Grails ones).

The syntax for the grailsScript() method is pretty straightforward: simply pass it the name of the Grails script to include, without any path information. Here is a list of Grails scripts that you could reuse:

Principales targets de Grails

Como se ha visto en el ejemplo al principio de esta sección, no se utiliza el fichero ni la sintaxis de clases para includeTargets cuando se incluyen targets principales de Grails. En su lugar, debe utilizar el método especial grailsScript() proporcionado por el lanzdor del comando Grails (tenga en cuenta que esto no está disponible en scripts de Gant normales, sólo en los de Grails).

La sintaxis del método grailsScript() es bastante sencilla: simplemente pas el nombre del script de Grails que se debe incluir, sin ninguna información de ruta de acceso. Aquí hay una lista de los scripts de Grails que podría volver a utilizar:

ScriptDescription
_GrailsSettingsYou really should include this! Fortunately, it is included automatically by all other Grails scripts except _GrailsProxy, so you usually don't have to include it explicitly.
_GrailsEventsInclude this to fire events. Adds an event(String eventName, List args) method. Again, included by almost all other Grails scripts.
_GrailsClasspathConfigures compilation, test, and runtime classpaths. If you want to use or play with them, include this script. Again, included by almost all other Grails scripts.
_GrailsProxyIf you don't have direct access to the internet and use a proxy, include this script to configure access through your proxy.
_GrailsArgParsingProvides a parseArguments target that does what it says on the tin: parses the arguments provided by the user when they run your script. Adds them to the argsMap property.
_GrailsTestContains all the shared test code. Useful if you want to add any extra tests.
_GrailsRunProvides all you need to run the application in the configured servlet container, either normally (runApp/runAppHttps) or from a WAR file (runWar/runWarHttps).

There are many more scripts provided by Grails, so it is worth digging into the scripts themselves to find out what kind of targets are available. Anything that starts with an "_" is designed for reuse.

Script architecture

ScriptDescripción
_GrailsSettings¡Realmente debería usar esto! Afortunadamente, se usa automáticamente por todos los scripts de Grails excepto _GrailsProxy, por lo que normalmente no tiene que usarlo explícitamente.
_GrailsEventsUse esto para desencadenar eventos. Agrega un método event(String eventName, List args). Una vez más, usada por casi todos los otros scripts de Grails.
_GrailsClasspathConfigura el classpath de la compilación, pruebas y tiempo de ejecución. Si desea usarlos o jugar con ellos, use este script. Una vez más, usado por casi todos los otros scripts de Grails.
_GrailsProxySi no tiene acceso directo a internet y utilizar a un proxy, use esta secuencia de comandos para configurar el acceso a través de proxy.
_GrailsArgParsingProporciona un target parseArguments que analiza los argumentos proporcionados por el usuario cuando ejecuta el script. Agrega a la propiedad argsMap.
_GrailsTestContiene todo el código compartido de prueba. Es útil si desea agregar cualquier prueba adicional.
_GrailsRunOfrece todo que lo necesario para ejecutar la aplicación en el contenedor de servlet configurado, ya sea normalmente (runApp/runAppHttps) o desde un fichero WAR (runWar/runWarHttps).

Hay muchos scripts más proporcionados por Grails, por lo que es merece la pena bucear en los scripts mismos para averiguar qué tipo de objetivos están disponibles. Cualquier cosa que comienza con un "_" está diseñado para su reutilización.

Arquitectura un script

You maybe wondering what those underscores are doing in the names of the Grails scripts. That is Grails' way of determining that a script is internal , or in other words that it has not corresponding "command". So you can't run "grails _grails-settings" for example. That is also why they don't have a default target.

Internal scripts are all about code sharing and reuse. In fact, we recommend you take a similar approach in your own scripts: put all your targets into an internal script that can be easily shared, and provide simple command scripts that parse any command line arguments and delegate to the targets in the internal script. For example if you have a script that runs some functional tests, you can split it like this:

Tal vez está pensando en lo que están haciendo esos caracteres de subrayado en los nombres de los scripts de Grails. Es la forma de Grails de determinar que una secuencia de comandos es interna , o en otras palabras que tiene "comando" correspondiente. Por lo que no se puede ejecutar "grails _grails-settings" por ejemplo. También es por esto qué no tienen un target predeterminado.

Los scripts internos son todo para compartir código y reutilizarlo. De hecho, se recomienda adoptar un enfoque similar en sus propios scripts: poner todos sus targets en un script interno que puede ser fácilmente compartido y proporcionar script simples que analizen cualquier argumentos y deleguen en los targets de los scripts internos. Por ejemplo si tiene una secuencia de comandos que ejecuta algunas pruebas funcionales, se puede dividir así:

./scripts/FunctionalTests.groovy:

includeTargets << new File("${basedir}/scripts/_FunctionalTests.groovy")

target(default: "Runs the functional tests for this project.") { depends(runFunctionalTests) }

./scripts/_FunctionalTests.groovy:

includeTargets << grailsScript("_GrailsTest")

target(runFunctionalTests: "Run functional tests.") { depends(...) … }

Here are a few general guidelines on writing scripts:
  • Split scripts into a "command" script and an internal one.
  • Put the bulk of the implementation in the internal script.
  • Put argument parsing into the "command" script.
  • To pass arguments to a target, create some script variables and initialise them before calling the target.
  • Avoid name clashes by using closures assigned to script variables instead of targets. You can then pass arguments direct to the closures.

Aquí hay unas directrices generales sobre cómo escribir scripts:

  • Dividir los scripts un script de "comando" y uno interno.
  • Poner la mayor parte de la implementación en la secuencia de comandos interno.
  • Poner el análisis de los parámetros en el script de "comando".
  • Para pasar argumentos a un target, crear algunas variables de script e inicializarlas antes de llamar al target.
  • Evitar colisiones de nombres utilizando closures asignadas a las variables del script en lugar de targets. Así puede pasar argumentos directamente a las closures.

4.4 Interceptando Eventos

Grails provides the ability to hook into scripting events. These are events triggered during execution of Grails target and plugin scripts.

The mechanism is deliberately simple and loosely specified. The list of possible events is not fixed in any way, so it is possible to hook into events triggered by plugin scripts, for which there is no equivalent event in the core target scripts.

Defining event handlers

Event handlers are defined in scripts called _Events.groovy. Grails searches for these scripts in the following locations:

  • USER_HOME/.grails/scripts - user-specific event handlers
  • PROJECT_HOME/scripts - applicaton-specific event handlers
  • PLUGINS_HOME/*/scripts - plugin-specific event handlers
  • GLOBAL_PLUGINS_HOME/*/scripts - event handlers provided by global plugins

Grails proporciona la capacidad de interceptar eventos de scripts. Estos eventos son activados durante la ejecución de scripts de Grails y plugins.

El mecanismo es deliberadamente simple y vagamente especificado. La lista de posibles eventos no es fija en modo alguno, por lo que es posible enlazar eventos activados por los scripts de plugin, para los que no hay evento equivalente en los scripts del núcleo.

Definición de manejadores de eventos

Los controladores de eventos se definen en un scripts llamado _Events.groovy. Grails busca estos scripts en las siguientes ubicaciones:

  • USER_HOME/.grails/scripts - manejadores de eventos específicos del usuario.
  • PROJECT_HOME/scripts - manejadores de eventos específicos de la aplicación.
  • PLUGINS_HOME / * / scripts - manejadores de eventos específicos de plugin.
  • GLOBAL_PLUGINS_HOME / * / scripts - manejadores de eventos proporcionados por plugins globales.

Whenever an event is fired, all the registered handlers for that event are executed. Note that the registration of handlers is performed automatically by Grails, so you just need to declare them in the relevant _Events.groovy file.

Event handlers are blocks defined in _Events.groovy, with a name beginning with "event". The following example can be put in your /scripts directory to demonstrate the feature:

eventCreatedArtefact = { type, name ->
   println "Created $type $name"
}

eventStatusUpdate = { msg -> println msg }

eventStatusFinal = { msg -> println msg }

Cuando se desencadena un evento, se ejecutan todos los manejadores registrados para ese evento. Tenga en cuenta que el registro de controladores se realiza automáticamente por Grails, por lo que sólo es necesario declararlos en el archivo _Events.groovy pertinente.

Los manejadores de eventos son bloques definidos en _Events.groovy, con un nombre que empieza con "event". En el ejemplo siguiente se puede colocar en el directorio/scripts para demostrar esta característica:

eventCreatedArtefact = { type, name ->
   println "Created $type $name"
}

eventStatusUpdate = { msg -> println msg }

eventStatusFinal = { msg -> println msg }

You can see here the three handlers eventCreatedArtefact, eventStatusUpdate, eventStatusFinal. Grails provides some standard events, which are documented in the command line reference guide. For example the compile command fires the following events:

  • CompileStart - Called when compilation starts, passing the kind of compile - source or tests
  • CompileEnd - Called when compilation is finished, passing the kind of compile - source or tests

Triggering events

To trigger an event simply include the Init.groovy script and call the event() closure:

Aquí puede ver tres controladores eventCreatedArtefact, eventStatusUpdate, eventStatusFinal. Grails proporciona algunos eventos estándar, que se describen en la Guía de referencia de línea de comandos. Por ejemplo, el comando compile dispara los siguientes eventos:

  • CompileStart - llamado cuando se inicia la compilación, pasando el tipo de compilación - código fuente o pruebas
  • CompileEnd - llamada una vez finalizada la compilación, pasando el tipo de compilación - código fuente o pruebas

Activación de eventos

Para desencadenar un evento simplemente debe incluir la secuencia de comandos Init.groovy y llamar a la closure event():

includeTargets << grailsScript("_GrailsEvents")

event("StatusFinal", ["Super duper plugin action complete!"])

Common Events

Below is a table of some of the common events that can be leveraged:

includeTargets << grailsScript("_GrailsEvents")

event("StatusFinal", ["Super duper plugin action complete!"])

Eventos habituales

A continuación es una tabla de algunos de los eventos habituales que se pueden utilizar:

EventParametersDescription
StatusUpdatemessagePassed a string indicating current script status/progress
StatusErrormessagePassed a string indicating an error message from the current script
StatusFinalmessagePassed a string indicating the final script status message, i.e. when completing a target, even if the target does not exit the scripting environment
CreatedArtefactartefactType,artefactNameCalled when a create-xxxx script has completed and created an artefact
CreatedFilefileNameCalled whenever a project source filed is created, not including files constantly managed by Grails
ExitingreturnCodeCalled when the scripting environment is about to exit cleanly
PluginInstalledpluginNameCalled after a plugin has been installed
CompileStartkindCalled when compilation starts, passing the kind of compile - source or tests
CompileEndkindCalled when compilation is finished, passing the kind of compile - source or tests
DocStartkindCalled when documentation generation is about to start - javadoc or groovydoc
DocEndkindCalled when documentation generation has ended - javadoc or groovydoc
SetClasspathrootLoaderCalled during classpath initialization so plugins can augment the classpath with rootLoader.addURL(...). Note that this augments the classpath after event scripts are loaded so you cannot use this to load a class that your event script needs to import, although you can do this if you load the class by name.
PackagingEndnoneCalled at the end of packaging (which is called prior to the Tomcat server being started and after web.xml is generated)

EventoParámetrosDescripción
StatusUpdatemensajePasa una cadena que indica el Estado y progreso de script actual.
StatusErrormensajePasa una cadena que indica un mensaje de error en el script actual.
StatusFinalmensajePasa una cadena que indica el mensaje de estado final del script, es decir, al completar un target, incluso no cierra el entorno de script.
CreatedArtefactartefactType, artefactNameSe llama cuando un script create-xxxx ha terminado y ha creado un artefacto
CreatedFilenombre de archivoLlamada siempre que se crea un fichero en el proyecto, sin incluir los archivos administrado por Grails.
ExitingreturnCodeSe llama cuando el entorno de script está a punto de cerrarse.
PluginInstalledNombre de PluginSe llama después de que se ha instalado un plugin.
CompileStarttipoSe llama cuando comienza la compilación, pasando el tipo de compilación - código fuente o pruebas
CompileEndtipoSe llama cuando finaliza la compilación, pasando el tipo de compilación - código fuente o pruebas
DocStarttipoSe llama cuando la generación de documentación está a punto de empezar - javadoc o groovydoc
DocEndtipoSe llama cuando se ha finalizado la generación de documentación - javadoc o groovydoc
SetClasspathrootLoaderLlamado durante la inicialización del classpath para que los plugins pueda insertar entradas en el classpath con rootLoader.addURL(...). Dese cuenta de que esto inserta nuevas rutas después de que los scripts se cargen por lo que no se puede utilizar esto para cargar una clase su script de eventos necesita, aunque se puede hacer esto si carga la clase por su nombre.
PackagingEndningunoLlamado al final del empaquetamiento (que se llama antes de arrancar el servidor Tomcat y después de generar el web.xml)

4.5 Personalizar la construcción

Grails is most definitely an opinionated framework and it prefers convention to configuration, but this doesn't mean you can't configure it. In this section, we look at how you can influence and modify the standard Grails build.

The defaults

The core of the Grails build configuration is the grails.util.BuildSettings class, which contains quite a bit of useful information. It controls where classes are compiled to, what dependencies the application has, and other such settings.

Here is a selection of the configuration options and their default values:

PropertyConfig optionDefault value
grailsWorkDirgrails.work.dir$USER_HOME/.grails/<grailsVersion>
projectWorkDirgrails.project.work.dir<grailsWorkDir>/projects/<baseDirName>
classesDirgrails.project.class.dir<projectWorkDir>/classes
testClassesDirgrails.project.test.class.dir<projectWorkDir>/test-classes
testReportsDirgrails.project.test.reports.dir<projectWorkDir>/test/reports
resourcesDirgrails.project.resource.dir<projectWorkDir>/resources
projectPluginsDirgrails.project.plugins.dir<projectWorkDir>/plugins
globalPluginsDirgrails.global.plugins.dir<grailsWorkDir>/global-plugins
verboseCompilegrails.project.compile.verbosefalse

Grails es definitivamente un framework opinionado y prefiere la convención sobre la configuración, pero esto no significa que no se pueda configurar. En esta sección, veremos cómo puede influir y modificar el la construcción estándar de Grails.

Los valores predeterminados

El núcleo de la configuración de la construcción de Grails es la clase grails.util.BuildSettings, que contiene bastante información útil. Controla donde se guardan las clases se compiladas, que dependencias tiene la aplicación, y otros ajustes como estos.

He aquí una selección de las opciones de configuración y sus valores predeterminados:

PropiedadOpción de configuraciónValor por defecto
grailsWorkDirgrails.work.dir$USER_HOME/.grails/<grailsVersion>
projectWorkDirgrails.project.work.dir<grailsWorkDir>/projects/<baseDirName>
classesDirgrails.project.class.dir<projectWorkDir>/classes
testClassesDirgrails.project.test.class.dir<projectWorkDir>/test-classes
testReportsDirgrails.project.test.reports.dir<projectWorkDir>/test/reports
resourcesDirgrails.project.resource.dir<projectWorkDir>/resources
projectPluginsDirgrails.project.plugins.dir<projectWorkDir>/plugins
globalPluginsDirgrails.global.plugins.dir<grailsWorkDir>/global-plugins
verboseCompilegrails.project.compile.verbosefalse

The BuildSettings class has some other properties too, but they should be treated as read-only:

PropertyDescription
baseDirThe location of the project.
userHomeThe user's home directory.
grailsHomeThe location of the Grails installation in use (may be null).
grailsVersionThe version of Grails being used by the project.
grailsEnvThe current Grails environment.
compileDependenciesA list of compile-time project dependencies as File instances.
testDependenciesA list of test-time project dependencies as File instances.
runtimeDependenciesA list of runtime-time project dependencies as File instances.

La clase BuildSettings también tiene algunas otras propiedades, pero deben ser tratados como de sólo lectura:

PropiedadDescripción
baseDirLa ubicación del proyecto.
userHomeDirectorio principal del usuario.
grailsHomeLa ubicación de la instalación de Grails en uso (puede ser null).
grailsVersionLa versión de Grails utilizada por el proyecto.
grailsEnvEl entorno actual de Grails.
compileDependenciesUna lista de dependencias del proyecto en tiempo de compilación como instancias de File.
testDependenciesUna lista de dependencias del proyecto en tiempo de pruebas como instancias de File.
runtimeDependenciesUna lista de dependencias del proyecto en tiempo de ejecución como instancias de File.

Of course, these properties aren't much good if you can't get hold of them. Fortunately that's easy to do: an instance of BuildSettings is available to your scripts as the grailsSettings script variable. You can also access it from your code by using the grails.util.BuildSettingsHolder class, but this isn't recommended.

Overriding the defaults

All of the properties in the first table can be overridden by a system property or a configuration option - simply use the "config option" name. For example, to change the project working directory, you could either run this command:

grails -Dgrails.project.work.dir=work compile

Por supuesto, estas propiedades no sirven para nada si no se puede conseguir accceso a ellas. Afortunadamente eso es fácil de hacer: una instancia de BuildSettings está disponible para tus scripts como la variable grailsSettings. También se puede acceder desde el código mediante el uso de la clase grails.util.BuildSettingsHolder, pero esto no es recomendable.

Sobreescribiendo los valores predeterminados

Todas las propiedades de la primera tabla se pueden sobreescribir por una propiedad del sistema o una opción de configuración, simplemente usar el nombre de "opción de configuración". Por ejemplo, para cambiar el directorio de trabajo del proyecto, podría ejecutar este comando:

grails -Dgrails.project.work.dir=work compile

or add this option to your grails-app/conf/BuildConfig.groovy file:

grails.project.work.dir = "work"
Note that the default values take account of the property values they depend on, so setting the project working directory like this would also relocate the compiled classes, test classes, resources, and plugins.

What happens if you use both a system property and a configuration option? Then the system property wins because it takes precedence over the BuildConfig.groovy file, which in turn takes precedence over the default values.

The BuildConfig.groovy file is a sibling of grails-app/conf/Config.groovy - the former contains options that only affect the build, whereas the latter contains those that affect the application at runtime. It's not limited to the options in the first table either: you will find build configuration options dotted around the documentation, such as ones for specifying the port that the embedded servlet container runs on or for determining what files get packaged in the WAR file.

o añadir esta opción al archivo grails-app/conf/BuildConfig.groovy:

grails.project.work.dir = "work"
Tenga en cuenta que los valores predeterminados influyen también en las propiedades de las que dependen, así que establecer el directorio de trabajo del proyecto también modifica la ubicación de las clases compiladas, las clasese de prueba, recursos y plugins.

¿Qué ocurre si se utilizan una propiedad del sistema y una opción de configuración? En ese caso, la propiedad del sistema gana porque prevalece sobre el archivo BuildConfig.groovy, que a su vez tiene prioridad sobre los valores predeterminados.

El archivo BuildConfig.groovy es un hermano de grails-app/conf/Config.groovy: la primera contiene opciones que sólo afectan a la construcción, mientras que el segundo contiene opciones que afectan a la aplicación en tiempo de ejecución. No se limita sólo a las opciones de la primera tabla: encontrará las opciones de configuración de generación en esta documentación, como las necesarias para especificar el puerto que se ejecuta el contenedor de servlet embebido o para determinar qué archivos se empaquetan en el archivo WAR.

Available build settings

NameDescription
grails.server.port.httpPort to run the embedded servlet container on ("run-app" and "run-war"). Integer.
grails.server.port.httpsPort to run the embedded servlet container on for HTTPS ("run-app --https" and "run-war --https"). Integer.
grails.config.base.webXmlPath to a custom web.xml file to use for the application (alternative to using the web.xml template).
grails.compiler.dependenciesLegacy approach to adding extra dependencies to the compiler classpath. Set it to a closure containing "fileset()" entries. These entries will be processed by an AntBuilder so the syntax is the Groovy form of the corresponding XML elements in an Ant build file, e.g. fileset(dir: "$basedir/lib", include: "**/*.class).
grails.testing.patternsA list of Ant path patterns that let you control which files are included in the tests. The patterns should not include the test case suffix, which is set by the next property.
grails.testing.nameSuffixBy default, tests are assumed to have a suffix of "Tests". You can change it to anything you like but setting this option. For example, another common suffix is "Test".
grails.project.war.fileA string containing the file path of the generated WAR file, along with its full name (include extension). For example, "target/my-app.war".
grails.war.dependenciesA closure containing "fileset()" entries that allows you complete control over what goes in the WAR's "WEB-INF/lib" directory.
grails.war.copyToWebAppA closure containing "fileset()" entries that allows you complete control over what goes in the root of the WAR. It overrides the default behaviour of including everything under "web-app".
grails.war.resourcesA closure that takes the location of the staging directory as its first argument. You can use any Ant tasks to do anything you like. It is typically used to remove files from the staging directory before that directory is jar'd up into a WAR.
grails.project.web.xmlThe location to generate Grails' web.xml to

Configuración de construcción disponible

NombreDescripción
grails.Server.Port.httpPuerto para ejecutar el contenedor de servlet embebido ("run-app" y "run-war"). Entero.
grails.Server.Port.httpsPuerto para ejecutar el contenedor de servlet embebido bajo HTTPS ("run-app --https" y "run war --https"). Entero.
grails.config.base.webXmlRuta del archivo web.xml personalizada para utilizar para la aplicación (alternativa al uso de la plantilla de web.xml).
grails.compiler.dependenciesEnfoque heredado para agregar dependencias adicionales a los classpath del compilador. Establézcalo en una closure que contenga las entradas "fileset()". Estas entradas serán procesadas por un AntBuilder por lo que la sintaxis es la forma Groovy de los correspondientes elementos XML en un fichero de construcción Ant, por ejemplo, fileset(dir: "$basedir/lib", include: "**/*.class).
grails.testing.PatternsUna lista de patrones de rutas Ant que le permiten controlar qué archivos se incluyen en las pruebas. Los patrones no deben incluir el sufijo de caso de prueba, se establece mediante la propiedad siguiente.
grails.testing.nameSuffixPor defecto, las pruebas se supone que tienen un sufijo de "Tests". Puede cambiarlo a cualquier cosa que le guste asignando esta opción. Por ejemplo, otro sufijo común es "Test".
grails.project.war.FileUna cadena que contiene la ruta del archivo WAR generado, junto con su nombre completo (incluye extensión). Por ejemplo, "target/my-app.war".
grails.war.dependenciesUna closure que contiene las entradas "fileset()" que permite un control total sobre lo que pasa en el directorio de "WEB-INF/lib" del WAR.
grails.war.copyToWebAppUna closure que contiene las entradas "fileset()" que permite un control total sobre lo que pasa en la raíz del WAR. Reemplaza el comportamiento predeterminado de incluir todo bajo "web-app".
grails.war.resourcesUna closure que toma la ubicación del directorio provisional (staging) como primer argumento. Puede utilizar cualquier tarea de Ant para hacer cualquier cosa que le guste. Normalmente se utiliza para eliminar archivos del directorio provisional antes de ese directorio jar se incluya en un WAR.
grails.project.web.xMLLa ubicación en la que se generará el fichero web.xml.

4.6 Ant y Maven

If all the other projects in your team or company are built using a standard build tool such as Ant or Maven, you become the black sheep of the family when you use the Grails command line to build your application. Fortunately, you can easily integrate the Grails build system into the main build tools in use today (well, the ones in use in Java projects at least).

Si todos los proyectos en su equipo o empresa se construyen utilizando una herramienta de construcción como Ant o Maven, se convierte en la oveja negra de la familia cuando utiliza la línea de comandos de Grails para construir su aplicación. Afortunadamente, puede integrar fácilmente el sistema de construcción de Grails en las principales herramientas de construcción en uso hoy en día (bueno, las que están en uso en proyectos de Java por lo menos).

Ant Integration

When you create a Grails application with the create-app command, Grails doesn't automatically create an Ant build.xml file but you can generate one with the integrate-with command:

Integración con Ant

Cuando se crea una aplicación Grails con la create-app, Grails no crea automáticamente un archivo Ant build.xml pero puede generar una con el comando integrate-with:


grails integrate-with --ant

This creates a build.xml file containing the following targets:

  • clean - Cleans the Grails application
  • compile - Compiles your application's source code
  • test - Runs the unit tests
  • run - Equivalent to "grails run-app"
  • war - Creates a WAR file
  • deploy - Empty by default, but can be used to implement automatic deployment

Each of these can be run by Ant, for example:

ant war

Esto crea un archivo build.xml que contiene los siguientes targets:

  • clean - Limpia la aplicación Grails
  • compile - Compila el código fuente de su aplicación
  • test - Ejecuta las pruebas unitarias
  • run - Equivalente a "ejecutar grails-app"
  • war - Crea un archivo WAR
  • deploy - Vacio por defecto, pero puede ser usado para implementar el despliegue automático

Cada uno de ellos se puede ejecutar con Ant, por ejemplo:

ant war

The build file is configured to use Apache Ivy for dependency management, which means that it will automatically download all the requisite Grails JAR files and other dependencies on demand. You don't even have to install Grails locally to use it! That makes it particularly useful for continuous integration systems such as CruiseControl or Jenkins.

It uses the Grails Ant task to hook into the existing Grails build system. The task lets you run any Grails script that's available, not just the ones used by the generated build file. To use the task, you must first declare it:

<taskdef name="grailsTask"
         classname="grails.ant.GrailsTask"
         classpathref="grails.classpath"/>

El fichero de construcción está configurado para utilizar Apache Ivy para la gestión de la dependencias, lo que significa que se descargará automáticamente todos los archivos JAR necesarios y otras dependencias bajo demanda. ¡Ni siquiera tiene que instalar Grails localmente para usarlo! Esto lo hace especialmente útil para los sistemas de integración continua, tales como CruiseControl o Jenkins.

Use la tarea Ant de Grails para enlazar con el actual sistema de construcción de Grails. La tarea le permite ejecutar cualquier script Grails que esté disponible, no sólo los utilizados por el fichero de construcción generado. Para utilizar la tarea, primero se debe declarar:

<taskdef name="grailsTask"
         classname="grails.ant.GrailsTask"
         classpathref="grails.classpath"/>

This raises the question: what should be in "grails.classpath"? The task itself is in the "grails-bootstrap" JAR artifact, so that needs to be on the classpath at least. You should also include the "groovy-all" JAR. With the task defined, you just need to use it! The following table shows you what attributes are available:
AttributeDescriptionRequired
homeThe location of the Grails installation directory to use for the build.Yes, unless classpath is specified.
classpathrefClasspath to load Grails from. Must include the "grails-bootstrap" artifact and should include "grails-scripts".Yes, unless home is set or you use a classpath element.
scriptThe name of the Grails script to run, e.g. "TestApp".Yes.
argsThe arguments to pass to the script, e.g. "-unit -xml".No. Defaults to "".
environmentThe Grails environment to run the script in.No. Defaults to the script default.
includeRuntimeClasspathAdvanced setting: adds the application's runtime classpath to the build classpath if true.No. Defaults to true.

Esto plantea la pregunta: ¿qué debe estar en "grails.classpath"? La tarea en sí misma está en el artefacto JAR "grails-bootstrap", por lo que tiene que estar en el classpath por lo menos. También debe incluir el "groovy-all" JAR. Con la tarea definida, ¡sólo tiene que usarla! La siguiente tabla muestra los atributos que están disponibles:

AtributoDescripciónRequerido
homeLa ubicación del directorio de instalación de Grails que se utilizará para la construcción.Sí, a menos que se especifique un classpath.
classpathrefClasspath para la carga de Grails. Debe incluir el artefacto "grails-bootstrap" y debe incluir "grails-scripts".Sí, a menos que home se establezca o se utilice un elemento classpath.
scriptEl nombre del script Grails para ejecutar, por ejemplo, "TestApp".Sí.
argsLos argumentos que se pasan al script, por ejemplo, "-unit -xml".No, por defecto "".
environmentEl entorno de Grails para ejecutar el script inNo, por defecto los valores del script.
includeRuntimeClasspathConfiguración avanzada: añade el classpath de la aplicación al classpath de la construcción si es verdadero.No, por defecto true.

The task also supports the following nested elements, all of which are standard Ant path structures:
  • classpath - The build classpath (used to load Gant and the Grails scripts).
  • compileClasspath - Classpath used to compile the application's classes.
  • runtimeClasspath - Classpath used to run the application and package the WAR. Typically includes everything in @compileClasspath.
  • testClasspath - Classpath used to compile and run the tests. Typically includes everything in runtimeClasspath.

How you populate these paths is up to you. If you use the home attribute and put your own dependencies in the lib directory, then you don't even need to use any of them. For an example of their use, take a look at the generated Ant build file for new apps.

La tarea también es compatible con los siguientes elementos anidados, todos los cuales son estructuras estándar de Ant:

  • classpath - El classpath de construcción (se utiliza para cargar los scripts de Gant y Grails).
  • compileClasspath - Classpath utilizados para compilar las clases de la aplicación.
  • runtimeClasspath - Classpath que se utiliza para ejecutar la aplicación y empaquetar el WAR. Por lo general incluye todo lo de @compileClasspath .
  • testClasspath - Classpath utilizado para compilar y ejecutar las pruebas. Por lo general incluye todo lo de @runtimeClasspath.

Como crear esas rutas depende de usted. Si utiliza el atributo home y coloca su propias dependencias en el directorio lib, entonces ni siquiera tiene necesidad de utilizar ninguna de ellas. Para un ejemplo de su uso, eche un vistazo al fichero de construcción generado por Ant para nuevas aplicaciones.

Maven Integration

Grails provides integration with Maven 2 with a Maven plugin. The current Maven plugin is based on but supersedes the version created by Octo, who did a great job with the original.

Preparation

In order to use the new plugin, all you need is Maven 2 installed and set up. This is because you no longer need to install Grails separately to use it with Maven!

The Maven 2 integration for Grails has been designed and tested for Maven 2.0.9 and above. It will not work with earlier versions.

The default mvn setup DOES NOT supply sufficient memory to run the Grails environment. We recommend that you add the following environment variable setting to prevent poor performance:

export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=256"

Integración con Maven

Grails ofrece una integración con Maven 2 con un plugin de Maven. El actual plugin de Maven reemplaza y se basa en la versión creada por Octo, que hizo un gran trabajo con el original.

Preparación

Para utilizar el nuevo plugin, todo lo que necesita es Maven 2 instalado y configurado. Esto se debe a que ¡ya no es necesario instalar Grails por separado para su uso con Maven!

La integración de Maven 2 con Grails ha sido diseñado y probado para Maven 2.0.9 y superiores. No funcionará con versiones anteriores.

La configuración por defecto de Maven no proporciona suficiente memoria para ejecutar el entorno de Grails. Le recomendamos agregar la siguiente variable de entorno a su configuración para evitar que los malos rendimientos:

export MAVEN_OPTS="-Xmx512m-XX: MaxPermSize = 256"

Creating a Grails Maven Project

To create a Mavenized Grails project simply run the following command:

mvn archetype:generate -DarchetypeGroupId=org.grails \
    -DarchetypeArtifactId=grails-maven-archetype \
    -DarchetypeVersion=1.3.2 \
    -DgroupId=example -DartifactId=my-app

Choose whichever grails version, group ID and artifact ID you want for your application, but everything else must be as written. This will create a new Maven project with a POM and a couple of other files. What you won't see is anything that looks like a Grails application. So, the next step is to create the project structure that you're used to. But first, to set target JDK to Java 6, do that now. Open my-app/pom.xml and change

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.5</source>
    <target>1.5</target>
  </configuration>
</plugin>
to
<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

Creación de un proyecto Grails con Maven

Para crear un proyecto Grails "mavenizado" sólo tiene que ejecutar el siguiente comando:

mvn archetype: generate-DarchetypeGroupId org.grails =   
     -DarchetypeArtifactId = grails-maven-arquetipo   
     -DarchetypeVersion = 1.3.2   
     -DgroupId = ejemplo-DartifactId = my-app

Elija la versión de Grails que desee, el identificador de grupo y la identificación de artefactos que desee para su aplicación, pero todo lo demás debe ser escrito como está. Esto creará un nuevo proyecto de Maven con un POM y un otro par de ficheros. Lo que no verá es nada que se parezca a una aplicación Grails. Por lo tanto, el siguiente paso es crear la estructura del proyecto que estamos acostumbrados. Pero primero, para establecer objetivos JDK de Java 6, hagalo ahora. Abra el fichero my-app/pom.xml y modifiquelo:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.5</source>
    <target>1.5</target>
  </configuration>
</plugin>
to
<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.6</source>
    <target>1.6</target>
  </configuration>
</plugin>

Then you're ready to create the project structure:

cd my-app
mvn initialize

if you see a message similar to this:

Resolving plugin JAR dependencies …
:: problems summary ::
:::: WARNINGS
        module not found: org.hibernate#hibernate-core;3.3.1.GA

you need to add the plugins manually to application.properties:

plugins.hibernate=2.0.0
plugins.tomcat=2.0.0

then run

mvn compile

and the hibernate and tomcat plugins will be installed.

Entonces estás listo para crear la estructura del proyecto:

cd mi-app
mvn initialize

null
si usted ve un mensaje similar a este:

Resolving plugin JAR dependencies …
:: problems summary ::
:::: WARNINGS
        module not found: org.hibernate#hibernate-core;3.3.1.GA

es necesario agregar manualmente los plugins al application.properties:

plugins.hibernate = 2.0.0
plugins.tomcat = 2.0.0

a continuación, ejecute

mvn compile

y el plugin de hibernate y de tomcat se instalarán. {nota}

Now you have a Grails application all ready to go. The plugin integrates into the standard build cycle, so you can use the standard Maven phases to build and package your app: mvn clean , mvn compile , mvn test , mvn package , mvn install .

You can also use some of the Grails commands that have been wrapped as Maven goals:

For a complete, up to date list, run mvn grails:help

Ahora tiene una aplicación Grails lista para funcionar. El plugin se integra en el ciclo estándar de construcción, así que usted puede utilizar el estándar de las fases de Maven para construir y empaquetar su aplicación: mvn clean , mvn compile , mvn test , mvn package , mvn install .

También puede utilizar algunos de los comandos de Grails que se han creado como goals de Maven:

Para una lista completa y actualizada, ejecute mvn grails:help

Mavenizing an existing project

Creating a new project is great way to start, but what if you already have one? You don't want to create a new project and then copy the contents of the old one over. The solution is to create a POM for the existing project using this Maven command (substitute the version number with the grails version of your existing project):

mvn org.grails:grails-maven-plugin:1.3.2:create-pom -DgroupId=com.mycompany
When this command has finished, you can immediately start using the standard phases, such as mvn package. Note that you have to specify a group ID when creating the POM.

You may also want to set target JDK to Java 6; see above.

Mavenizando un proyecto existente

Crear un nuevo proyecto es una buena forma de empezar, pero ¿qué hacer si tenemos un proyecto existente? No queremos crear un nuevo proyecto y luego copiar el contenido del proyecto existente. La solución es crear un POM para el proyecto existente con este comando Maven (sustituya el número de versión con la versión de su proyecto Grails):

mvn org.grails: grails-maven-plugin: 1.3.2: create-pom-DgroupId = com.mycompany

Cuando este comando ha terminado, puede comenzar inmediatamente con las fases estándar, tales como mvn package. Tenga en cuenta que se tiene que especificar un ID de grupo al crear el POM.

También es posible que desee establecer targets JDK de Java 6, ver arriba.

Adding Grails commands to phases

The standard POM created for you by Grails already attaches the appropriate core Grails commands to their corresponding build phases, so "compile" goes in the "compile" phase and "war" goes in the "package" phase. That doesn't help though when you want to attach a plugin's command to a particular phase. The classic example is functional tests. How do you make sure that your functional tests (using which ever plugin you have decided on) are run during the "integration-test" phase?

Fear not: all things are possible. In this case, you can associate the command to a phase using an extra "execution" block:

<plugin>
    <groupId>org.grails</groupId>
    <artifactId>grails-maven-plugin</artifactId>
    <version>1.3.2</version>
    <extensions>true</extensions>
    <executions>
        <execution>
            <goals></goals>
        </execution>
        <!-- Add the "functional-tests" command to the "integration-test" phase -->
        <execution>
            <id>functional-tests</id>
            <phase>integration-test</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <command>functional-tests</command>
            </configuration>
        </execution>
    </executions>
</plugin>

Agregando comandos Grails a las fases

El POM estándar creado por Grails ya une los comandos Grails con sus fases de construcción correspondientes, por lo que "compile" va en la fase "compile" y "war" va en la fase "package". Sin embargo, esto no ayuda cuando se desea conectar un comando de un plugin con una fase determinada. El ejemplo clásico son la pruebas funcionales. ¿Cómo asegurarse de que las pruebas funcionales (con el plugin que sea) se ejecutan durante la fase "integration-test"?

No temas, todo es posible. En este caso, se puede asociar un comando a una fase con un bloque de "execution":

<plugin>
    <groupId>org.grails</groupId>
    <artifactId>grails-maven-plugin</artifactId>
    <version>1.3.2</version>
    <extensions>true</extensions>
    <executions>
        <execution>
            <goals>
            …
            </goals>
        </execution>
        <!-- Add the "functional-tests" command to the "integration-test" phase -->
        <execution>
            <id>functional-tests</id>
            <phase>integration-test</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <command>functional-tests</command>
            </configuration>
        </execution>
    </executions>
</plugin>

This also demonstrates the grails:exec goal, which can be used to run any Grails command. Simply pass the name of the command as the command system property, and optionally specify the arguments with the args property:
mvn grails:exec -Dcommand=create-webtest -Dargs=Book

Esto también muestra el goal grails:exec, que se puede utilizar para ejecutar cualquier comando de Grails. Basta con pasar el nombre del comando como la propoiedad del sistema command, y, opcionalmente, especificar los argumentos con la propiedad args:

mvn grails: exec-Dcommand = a crear webtest-Dargs = Libro

Debugging a Grails Maven Project

Maven can be launched in debug mode using the "mvnDebug" command. To launch your Grails application in debug, simply run:

mvnDebug grails:run-app

The process will be suspended on startup and listening for a debugger on port 8000.

If you need more control of the debugger, this can be specified using the MAVEN_OPTS environment variable, and launch Maven with the default "mvn" command:

MAVEN_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
mvn grails:run-app

La depuración de un proyecto Grails Maven

Maven puede ser lanzado en modo de depuración a través del comando "mvnDebug". Para iniciar su aplicación Grails en depuración, sólo tiene que ejecutar:

mvnDebug grails:run-app

El proceso será suspendido en el arranque y escucha buscando un depurador en el puerto 8000.

Si necesita más control del depurador, se puede especificar usando la variable de entorno MAVEN_OPTS, y lanzando Maven con el comando por defecto "mvn":

MAVEN_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
mvn grails:run-app

Raising issues

If you come across any problems with the Maven integration, please raise a JIRA issue as a sub-task of GRAILS-3547.

Notificando problemas

Si te encuentras con algún problema con la integración Maven, por favor, da de alta un asunto en JIRA como una sub-tarea de Grails-3547.