3 Configuración - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith
Version: null
Table of Contents
3 Configuración
It may seem odd that in a framework that embraces "convention-over-configuration" that we tackle this topic now, but since what configuration there is typically a one-off, it is best to get it out the way.With Grails' default settings you can actually develop an application without doing any configuration whatsoever. Grails ships with an embedded servlet container and in-memory H2 database, so there isn't even a database to set up.However, typically you should configure a more robust database at some point and that is described in the following section.
Puede parecer extraño que en un framework que enfatiza la "Convención sobre configuración" abordemos este tema, pero como la configuración es normalmente algo que se modifica excepcionalmente, es mejor quitárselo de encima.Con la configuración predeterminada de Grails realmente puede desarrollar una aplicación sin hacer ninguna configuración alguna. Grails cuenta con un contenedor de servlet incrustado y una base de datos en memoria H2 de, por lo que no hay siquiera una base de datos que configurar.Sin embargo, normalmente debería configurar una base de datos más robusto en algún momento, como se describe en la sección siguiente.
3.1 Configuración básica
For general configuration Grails provides a file called Then later in your application you can access these settings in one of two ways. The most common is from the GrailsApplication object, which is available as a variable in controllers and tag libraries:
La configuración general Grails proporciona un archivo llamado grails-app/conf/Config.groovy. This file uses Groovy's ConfigSlurper which is very similar to Java properties files except it is pure Groovy hence you can reuse variables and use proper Java types!You can add your own configuration in here, for example:foo.bar.hello = "world"grails-app/conf/Config.groovy. Este archivo utiliza el ConfigSlurper de Groovy que es muy similar a los archivos de propiedades de Java excepto porque es puro Groovy, así que puede reutilizar las variables y utilizar tipos propios de Java.Puede añadir su propia configuración aquí, por ejemplo:foo.bar.hello = "world"assert "world" == grailsApplication.config.foo.bar.hello
The other way involves getting a reference to the ConfigurationHolder class that holds a reference to the configuration object:
La otra forma consiste en obtener una referencia a la clase ConfigurationHolder que contiene una referencia al objeto de configuración:import org.codehaus.groovy.grails.commons.* … def config = ConfigurationHolder.config assert "world" == config.foo.bar.hello
ConfigurationHolder and ApplicationHolder are deprecated and will be removed in a future version of Grails, so it is highly preferable to access theGrailsApplicationand config from thegrailsApplicationvariable.
ConfigurationHolder y ApplicationHolder están deprecadas y se eliminarán en una versión futura de Grails, así que es preferible acceder al objetoGrailsApplicationy a la configuración desde la variablegrailsApplication.
3.1.1 Opciones disponibles
Grails also provides the following configuration options:
Grails también proporciona las siguientes opciones de configuración:
grails.config.locations- The location of properties files or addition Grails Config files that should be merged with main configurationgrails.enable.native2ascii- Set this to false if you do not require native2ascii conversion of Grails i18n properties filesgrails.views.default.codec- Sets the default encoding regime for GSPs - can be one of 'none', 'html', or 'base64' (default: 'none'). To reduce risk of XSS attacks, set this to 'html'.grails.views.gsp.encoding- The file encoding used for GSP source files (default is 'utf-8')grails.mime.file.extensions- Whether to use the file extension to dictate the mime type in Content Negotiationgrails.mime.types- A map of supported mime types used for Content Negotiationgrails.serverURL- A string specifying the server URL portion of absolute links, including server name e.g. grails.serverURL="http://my.yourportal.com". See createLink.
grails.config.locations- la ubicación de archivos de propiedades o archivos de configuración de Grails que deben combinarse con la configuración principal.grails.enable.native2ascii- se establece en false si no necesita convertir archivos de propiedades de i18n de Grails a native2ascii.grails.views.default.codec- establece la de codificación predeterminada para GSPs, puede ser 'none', 'html' o 'base64' (por defecto: 'none'). Para reducir el riesgo de ataques XSS, definir 'html'.grails.views.gsp.encoding- establece la codificación de archivos para los archivos GSP (el valor por defecto es 'utf-8').grails.mime.file.extensions- si se utiliza la extensión de archivo para dictar el tipo mime tipo en contenido Negotiationgrails.mime.types- un mapa de tipos mime admitidos utilizados al negociar contenidosgrails.serverURL- una cadena que especifica la parte URL del servidor de enlaces absolutos, incluyendo el nombre del servidor, por ejemplo, grails.serverURL="http://my.yourportal.com". Consulte createLink.
War generation
grails.project.war.file- Sets the name and location of the WAR file generated by the war commandgrails.war.dependencies- A closure containing Ant builder syntax or a list of JAR filenames. Lets you customise what libaries are included in the WAR file.grails.war.copyToWebApp- A closure containing Ant builder syntax that is legal inside an Ant copy, for example "fileset()". Lets you control what gets included in the WAR file from the "web-app" directory.grails.war.resources- A closure containing Ant builder syntax. Allows the application to do any other other work before building the final WAR file
Generación de wars
grails.project.war.file- establece el nombre y la ubicación del archivo war generado por el comando war.grails.war.dependencies- una closure que contiene la sintaxis del constructor de Ant o una lista de nombres de archivo JAR. Le permite personalizar qué librerías se incluyen en el archivo war.grails.war.copyToWebApp- una closure que contiene la sintaxis del constructor de Ant que es legal dentro de un copy de Ant, por ejemplo "fileset()". Le permite controlar qué se incluye en el archivo war desde el directorio "web-app".grails.war.resources- una closure que contiene la sintaxis del constructor de Ant. Permite a la aplicación hacer otros trabajos antes de construir el archivo war final.
3.1.2 Logging
The Basics
Grails uses its common configuration mechanism to provide the settings for the underlying Log4j log system, so all you have to do is add alog4j setting to the file grails-app/conf/Config.groovy.So what does this log4j setting look like? Here's a basic example:Los conceptos básicos
Grails utiliza su mecanismo de configuración para proporcionar la configuración base para el sistema de logs Log4j por lo que todo lo que tiene que hacer es agregar la configuración paralog4j al archivo grails-app/conf/Config.groovyAsí que ¿cómo es la configuración para este log4j? Aquí tiene un ejemplo básico:log4j = {
error 'org.codehaus.groovy.grails.web.servlet', // controllers
'org.codehaus.groovy.grails.web.pages' // GSP warn 'org.apache.catalina'
}This says that for loggers whose name starts with 'org.codehaus.groovy.grails.web.servlet' or 'org.codehaus.groovy.grails.web.pages', only messages logged at 'error' level and above will be shown. Loggers with names starting with 'org.apache.catalina' logger only show messages at the 'warn' level and above. What does that mean? First of all, you have to understand how levels work.
Esto dice que para los loggers cuyo nombre comienza con 'org.codehaus.groovy.grails.web.servlet' o 'org.codehaus.groovy.grails.web.pages', sólo se registran mensajes a nivel de 'error' y superiores. Los loggers con nombres que empiezan con 'org.apache.catalina' sólo resgistran mensajes de nivel 'warn' y superiores. ¿Qué significa eso? En primer lugar, hay que entender cómo funcionan los niveles.Logging levels
The are several standard logging levels, which are listed here in order of descending priority:- off
- fatal
- error
- warn
- info
- debug
- trace
- all
log.error(msg) will log a message at the 'error' level. Likewise, log.debug(msg) will log it at 'debug'. Each of the above levels apart from 'off' and 'all' have a corresponding log method of the same name.The logging system uses that message level combined with the configuration for the logger (see next section) to determine whether the message gets written out. For example, if you have an 'org.example.domain' logger configured like so:Niveles de registro
Existen varios niveles de registro estándar, que se listan en orden descendente de prioridad:- off
- fatal
- error
- warn
- info
- debug
- trace
- all
log.error(msg) registrará un mensaje en el nivel de "error". Asimismo, log.debug(msg) se registrará en 'debug'. Cada uno de los niveles anteriores aparte de 'off' y 'all' tienen un método de registro correspondiente con el mismo nombre.El sistema de registro utiliza el nivel del mensaje combinado con la configuración para el logger (consulte la siguiente sección) para determinar si se escribe el mensaje. Por ejemplo, si tienes un logger de 'org.example.domain' configurado así:warn 'org.example.domain'
then messages with a level of 'warn', 'error', or 'fatal' will be written out. Messages at other levels will be ignored.Before we go on to loggers, a quick note about those 'off' and 'all' levels. These are special in that they can only be used in the configuration; you can't log messages at these levels. So if you configure a logger with a level of 'off', then no messages will be written out. A level of 'all' means that you will see all messages. Simple.
luego se escribirán los mensajes con un nivel de 'warn', 'error' o 'fatal'. Se omitirán los mensajes a otros niveles.Antes de continuar con los loggers, una nota rápida sobre los nivels 'off' y 'all'. Estos son especiales ya que sólo pueden utilizarse en la configuración; no se puede registrar los mensajes en estos niveles. Así que si configura un registrador con un nivel de 'off', ningún mensaje se escribirá. Un nivel de 'all' significa que se verán todos los mensajes. Simple.Loggers
Loggers are fundamental to the logging system, but they are a source of some confusion. For a start, what are they? Are they shared? How do you configure them?A logger is the object you log messages to, so in the calllog.debug(msg), log is a logger instance (of type Log). These loggers are cached and uniquely identified by name, so if two separate classes use loggers with the same name, those loggers are actually the same instance.There are two main ways to get hold of a logger:
- use the
loginstance injected into artifacts such as domain classes, controllers and services; - use the Commons Logging API directly.
log property, then the name of the logger is 'grails.app.<type>.<className>', where type is the type of the artifact, for example 'controller' or 'service, and className is the fully qualified name of the artifact. For example, if you have this service:
Loggers
Los loggers son fundamentales para el sistema de log, pero son una fuente de confusión. Para empezar, ¿qué son? ¿son compartidos? ¿cómo configurarlos?Un logger es el objeto en el que registras mensajes, por lo que en la llamadalog.debug(msg), log es una instancia de logger (del tipo Log). Estos loggers se almacenan en caché y se identifica por su nombre, por lo que si dos clases distintas utilizan dos loggers con el mismo nombre, los loggers son realmente la misma instancia.Hay dos formas principales de apoderarse de un registrador:
- Usar la instancia de
logque se inyecta en los artefactos, como las clases de dominio, los controladores y servicios; - Utilizar la API de Commons Logging directamente.
log, entonces el nombre del log es "grails.app.<tipo>. <nombreClase> ', Donde tipo es el tipo de artefacto, por ejemplo 'controlador' o 'servicio" y nombreClase es el nombre completo del artefacto. Por ejemplo, si usted tiene este servicio:package org.exampleclass MyService {
…
}then the name of the logger will be 'grails.app.services.org.example.MyService'.For other classes, the typical approach is to store a logger based on the class name in a constant static field:
el nombre del logger será 'grails.app.services.org.example.MyService'.Para otras clases, el enfoque típico es almacenar un logger basado en el nombre de clase en un campo estático constante:package org.otherimport org.apache.commons.logging.LogFactoryclass MyClass { private static final log = LogFactory.getLog(this) … }
This will create a logger with the name 'org.other.MyClass' - note the lack of a 'grails.app.' prefix since the class isn't an artifact. You can also pass a name to the
Esto creará un logger con el nombre 'org.other.MyClass' - nota la falta de un prefijo 'grails.app.' ya que la clase no es un artefacto. También se puede pasar un nombre al método getLog() method, such as "myLogger", but this is less common because the logging system treats names with dots ('.') in a special way.Configuring loggers
You have already seen how to configure loggers in Grails:getLog(), como "myLogger", pero esto es menos común porque el sistema de registro trata los nombres con puntos ('. ') de una manera especial.Configuración de los loggers
Ya has visto cómo configurar los loggers en Grails:log4j = {
error 'org.codehaus.groovy.grails.web.servlet'
}This example configures loggers with names starting with 'org.codehaus.groovy.grails.web.servlet' to ignore any messages sent to them at a level of 'warn' or lower. But is there a logger with this name in the application? No. So why have a configuration for it? Because the above rule applies to any logger whose name begins with 'org.codehaus.groovy.grails.servlet.' as well. For example, the rule applies to both the
Este ejemplo configura los loggers con nombres que empiecen por 'org.codehaus.groovy.grails.web.servlet' para ignorar cualquier mensaje enviado a ellos a un nivel de 'warn' o inferior. ¿Pero hay un logger con este nombre en la aplicación? No. Así que ¿por qué tiene una configuración para ello? Debido a la regla anterior aplica a cualquier logger cuyo nombre empiece con 'org.codehaus.groovy.grails.servlet.' así, por ejemplo, la regla se aplica a la clase org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet class and the org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequest one.In other words, loggers are hierarchical. This makes configuring them by package much simpler than it would otherwise be.The most common things that you will want to capture log output from are your controllers, services, and other artifacts. Use the convention mentioned earlier to do that: grails.app.<artifactType>.<className> . In particular the class name must be fully qualifed, i.e. with the package if there is one:org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet y a org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequest.En otras palabras, los loggers son jerárquicos. Esto hace que configurarlos por paquete mucho más simple de lo que sería de otra manera.Las cosas más comunes que desea capturar el registro de salida son los controladores, servicios y otros artefactos. Utilice la convención mencionada anteriormente para ello: grails.app.<tipoArtefacto>.<nombreClase> . En particular el nombre de clase debe ser plenamente cualificado, es decir, con el paquete si hay uno: log4j = {
// Establece el nivel de todos los artefactos de aplicación
info "grails.app" // Establece el nivel para un controlador específico en un paquete predeterminado
debug "grails.app.controllers.YourController" // Establece el nivel para una clase de dominio específico
debug "grails.app.domain.org.example.Book" // Establecer el nivel para todos taglibs
info "grails.app.taglib"
}The standard artifact names used in the logging configuration are:
Los nombres de artefacto estándar utilizados en la configuración de log son:
conf- For anything undergrails-app/confsuch asBootStrap.groovyand filterstaglib- For tag librariesservices- For service classescontrollers- For controllersdomain- For domain entities
conf- para cualquier cosa bajograils-app/confcomo elBootStrap.groovyy filtros.taglib- para las bibliotecas de etiquetas.servicios- para las clases de servicio.controllers- Para los controladores.domain- para entidades de dominio
org.codehaus.groovy.grails.commons- Core artifact information such as class loading etc.org.codehaus.groovy.grails.web- Grails web request processingorg.codehaus.groovy.grails.web.mapping- URL mapping debuggingorg.codehaus.groovy.grails.plugins- Log plugin activitygrails.spring- See what Spring beans Grails and plugins are definingorg.springframework- See what Spring is doingorg.hibernate- See what Hibernate is doing
org.codehaus.groovy.grails.commons- información del núcleo como carga de clases etc..org.codehaus.groovy.grails.web- Procesamiento de solicitudes web de Grails.org.codehaus.groovy.grails.web.mapping- Depuración de mapeo de URLs.org.codehaus.groovy.grails.plugins- registro de actividad de plugins.grails.spring- ver qué hace beans de Spring y plugins Grails estan definidos.org.springframework- ver qué hace Spring.org.hibernate- ver lo que está haciendo ibernate.
The Root Logger
All logger objects inherit their configuration from the root logger, so if no explicit configuration is provided for a given logger, then any messages that go to that logger are subject to the rules defined for the root logger. In other words, the root logger provides the default configuration for the logging system.Grails automatically configures the root logger to only handle messages at 'error' level and above, and all the messages are directed to the console (stdout for those with a C background). You can customise this behaviour by specifying a 'root' section in your logging configuration like so:El registrador raíz
Todos los registradores heredarán su configuración del logger raíz, por lo que si no se proporciona ninguna configuración explícita para un logger determinado y así todos los mensajes que llegan a ese registrador están sujetos a las reglas definidas para el logger raíz. En otras palabras, el logger raíz proporciona la configuración predeterminada para el sistema de log.Grails configura automáticamente el logger raíz para sólo gestionar los mensajes "error" y superiores, y todos los mensajes se dirigen a la consola (stdout para aquellos con un pasado con C). Puede personalizar este comportamiento especificando una sección de 'root' en la configuración del log de este modo:log4j = {
root {
info()
}
…
}The above example configures the root logger to log messages at 'info' level and above to the default console appender. You can also configure the root logger to log to one or more named appenders (which we'll talk more about shortly):
En el ejemplo anterior se configura el logger raíz para registrar mensajes a nivel de 'info' y por encima en el appender de consola predeterminada. También puede configurar el logger raíz para registrar a uno o más appenders con nombre (sobre lo que ya hablaremos más en breve):log4j = {
appenders {
file name:'file', file:'/var/logs/mylog.log'
}
root {
debug 'stdout', 'file'
}
}In the above example, the root logger will log to two appenders - the default 'stdout' (console) appender and a custom 'file' appender.For power users there is an alternative syntax for configuring the root logger: the root
En el ejemplo anterior, el registrador raíz registrará a dos appenders, el appender predeterminada 'debug' (consola) y un appender personalizado 'file'.Para usuarios avanzados existe una sintaxis alternativa para configurar el logger raíz: la instancia de logger raiz org.apache.log4j.Logger instance is passed as an argument to the log4j closure. This lets you work with the logger directly:org.apache.log4j.Logger se pasa como un argumento a la closure de log4j. Esto le permite trabajar directamente con el logger:log4j = { root ->
root.level = org.apache.log4j.Level.DEBUG
…
}For more information on what you can do with this
Para obtener más información sobre lo que puede hacer con esta instancia de Logger instance, refer to the Log4j API documentation.Those are the basics of logging pretty well covered and they are sufficient if you're happy to only send log messages to the console. But what if you want to send them to a file? How do you make sure that messages from a particular logger go to a file but not the console? These questions and more will be answered as we look into appenders.Appenders
Loggers are a useful mechanism for filtering messages, but they don't physically write the messages anywhere. That's the job of the appender, of which there are various types. For example, there is the default one that writes messages to the console, another that writes them to a file, and several others. You can even create your own appender implementations!This diagram shows how they fit into the logging pipeline:Logger, consulte la documentación de la API de Log4j.Esos son los elementos básicos de registro bastante bien cubiertos y son suficientes si sólo quieres enviar mensajes de log a la consola. Pero ¿qué sucede si desea registrar en un archivo? ¿Cómo asegurarnos de que los mensajes de un logger particular vayan a un archivo, pero no a la consola? Se responderá estas preguntas y más revisando los appenders.Appenders
Los loggers son un mecanismo útil para el filtrado de mensajes, pero físicamente no escriben los mensajes en ningún sitio. Esto es trabajo del appender, de los cuales hay varios tipos. Por ejemplo, el appender por defecto escribe los mensajes de la consola, existe otro que escribe en un archivo y algunos otros. ¡Incluso puede crear su propia implementación!Este diagrama muestra cómo encajan en el flujo de registro:
As you can see, a single logger may have several appenders attached to it. In a standard Grails configuration, the console appender named 'stdout' is attached to all loggers through the default root logger configuration. But that's the only one. Adding more appenders can be done within an 'appenders' block:
Como puede ver, un logger puede tener varios appenders conectados a él. En una configuración estándar de Grails, el appender de consola denominada 'debug' está unido a todos los logger mediante la configuración predeterminada del logger raíz. Pero es el único. Agregar más appenders puede hacerse dentro de un bloque de 'appenders':log4j = {
appenders {
rollingFile name: "myAppender",
maxFileSize: 1024,
file: "/tmp/logs/myApp.log"
}
}The following appenders are available by default:
Las siguientes appenders están disponibles de forma predeterminada:| Name | Class | Description |
|---|---|---|
| jdbc | JDBCAppender | Logs to a JDBC connection. |
| console | ConsoleAppender | Logs to the console. |
| file | FileAppender | Logs to a single file. |
| rollingFile | RollingFileAppender | Logs to rolling files, for example a new file each day. |
| Nombre | Clase | Descripción |
|---|---|---|
| jdbc | JDBCAppender | Registra a una conexión JDBC. |
| consola | ConsoleAppender | Registra en la consola. |
| file | FileAppender | Registra a un archivo. |
| rollingFile | RollingFileAppender | Registra a varios archivos, por ejemplo un archivo nuevo cada día. |
Each named argument passed to an appender maps to a property of the underlying Appender implementation. So the previous example sets the
Cada argumento con nombre pasado a un appender se asigna a una propiedad de la implementación subyacente del Appender. Así que el ejemplo anterior establece las propiedades name, maxFileSize and file properties of the RollingFileAppender instance.You can have as many appenders as you like - just make sure that they all have unique names. You can even have multiple instances of the same appender type, for example several file appenders that log to different files.If you prefer to create the appender programmatically or if you want to use an appender implementation that's not available in the above syntax, simply declare an appender entry with an instance of the appender you want:
nombre, maxFileSize y file de la instancia de RollingFileAppender.Puede tener tantos appenders como quiera, solo asegúrese que todos tienen nombres únicos. Incluso puede tener varias instancias del mismo tipo appender, por ejemplo de varios appenders file que registran en archivos diferentes.Si prefiere crear el appender mediante programación o si desea utilizar una implementación de appender que no está disponible en la sintaxis anterior, simplemente declarar una entrada appender con la instancia del appender que desee:import org.apache.log4j.*log4j = { appenders { appender new RollingFileAppender( name: "myAppender", maxFileSize: 1024, file: "/tmp/logs/myApp.log") } }
This approach can be used to configure This will ensure that the 'grails.app.controllers.BookController' logger sends log messages to 'myAppender' as well as any appenders configured for the root logger. To add more than one appender to the logger, then add them to the same level declaration:
Este enfoque puede utilizarse para configurar JMSAppender, SocketAppender, SMTPAppender, and more.Once you have declared your extra appenders, you can attach them to specific loggers by passing the name as a key to one of the log level methods from the previous section:error myAppender: "grails.app.controllers.BookController"JMSAppender, SocketAppender, SMTPAppender y muchos más.Una vez que ha declarado sus appenders adicionales, puede conectarlos a loggers específicos pasando el nombre como clave a uno de los métodos de registro de niveles de la sección anterior:error myAppender: "grails.app.controllers.BookController"error myAppender: "grails.app.controllers.BookController", myFileAppender: ["grails.app.controllers.BookController", "grails.app.services.BookService"], rollingFile: "grails.app.controllers.BookController"
The above example also shows how you can configure more than one logger at a time for a given appender (
El ejemplo anterior muestra cómo puede configurar más de un logger para un determinado appender (myFileAppender) by using a list.
myFileAppender) usando una lista.
Be aware that you can only configure a single level for a logger, so if you tried this code:you'd find that only 'fatal' level messages get logged for 'grails.app.controllers.BookController'. That's because the last level declared for a given logger wins. What you probably want to do is limit what level of messages an appender writes.
Tenga en cuenta que sólo se puede configurar un único nivel de un logger, así que si has probado este código:error myAppender: "grails.app.controllers.BookController" debug myFileAppender: "grails.app.controllers.BookController" fatal rollingFile: "grails.app.controllers.BookController"
error myAppender: "grails.app.controllers.BookController" debug myFileAppender: "grails.app.controllers.BookController" fatal rollingFile: "grails.app.controllers.BookController"
An appender that is attached to a logger configured with the 'all' level will generate a lot of logging information. That may be fine in a file, but it makes working at the console difficult. So we configure the console appender to only write out messages at 'info' level or above:
Un appender que está conectada a un logger configurado con el nivel 'all' va a generar una gran cantidad de información de registro. Esto puede estar bien en un archivo, pero hace difícil trabajar en la consola. Así que configuramos el appender consola sólo para escribir mensajes a nivel de 'info' o superior:log4j = {
appenders {
console name: "stdout", threshold: org.apache.log4j.Level.INFO
}
}The key here is the
La clave aquí es el argumento threshold argument which determines the cut-off for log messages. This argument is available for all appenders, but do note that you currently have to specify a Level instance - a string such as "info" will not work.Custom Layouts
By default the Log4j DSL assumes that you want to use a PatternLayout. However, there are other layouts available including:xml- Create an XML log filehtml- Creates an HTML log filesimple- A simple textual logpattern- A Pattern layout
threshold que determina el límite de mensajes de log. Este argumento está disponible para todos los appenders, pero tenga en cuenta que actualmente tiene que especificar una instancia Level, una cadena como "info" no funcionará.Esquemas personalizados
De forma predeterminada el DSL asume que desea utilizar PatternLayout. Sin embargo, hay otros esquemas disponibles incluyendo:xml- crear un archivo de log XMLhtml- crea un archivo de log HTMLsimple- un simple log textualpatrón- diseño de un esquema
You can specify custom patterns to an appender using the
Puede especificar esquemas personalizados para un appender mediante el parámetro layout setting:layout:log4j = {
appenders {
console name: "customAppender",
layout: pattern(conversionPattern: "%c{2} %m%n")
}
}
This also works for the built-in appender "stdout", which logs to the console:
Esto también funciona para el appender incorporado "debug", que inicia una sesión en la consola:
log4j = {
appenders {
console name: "stdout",
layout: pattern(conversionPattern: "%c{2} %m%n")
}
}Environment-specific configuration
Since the logging configuration is insideConfig.groovy, you can put it inside an environment-specific block. However, there is a problem with this approach: you have to provide the full logging configuration each time you define the log4j setting. In other words, you cannot selectively override parts of the configuration - it's all or nothing.To get around this, the logging DSL provides its own environment blocks that you can put anywhere in the configuration:Configuración específica para el entorno
Desde que la configuración de registro está dentro deConfig.groovy, puede colocarlo dentro de un bloque específico de entorno. Sin embargo, hay un problema con este enfoque: tiene que proporcionar la configuración de registro completa cada vez que se defina la configuración log4j. En otras palabras, no se puede anular de manera selectiva elementos de la configuración, es todo o nada.Para evitar esto, el DSL de log proporciona sus propios bloques de entorno que puede colocar en cualquier parte de la configuración:log4j = {
appenders {
console name: "stdout",
layout: pattern(conversionPattern: "%c{2} %m%n") environments {
production {
rollingFile name: "myAppender", maxFileSize: 1024,
file: "/tmp/logs/myApp.log"
}
}
} root {
//…
} // other shared config
info "grails.app.controller" environments {
production {
// Override previous setting for 'grails.app.controller'
error "grails.app.controller"
}
}
}The one place you can't put an environment block is inside the
El lugar no se puede poner un bloque de entorno es dento la definición root definition, but you can put the root definition inside an environment block.Full stacktraces
When exceptions occur, there can be an awful lot of noise in the stacktrace from Java and Groovy internals. Grails filters these typically irrelevant details and restricts traces to non-core Grails/Groovy class packages.When this happens, the full trace is always logged to theStackTrace logger, which by default writes its output to a file called stacktrace.log. As with other loggers though, you can change its behaviour in the configuration. For example if you prefer full stack traces to go to the console, add this entry:root, pero puede poner la definición root dentro de un bloque de entorno.Stacktraces completa
Cuando se producen excepciones, puede haber mucho ruido en el stacktrace de Java y Groovy. Grails filtra estos detalles típicamente irrelevantes y restringe la traza a paquetes de clase Groovy/Grails complementarios.Cuando esto sucede, la traza completa siempre se registra para el loggerStackTrace, que, por defecto, escribe su salida a un archivo denominado stacktrace.log. Como con otros loggers, puede cambiar su comportamiento en la configuración. Por ejemplo, si prefiere que estas trazasvayan a la consola, puede agregar esta entrada:error stdout: "StackTrace"This won't stop Grails from attempting to create the stacktrace.log file - it just redirects where stack traces are written to. An alternative approach is to change the location of the 'stacktrace' appender's file:
Esto no impedirá que Grails intente crear el archivo stacktrace.log, simplemente redirige donde se escriben trazas. Un método alternativo es cambiar la ubicación del archivo del appender 'stacktrace':log4j = {
appenders {
rollingFile name: "stacktrace", maxFileSize: 1024,
file: "/var/tmp/logs/myApp-stacktrace.log"
}
}or, if you don't want to the 'stacktrace' appender at all, configure it as a 'null' appender:
o, si no desea el appender 'stacktrace', puede configurarlo como un appender 'null':log4j = {
appenders {
'null' name: "stacktrace"
}
}You can of course combine this with attaching the 'stdout' appender to the 'StackTrace' logger if you want all the output in the console.Finally, you can completely disable stacktrace filtering by setting the
Por supuesto puede combinarlo con anexar el appender 'stdout' al logger 'StackTrace' si desea toda la salida de la consola.Por último, puede deshabilitar completamente el filtrado stacktrace estableciendo la propiedad VM grails.full.stacktrace VM property to true:grails -Dgrails.full.stacktrace=true run-appgrails.full.stacktrace a true:grails -Dgrails.full.stacktrace=true run-appMasking Request Parameters From Stacktrace Logs
When Grails logs a stacktrace, the log message may include the names and values of all of the request parameters for the current request. To mask out the values of secure request parameters, specify the parameter names in thegrails.exceptionresolver.params.exclude config property:grails.exceptionresolver.params.exclude = ['password', 'creditCard']
grails.exceptionresolver.logRequestParameters config property to false. The default value is true when the application is running in DEVELOPMENT mode and false for all other modes.grails.exceptionresolver.logRequestParameters=falseEnmascaramiento de parámetros de request de registros Stacktrace
Cuando Grails registra una stacktrace, el mensaje de log puede incluir los nombres y valores de todos los parámetros de la petición de la request actual. Para ocultar los valores de parámetros de request segura, especifique los nombres de parámetro en la propiedad de configuracióngrails.exceptionresolver.params.exclude:grails.exceptionresolver.params.exclude = ['password', 'creditCard']
grails.exceptionresolver.logRequestParameters a false. El valor predeterminado es true cuando la aplicación se ejecuta en modo de desarrollo y false para todos los demás modos.Grails.exceptionresolver.logRequestParameters=falseLogger inheritance
Earlier, we mentioned that all loggers inherit from the root logger and that loggers are hierarchical based on '.'-separated terms. What this means is that unless you override a parent setting, a logger retains the level and the appenders configured for that parent. So with this configuration:Herencia de logger
Anteriormente, se mencionó que todos los registradores heredarán del logger raíz y que los registradores son jerárquicos basados en el separador '.'. Esto significa que a menos que reemplace a un padre, un logger mantiene el nivel y las appenders configurados para ese padre. Por lo tanto con esta configuración:log4j = {
appenders {
file name:'file', file:'/var/logs/mylog.log'
}
root {
debug 'stdout', 'file'
}
}all loggers in the application will have a level of 'debug' and will log to both the 'stdout' and 'file' appenders. What if you only want to log to 'stdout' for a particular logger? Change the 'additivity' for a logger in that case.Additivity simply determines whether a logger inherits the configuration from its parent. If additivity is false, then its not inherited. The default for all loggers is true, i.e. they inherit the configuration. So how do you change this setting? Here's an example:
todos los loggers en la aplicación tendrán un nivel de 'debug' y registrarán a los appenders 'stdout' y 'file'. ¿Y si sólo desea registrar a 'stdout' para un registrador particular? Cambie el 'additivity' para un logger en ese caso.'Additivity' simplemente determina si un registrador hereda la configuración de su padre. Si 'additivity' es falso, entonces es no heredado. El valor predeterminado para todos los registradores es cierto, es decir, heredan la configuración. Entonces, ¿cómo se cambia esta configuración? Aquí está un ejemplo:log4j = {
appenders {
…
}
root {
…
} info additivity: false
stdout: ["grails.app.controllers.BookController",
"grails.app.services.BookService"]
}So when you specify a log level, add an 'additivity' named argument. Note that you when you specify the additivity, you must configure the loggers for a named appender. The following syntax will not work:
Así que cuando se especifica un nivel de registro, agregue un argumento 'additivity'. Tenga en cuenta que cuando se especifica la 'additivity', debe configurar los loggers para un appender con nombre. La siguiente sintaxis no funcionará:info additivity: false, ["grails.app.controllers.BookController", "grails.app.services.BookService"]
Customizing stack trace printing and filtering
info additivity: false, ["grails.app.controllers.BookController", "grails.app.services.BookService"]
Personalización de impresión y filtro de stacktraces
Stacktraces in general and those generated when using Groovy in particular are quite verbose and contain many stack frames that aren't interesting when diagnosing problems. So Grails uses a implementation of the In addition, Grails customizes the display of the filtered stacktrace to make the information more readable. To customize this, implement the
Las tacktraces en general y aquellas generadas al usar Groovy en particular son bastante detallados y contienen muchos líneas que no son interesantes al diagnosticar problemas. Así Grails utiliza una implementación de la interfaz org.codehaus.groovy.grails.exceptions.StackTraceFilterer interface to filter out irrelevant stack frames. To customize the approach used for filtering, implement that interface in a class in src/groovy or src/java and register it in Config.groovy:grails.logging.stackTraceFiltererClass =
'com.yourcompany.yourapp.MyStackTraceFilterer'org.codehaus.groovy.grails.exceptions.StackTracePrinter interface in a class in src/groovy or src/java and register it in Config.groovy:org.codehaus.groovy.grails.exceptions.StackTraceFilterer para filtrar las líneas irrelevantes. Para personalizar el enfoque utilizado para filtrar, puede implementar esta interfaz en una clase en src/groovy o src/java y registrarlo en Config.groovy:grails.logging.stackTraceFiltererClass =
'com.yourcompany.yourapp.MyStackTraceFilterer'org.codehaus.groovy.grails.exceptions.StackTracePrinter en una clase en src/groovy o src/java y registrarlo en Config.groovy:grails.logging.stackTracePrinterClass =
'com.yourcompany.yourapp.MyStackTracePrinter'Finally, to render error information in the error GSP, an HTML-generating printer implementation is needed. The default implementation is
Por último, para procesar información de error en error del SGP, es necesaria una implementación de impresora generadora de HTML. La implementación predeterminada es org.codehaus.groovy.grails.web.errors.ErrorsViewStackTracePrinter and it's registered as a Spring bean. To use your own implementation, either implement the org.codehaus.groovy.grails.exceptions.StackTraceFilterer directly or subclass ErrorsViewStackTracePrinter and register it in grails-app/conf/spring/resources.groovy as:org.codehaus.groovy.grails.web.errors.ErrorsViewStackTracePrinter y está registrada como un bean de Spring. Para utilizar su propia implementación, puede implementar org.codehaus.groovy.grails.exceptions.StackTraceFilterer directamente o hacer una subclase de ErrorsViewStackTracePrinter y regístrarla en grails-app/conf/spring/resources.groovy así:import com.yourcompany.yourapp.MyErrorsViewStackTracePrinterbeans = { errorsViewStackTracePrinter(MyErrorsViewStackTracePrinter,
ref('grailsResourceLocator'))
}3.1.3 GORM
Grails provides the following GORM configuration options:
and to enable failOnError for domain classes by package:
Grails ofrece las siguientes opciones de configuración de GORM:
grails.gorm.failOnError- If set totrue, causes thesave()method on domain classes to throw agrails.validation.ValidationExceptionif validation fails during a save. This option may also be assigned a list of Strings representing package names. If the value is a list of Strings then the failOnError behavior will only be applied to domain classes in those packages (including sub-packages). See the save method docs for more information.
grails.gorm.failOnError=truegrails.gorm.failOnError- si establece entruecausas save()método en las clases de dominio a tirar ungrails.validation.ValidationExceptionvalidation falle durante un save. Esta opción puede asignarse también una lista de cadenas que representan los nombres de los paquetes. Si el valor es una lista de cadenas, a continuación, el comportamiento failOnError sólo se aplicará a las clases de dominio de los paquetes (incluyendo sub-paquetes). Consulte a la documentación de método save para obtener más información.
Grails.Gorm.failOnError=truegrails.gorm.failOnError = ['com.companyname.somepackage',
'com.companyname.someotherpackage']Grails.Gorm.failOnError = ['com.companyname.somepackage',
'com.companyname.someotherpackage']grails.gorm.autoFlush= si se establece en truecausas merge, save y delete métodos para realizar el vaciado de la sesión, reemplazando a la necesidad de vaciar explícitamente utilizandosave(flush: true).
3.2 Entornos
Per Environment Configuration
Grails supports the concept of per environment configuration. TheConfig.groovy, DataSource.groovy, and BootStrap.groovy files in the grails-app/conf directory can use per-environment configuration using the syntax provided by ConfigSlurper. As an example consider the following default DataSource definition provided by Grails:Configuración por entornos
Grails es compatible con el concepto de configuración por entornos. Los archivosConfig.groovy, DataSource.groovy y BootStrap.groovy en el directorio grails-app/conf pueden utilizar configuración por entorno por medio con la sintaxis proporcionada por ConfigSlurper. Como ejemplo, considere la siguiente definición por defecto del DataSource proporcionada por Grails:dataSource {
pooled = false
driverClassName = "org.h2.Driver"
username = "sa"
password = ""
}
environments {
development {
dataSource {
dbCreate = "create-drop"
url = "jdbc:h2:mem:devDb"
}
}
test {
dataSource {
dbCreate = "update"
url = "jdbc:h2:mem:testDb"
}
}
production {
dataSource {
dbCreate = "update"
url = "jdbc:h2:prodDb"
}
}
}Notice how the common configuration is provided at the top level and then an
Observe cómo la configuración común se proporciona en el nivel superior y, a continuación, especifica un bloque environments block specifies per environment settings for the dbCreate and url properties of the DataSource.Packaging and Running for Different Environments
Grails' command line has built in capabilities to execute any command within the context of a specific environment. The format is:grails [environment] [command name]
environments especificando valores por entorno para dbCreate y la propiedad url para el DataSource.Empaquetado y ejecución para distintos entornos
La línea de comando de Grails tiene capacidad para ejecutar cualquier comando dentro del contexto de un entorno específico. El formato es:Grails [entorno] [nombre de comando]
In addition, there are 3 preset environments known to Grails: To target other environments you can pass a
Además, hay 3 entornos preestablecidos para Grails: dev, prod, and test for development, production and test. For example to create a WAR for the test environment you wound run:grails test war
grails.env variable to any command:grails -Dgrails.env=UAT run-app
dev, prod, y test, para development, production y test. Por ejemplo, para crear un WAR para el entorno de test puede ejecutar:grails test war
grails.env para cualquier comando:Grails-Dgrails.env=UAT run-app
Programmatic Environment Detection
Within your code, such as in a Gant script or a bootstrap class you can detect the environment using the Environment class:Detección de entorno mediante programación
Dentro del código, como en un script de Gant o una clase de bootstrap se puede detectar el entorno mediante la clase Environment:import grails.util.Environment...switch (Environment.current) { case Environment.DEVELOPMENT: configureForDevelopment() break case Environment.PRODUCTION: configureForProduction() break }
Per Environment Bootstrapping
Its often desirable to run code when your application starts up on a per-environment basis. To do so you can use thegrails-app/conf/BootStrap.groovy file's support for per-environment execution:Bootstrap por entorno
A menudo es deseable ejecutar código cuando la aplicación se inicia dependiendo del entorno. Para ello puede utilizar el soporte por entornos del archivograils-app/conf/BootStrap.groovy :def init = { ServletContext ctx ->
environments {
production {
ctx.setAttribute("env", "prod")
}
development {
ctx.setAttribute("env", "dev")
}
}
ctx.setAttribute("foo", "bar")
}Generic Per Environment Execution
The previousBootStrap example uses the grails.util.Environment class internally to execute. You can also use this class yourself to execute your own environment specific logic:Ejecución genérica por entorno
En el ejemplo anterior deBootStrap se utiliza la clase grails.util.Environment internamente para ejecutar. También puede utilizar esta clase para ejecutar su propia lógica específica del entorno:Environment.executeForCurrentEnvironment {
production {
// hacer algo en producción
}
development {
// hacer algo en desarrollo
}
}3.3 El orígen de datos
Since Grails is built on Java technology setting up a data source requires some knowledge of JDBC (the technology that doesn't stand for Java Database Connectivity).If you use a database other than H2 you need a JDBC driver. For example for MySQL you would need Connector/JDrivers typically come in the form of a JAR archive. It's best to use Ivy to resolve the jar if it's available in a Maven repository, for example you could add a dependency for the MySQL driver like this:
Dado que Grails se basa en la tecnología Java configurar un origen de datos requiere algunos conocimientos de JDBC (la tecnología que no es Java Database Connectivity).Si utiliza una base de datos que no sea H2 necesita un driver JDBC. Por ejemplo para MySQL sería necesario Connector/JLos drivers suelen empaquetarse en forma de un archivo JAR. Es mejor utilizar Ivy para resolver el jar si está disponible en un repositorio de Maven, por ejemplo podría añadir una dependencia para el controlador de MySQL como esta:grails.project.dependency.resolution = {
inherits("global")
log "warn"
repositories {
grailsPlugins()
grailsHome()
grailsCentral()
mavenCentral()
}
dependencies {
runtime 'mysql:mysql-connector-java:5.1.16'
}
}
Note that the built-in
Tenga en cuenta que el repositorio incorporado mavenCentral() repository is included here since that's a reliable location for this library.If you can't use Ivy then just put the JAR in your project's lib directory.Once you have the JAR resolved you need to get familiar Grails' DataSource descriptor file located at grails-app/conf/DataSource.groovy. This file contains the dataSource definition which includes the following settings:mavenCentral() se incluye aquí ya es un lugar confiable para esta biblioteca.Si no puede utilizar Ivy, ponga el jar en el directorio lib del proyecto.Una vez que tenga el jar resuelto necesita familiarizarse con el descriptor del origen de datos de Grails, ubicado en grails-app/conf/DataSource.groovy. Este archivo contiene la definición de origen de datos que incluye las siguientes opciones:driverClassName- The class name of the JDBC driverusername- The username used to establish a JDBC connectionpassword- The password used to establish a JDBC connectionurl- The JDBC URL of the databasedbCreate- Whether to auto-generate the database from the domain model - one of 'create-drop', 'create', 'update' or 'validate'pooled- Whether to use a pool of connections (defaults to true)logSql- Enable SQL logging to stdoutformatSql- Format logged SQLdialect- A String or Class that represents the Hibernate dialect used to communicate with the database. See the org.hibernate.dialect package for available dialects.readOnly- Iftruemakes the DataSource read-only, which results in the connection pool callingsetReadOnly(true)on eachConnectionproperties- Extra properties to set on the DataSource bean. See the Commons DBCP BasicDataSource documentation.
driverClassName- el nombre de clase del controlador JDBC.username- el nombre de usuario utilizado para establecer una conexión JDBC.password- la contraseña utilizada para establecer una conexión JDBC.url- la URL JDBC de la base de datos.dbCreate- si se va a generar automáticamente la base de datos del dominio modelo - uno de 'create-drop'(borrar-crear), 'create'(crear), 'update'(actualizar) o 'validate' (valiadar).pooled- si va a utilizar un pool de conexiones (de forma predeterminada es true)logSql- habilitar el registro de SQL a stdout.formatSql- formato del SQL.dialect- clase o una cadena representa el dialecto de hibertnate utilizado para comunicarse con la base de datos. Ver el paquete org.hibernate.dialect para dialectos disponibles.readOnly- sitruehace el origen de datos de sólo lectura, lo que resulta en que el pool de conexiones llama asetReadOnly(true)con cadaconexión.properties- propiedades adicionales para establecer en el bean DataSource. Consulte la documentación de Commons DBCP BasicDataSource.
dataSource {
pooled = true
dbCreate = "update"
url = "jdbc:mysql://localhost/yourDB"
driverClassName = "com.mysql.jdbc.Driver"
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
username = "yourUser"
password = "yourPassword"
}When configuring the DataSource do not include the type or the def keyword before any of the configuration settings as Groovy will treat these as local variable definitions and they will not be processed. For example the following is invalid:
Cuando configurando el origen de datos se incluyen el tipo o la palabra clave de def antes de cualquiera de las opciones de configuración, Groovy tratará estas como definiciones de variables locales y no se procesarán. Por ejemplo, lo siguiente es inválido:
dataSource {
boolean pooled = true // type declaration results in ignored local variable
…
}
Example of advanced configuration using extra properties:
Ejemplo de configuración avanzada utilizando propiedades adicionales:
dataSource {
pooled = true
dbCreate = "update"
url = "jdbc:mysql://localhost/yourDB"
driverClassName = "com.mysql.jdbc.Driver"
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
username = "yourUser"
password = "yourPassword"
properties {
maxActive = 50
maxIdle = 25
minIdle = 5
initialSize = 5
minEvictableIdleTimeMillis = 60000
timeBetweenEvictionRunsMillis = 60000
maxWait = 10000
validationQuery = "/* ping */"
}
}More on dbCreate
Hibernate can automatically create the database tables required for your domain model. You have some control over when and how it does this through thedbCreate property, which can take these values:
- create - Drops the existing schemaCreates the schema on startup, dropping existing tables, indexes, etc. first.
- create-drop - Same as create, but also drops the tables when the application shuts down cleanly.
- update - Creates missing tables and indexes, and updates the current schema without dropping any tables or data. Note that this can't properly handle many schema changes like column renames (you're left with the old column containing the existing data).
- validate - Makes no changes to your database. Compares the configuration with the existing database schema and reports warnings.
- any other value - does nothing
Más sobre dbCreate
Hibernate puede crear automáticamente las tablas de base de datos necesarias para su modelo de dominio. Tiene algún control sobre cuándo y cómo lo hace a través de la propiedaddbCreate, que puede tomar estos valores:
- create - borra la estructura vigente el esquema en el inicio, borrando tablas, índices, etc. primero.
- create-drop - igual que create, pero también borra las tablas cuando se cierra la aplicación sin errores.
- update - crea las tablas e índices que faltan y actualiza el esquema actual sin perder datos ni las tablas. Tenga en cuenta que esto no puede manejar correctamente muchos cambios en el esquema como cambios de nombre de columna (te dejan la antigua columna que contiene los datos existentes).
- validate - no modifica la base de datos. Compara la configuración con el esquema de base de datos existente y las reporta los avisos.
- cualquier otro valor - no hace nada
You can also remove the
También puede quitar el parámetro dbCreate setting completely, which is recommended once your schema is relatively stable and definitely when your application and database are deployed in production. Database changes are then managed through proper migrations, either with SQL scripts or a migration tool like Liquibase (the Database Migration plugin uses Liquibase and is tightly integrated with Grails and GORM).
dbCreate, que es lo recomendado una vez que su esquema es relativamente estable y definitivamente cuando su base de datos y aplicaciones se implementan en producción. Los cambios de la base de datos son administrados a través de las migraciones adecuadas, con secuencias de comandos SQL o una herramienta de migración como Liquibase (el plugin Database Migration utiliza Liquibase y está estrechamente integrado con Grails y GORM).
3.3.1 Orígenes de datos y entornos
The previous example configuration assumes you want the same config for all environments: production, test, development etc.Grails' DataSource definition is "environment aware", however, so you can do:
La configuración del ejemplo anterior asume que desea la misma configuración para todos los entornos: producción, pruebas, desarrollo, etc..La definición de origen de datos de Grails es sensible al entorno, por lo que puedes hacer o siguiente:dataSource {
pooled = true
driverClassName = "com.mysql.jdbc.Driver"
dialect = org.hibernate.dialect.MySQL5InnoDBDialect
// other common settings here
}environments {
production {
dataSource {
url = "jdbc:mysql://liveip.com/liveDb"
// other environment-specific settings here
}
}
}3.3.2 Orígenes de datos JNDI
Referring to a JNDI DataSource
Most Java EE containers supplyDataSource instances via Java Naming and Directory Interface (JNDI). Grails supports the definition of JNDI data sources as follows:Utilizando un origen de datos JNDI
La mayoría de los contenedores J2EE proporcionan instancias deDataSource a través de Java Naming and Directory Interface (JNDI). Grails es compatible con la definición de orígenes de datos JNDI como sigue:dataSource {
jndiName = "java:comp/env/myDataSource"
}The format on the JNDI name may vary from container to container, but the way you define the
El formato del nombre JNDI puede variar de un contenedor a otro, pero la manera de definir el DataSource in Grails remains the same.Configuring a Development time JNDI resource
The way in which you configure JNDI data sources at development time is plugin dependent. Using the Tomcat plugin you can define JNDI resources using thegrails.naming.entries setting in grails-app/conf/Config.groovy:DataSource en Grails sigue siendo la misma.Configuración de un recurso JNDI de tiempo de desarrollo
La forma en que puede configurar orígenes de datos JNDI al tiempo de desarrollo depende del plugin utilizado. Utilizando el plugin de Tomcat plugin puede definir recursos JNDI mediantegrails.naming.entries en grails-app/conf/Config.groovy:grails.naming.entries = [
"bean/MyBeanFactory": [
auth: "Container",
type: "com.mycompany.MyBean",
factory: "org.apache.naming.factory.BeanFactory",
bar: "23"
],
"jdbc/EmployeeDB": [
type: "javax.sql.DataSource", //required
auth: "Container", // optional
description: "Data source for Foo", //optional
driverClassName: "org.h2.Driver",
url: "jdbc:h2:mem:database",
username: "dbusername",
password: "dbpassword",
maxActive: "8",
maxIdle: "4"
],
"mail/session": [
type: "javax.mail.Session,
auth: "Container",
"mail.smtp.host": "localhost"
]
]3.3.3 Migraciones automáticas de bases de datos
The
La propiedad dbCreate property of the DataSource definition is important as it dictates what Grails should do at runtime with regards to automatically generating the database tables from GORM classes. The options are described in the DataSource section:
createcreate-dropupdatevalidate- no value
dbCreate is by default set to "create-drop", but at some point in development (and certainly once you go to production) you'll need to stop dropping and re-creating the database every time you start up your server.dbCreate de la definición del DataSource es importante ya que dicta lo que debe hacer Grails en tiempo de ejecución con respecto a la generación automática de las tablas de base de datos de clases GORM. Las opciones se describen en la sección DataSource:
createcreate-dropupdatevalidate- no value
dbCreate es por defecto "create-drop" (borrar y crear), pero en algún punto en el desarrollo (y, desde luego, una vez pase a la producción) deberá dejar de borrar y volver a crear la base de datos cada vez que inicie el servidor.It's tempting to switch to
Es tentador cambiar a update so you retain existing data and only update the schema when your code changes, but Hibernate's update support is very conservative. It won't make any changes that could result in data loss, and doesn't detect renamed columns or tables, so you'll be left with the old one and will also have the new one.Grails supports Rails-style migrations via the Database Migration plugin which can be installed by running
grails install-plugin database-migrationThe plugin uses Liquibase and and provides access to all of its functionality, and also has support for GORM (for example generating a change set by comparing your domain classes to a database).
update (actualizar) para mantener los datos existentes y sólo actualizar el esquema cuando el código cambia, pero el soporte de actualización de Hibernate es muy conservador. No realizar los cambios que podrían dar lugar a pérdida de datos y no detecta renombrado de columnas o tablas, por lo que quedará con el viejo y también con el nuevo.Grails soporta migraciones estilo Rails a través del plugin Database Migration plugin que puede instalarse mediante la ejecución de
grails install-plugin database-migrationEl plugin utiliza Liquibase y proporciona acceso a toda su funcionalidad y también cuenta con soporte para GORM (por ejemplo generando un cambio comparando sus clases de dominio con una base de datos).
3.3.4 Proxy de origen de datos preparado para transacción
The actual
El dataSource bean is wrapped in a transaction-aware proxy so you will be given the connection that's being used by the current transaction or Hibernate Session if one is active.If this were not the case, then retrieving a connection from the dataSource would be a new connection, and you wouldn't be able to see changes that haven't been committed yet (assuming you have a sensible transaction isolation setting, e.g. READ_COMMITTED or better).The "real" unproxied dataSource is still available to you if you need access to it; its bean name is dataSourceUnproxied.You can access this bean like any other Spring bean, i.e. using dependency injection:
dataSource bean está envuelto en un proxy preparado para la transacción por lo que se le dará la conexión que se utiliza en la transacción actual o la Session Hibernate si está activa.Si esto no fuera el caso, entonces recuperar una conexión desde el datasource sería una nueva conexión, y no sería capaz de ver los cambios que no hayan sido comprometidos aún (suponiendo que tiene un aislamiento de transacción razonable, por ejemplo, READ_COMMITTED o mejor).El dataSource real fuera del proxy sigue estando disponible si necesita tener acceso a él; su nombre de bean es dataSourceUnproxied.Se puede acceder a este bean como a cualquier otro bean de Spring, es decir, mediante inyección de dependencias:class MyService { def dataSourceUnproxied
…
}
or by pulling it from the
o solicitándolo al ApplicationContext:
ApplicationContext:def dataSourceUnproxied = ctx.dataSourceUnproxied
3.3.5 La consola de la Base de Datos
The H2 database console is a convenient feature of H2 that provides a web-based interface to any database that you have a JDBC driver for, and it's very useful to view the database you're developing against. It's especially useful when running against an in-memory database.
La consola de base de datos H2 es una práctica función de H2 que proporciona una interfaz basada en web para cualquier base de datos que tenga un driver JDBC, y es muy útil para ver la base de datos contra la que se está desarrollando. Es especialmente útil cuando se ejecuta contra una base de datos en memoria.
You can access the console by navigating to http://localhost:8080/appname/dbconsole in a browser. The URI can be configured using the
Para acceder a la consola, vaya a la dirección http://localhost:8080/appname/dbconsole en un navegador. La URI se puede configurar mediante el atributo grails.dbconsole.urlRoot attribute in Config.groovy and defaults to '/dbconsole'.
grails.dbconsole.urlRoot en el Config.groovy y por defecto es '/dbconsole'.
The console is enabled by default in development mode and can be disabled or enabled in other environments by using the
La consola está activada por defecto en el modo de desarrollo y puede ser activada o desactivada en otros ambientes mediante el uso del atributo grails.dbconsole.enabled attribute in Config.groovy. For example you could enable the console in production using
grails.dbconsole.enabled en el Config.groovy. Por ejemplo, podría habilitar la consola en la producción así:environments {
production {
grails.serverURL = "http://www.changeme.com"
grails.dbconsole.enabled = true
grails.dbconsole.urlRoot = '/admin/dbconsole'
}
development {
grails.serverURL = "http://localhost:8080/${appName}"
}
test {
grails.serverURL = "http://localhost:8080/${appName}"
}
}If you enable the console in production be sure to guard access to it using a trusted security framework.
Configuration
By default the console is configured for an H2 database which will work with the default settings if you haven't configured an external database - you just need to change the JDBC URL tojdbc:h2:mem:devDB. If you've configured an external database (e.g. MySQL, Oracle, etc.) then you can use the Saved Settings dropdown to choose a settings template and fill in the url and username/password information from your DataSource.groovy.
Si habilita la consola en producción asegúrese de proteger el acceso a ella mediante un framework de seguridad de confianza.
Configuración
Por defecto, la consola está configurada para una base de datos H2 que funciona con la configuración predeterminada si no ha configurado una base de datos externa; basta con cambiar la URL JDBC ajdbc:h2:mem:devDB. Si ha configurado una base de datos externa (por ejemplo, MySQL, Oracle, etc.) puede utilizar la lista desplegable de Saved Settings para seleccionar una plantilla y rellenar la url, y el nombre de usuario y contraseña de tu DataSource.groovy.
3.3.6 Orígenes de datos multiples
By default all domain classes share a single
Por defecto, todas las clases de dominio compartan un solo DataSource and a single database, but you have the option to partition your domain classes into two or more DataSources.Configuring Additional DataSources
The defaultDataSource configuration in grails-app/conf/DataSource.groovy looks something like this:
DataSource y una única base de datos, pero tiene la opción de dividir las clases de dominio en dos o más DataSources.Configuración de orígenes de datos adicionales
La configuración delDataSource por defecto en grails-app/conf/DataSource.groovy es algo como esto:dataSource {
pooled = true
driverClassName = "org.h2.Driver"
username = "sa"
password = ""
}
hibernate {
cache.use_second_level_cache = true
cache.use_query_cache = true
cache.provider_class = 'net.sf.ehcache.hibernate.EhCacheProvider'
}environments {
development {
dataSource {
dbCreate = "create-drop"
url = "jdbc:h2:mem:devDb"
}
}
test {
dataSource {
dbCreate = "update"
url = "jdbc:h2:mem:testDb"
}
}
production {
dataSource {
dbCreate = "update"
url = "jdbc:h2:prodDb"
}
}
}
This configures a single
Esto configura un único DataSource with the Spring bean named dataSource. To configure extra DataSources, add another dataSource block (at the top level, in an environment block, or both, just like the standard DataSource definition) with a custom name, separated by an underscore. For example, this configuration adds a second DataSource, using MySQL in the development environment and Oracle in production:
DataSource con un bean de Spring llamado dataSource. Para configurar DataSources adicionales, agregue otro bloque dataSource (en el nivel superior, en un bloque de entorno, o ambos, al igual que la definición estándar de DataSource) con un nombre personalizado, separado por un guión bajo. Por ejemplo, esta configuración agrega un segundo DataSource, usando MySQL en el entorno de desarrollo y Oracle en producción:environments {
development {
dataSource {
dbCreate = "create-drop"
url = "jdbc:h2:mem:devDb"
}
dataSource_lookup {
dialect = org.hibernate.dialect.MySQLInnoDBDialect
driverClassName = 'com.mysql.jdbc.Driver'
username = 'lookup'
password = 'secret'
url = 'jdbc:mysql://localhost/lookup'
dbCreate = 'update'
}
}
test {
dataSource {
dbCreate = "update"
url = "jdbc:h2:mem:testDb"
}
}
production {
dataSource {
dbCreate = "update"
url = "jdbc:h2:prodDb"
}
dataSource_lookup {
dialect = org.hibernate.dialect.Oracle10gDialect
driverClassName = 'oracle.jdbc.driver.OracleDriver'
username = 'lookup'
password = 'secret'
url = 'jdbc:oracle:thin:@localhost:1521:lookup'
dbCreate = 'update'
}
}
}
You can use the same or different databases as long as they're supported by Hibernate.
Puede utilizar las mismos o diferentes bases de datos siempre y cuando esté soportadas por Hibernate.Configuring Domain Classes
If a domain class has noDataSource configuration, it defaults to the standard 'dataSource'. Set the datasource property in the mapping block to configure a non-default DataSource. For example, if you want to use the ZipCode domain to use the 'lookup' DataSource, configure it like this;
Configuración de clases de dominio
Si una clase de dominio no tiene ninguna configuración deDataSource, utiliza el 'dataSource' estándar. Debe establecer la propiedad datasource en el bloque mapping para configurar otro DataSource. Por ejemplo, si desea que el dominio ZipCode utilice el DataSource 'lookup', configurelo así:class ZipCode { String code static mapping = {
datasource 'lookup'
}
}
A domain class can also use two or more
Una clase de dominio también puede utilizar dos o más DataSources. Use the datasources property with a list of names to configure more than one, for example:
DataSources. Use la propiedad datasources con una lista de nombres para configurar más de uno, por ejemplo:class ZipCode { String code static mapping = {
datasources(['lookup', 'auditing'])
}
}
If a domain class uses the default
Si una clase de dominio utiliza el DataSource and one or more others, use the special name 'DEFAULT' to indicate the default DataSource:
DataSource por defecto y algún o algunos otros, utilice el nombre especial 'DEFAULT' para indicar el DataSource por defecto:class ZipCode { String code static mapping = {
datasources(['lookup', 'DEFAULT'])
}
}
If a domain class uses all configured
Si una clase de dominio utiliza todos los DataSources use the special value 'ALL':
DataSources configurados use el valor especial 'ALL':class ZipCode { String code static mapping = {
datasource 'ALL'
}
}Namespaces and GORM Methods
If a domain class uses more than oneDataSource then you can use the namespace implied by each DataSource name to make GORM calls for a particular DataSource. For example, consider this class which uses two DataSources:
Espacios de nombres y métodos GORM
Si una clase de dominio utiliza más de unDataSource puede utilizar el espacio de nombres que implica cada nombre de DataSource para hacer llamadas GORM para un determinado DataSource. Por ejemplo, esta clase que utiliza dos DataSources:class ZipCode { String code static mapping = {
datasources(['lookup', 'auditing'])
}
}
The first As you can see, you add the
El primer DataSource specified is the default when not using an explicit namespace, so in this case we default to 'lookup'. But you can call GORM methods on the 'auditing' DataSource with the DataSource name, for example:def zipCode = ZipCode.auditing.get(42) … zipCode.auditing.save()
DataSource to the method call in both the static case and the instance case.
DataSource especificado es el valor por defecto cuando no se utiliza un espacio de nombre explícito, por lo que en este caso el predeterminado es 'lookup'. Pero puede llamar a métodos GORM con el DataSource con nombre del DataSource, por ejemplo:def zipCode = ZipCode.auditing.get(42) … zipCode.auditing.save()
DataSource a la llamada de método tanto en el caso de llamada estática como en el caso de la instancia.Services
Like Domain classes, by default Services use the defaultDataSource and PlatformTransactionManager. To configure a Service to use a different DataSource, use the static datasource property, for example:
Servicios
Como las clases de dominio, los servicios utilizan elDataSource por defecto y el PlatformTransactionManager. Para configurar un servicio para que utilice un DataSource diferente , utilice la propiedad estática datasource, por ejemplo:class DataService { static datasource = 'lookup' void someMethod(...) {
…
}
}
A transactional service can only use a single
Un servicio transaccional puede sólo utilizar un único DataSource, so be sure to only make changes for domain classes whose DataSource is the same as the Service.Note that the datasource specified in a service has no bearing on which datasources are used for domain classes; that's determined by their declared datasources in the domain classes themselves. It's used to declare which transaction manager to use.What you'll see is that if you have a Foo domain class in dataSource1 and a Bar domain class in dataSource2, and WahooService uses dataSource1, a service method that saves a new Foo and a new Bar will only be transactional for Foo since they share the datasource. The transaction won't affect the Bar instance. If you want both to be transactional you'd need to use two services and XA datasources for two-phase commit, e.g. with the Atomikos plugin.DataSource, así que asegúrese de sólo hacer cambios para las clases de dominio cuyos DataSource es el mismo que el del servicio.Tenga en cuenta que la fuente de datos que se especifica en un servicio no tiene relación con las fuentes de datos que se utilizan para las clases de dominio, que son determinadas por los orígenes de datos declarados en las clases de dominio. Se utiliza para declarar que administrador de transacciones se utilizará.Lo que verá es que si usted tiene una clase de dominio Foo en un DataSource1 y una clase de dominio Bar en el dataSource2 y un servicio WahooService utiliza el DataSource1, un método del servicio que salva un nuevo Foo y un nuevo Bar sólo será transaccional para Foo, ya que comparten la fuente de datos, y la operación no afectará a la instancia de Bar. Si quieres ser transaccional para ambas instancias tendrá que utilizar dos servicios y fuentes de datos con commit en dos fases, por ejemplo, con el plugin Atomikos.XA and Two-phase Commit
Grails has no native support for XADataSources or two-phase commit, but the Atomikos plugin makes it easy. See the plugin documentation for the simple changes needed in your DataSource definitions to reconfigure them as XA DataSources.XA y commit en dos fases
Grails no tiene soporte nativo paraDataSources XA o commit en dos fases, pero el plugin Atomikos hace que sea fácil. Consulte la documentación de plugin para conocer los cambios que debe hacer en la definición de su DataSource para configurarlos como DataSources XA.
3.4 Externalizando la configuración
Some deployments require that configuration be sourced from more than one place and be changeable without requiring a rebuild of the application. In order to support deployment scenarios such as these the configuration can be externalized. To do so, point Grails at the locations of the configuration files that should be used by adding a
Algunas implementaciones requieren que la configuración proceda de más de una ubicación y sea intercambiables sin necesidad de un redespliegue de la aplicación. Para admitir estos escenarios de despliegue la configuración puede ser externalizada. Para ello, señale a Grails las ubicaciones de los archivos de configuración que deben utilizarse mediante la adición de un valor de grails.config.locations setting in Config.groovy, for example:grails.config.locations en Config.groovy, por ejemplo:Grails.config.Locations = [
"classpath:$ {appName}-config.properties",
"classpath:$ {appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy"]In the above example we're loading configuration files (both Java Properties files and ConfigSlurper configurations) from different places on the classpath and files located in This can be useful in situations where the config is either coming from a plugin or some other part of your application. A typical use for this is re-using configuration provided by plugins across multiple applications.
En el ejemplo anterior estamos cargando archivos de configuración (archivos de propiedades Java y configuraciones de ConfigSlurper de diferentes lugares del classpath y archivos ubicados en USER_HOME.It is also possible to load config by specifying a class that is a config script.grails.config.locations = [com.my.app.MyConfig]
USER_HOME.También es posible cargar configuración especificando una clase que es un script de configuración.Grails.config.Locations = [com.my.app.MyConfig]
Ultimately all configuration files get merged into the
En última instancia todos los archivos de configuración se fusionaron en la propiedad config property of the GrailsApplication object and are hence obtainable from there.Values that have the same name as previously defined values will overwrite the existing values, and the pointed to configuration sources are loaded in the order in which they are defined.Config Defaults
The configuration values contained in the locations described by thegrails.config.locations property will override any values defined in your application Config.groovy file which may not be what you want. You may want to have a set of default values be be loaded that can be overridden in either your application's Config.groovy file or in a named config location. For this you can use the grails.config.defaults.locations property.This property supports the same values as the grails.config.locations property (i.e. paths to config scripts, property files or classes), but the config described by grails.config.defaults.locations will be loaded before all other values and can therefore be overridden. Some plugins use this mechanism to supply one or more sets of default configuration that you can choose to include in your application config.config del objeto GrailsApplication y, por tanto, puede obtenerse a partir de ahí.Los valores que tienen el mismo nombre que otros valores definidos anteriormente sobrescribirán los valores existentes y las referencias de configuración se cargan en el orden en el que se definen.Valores de configuración predeterminados
Los valores de configuración contenidos en los lugares descritos por la propiedadgrails.config.locations sobreescribirán los valores definidos en el archivo Config.groovy de la aplicación que puede no ser lo que quiere. Puede que desee tener un conjunto de valores por defecto cargados que pueden ser sobreescritos en el archivo Config.groovy de la aplicación o en cualquier localización definida. Para ello puede utilizar la propiedad grails.config.defaults.locations.Esta propiedad soporta los mismos valores que la propiedad grails.config.locations (es decir, rutas para scripts de configuración, los archivos de propiedad o clases), pero la configuración descrita por grails.config.defaults.locations será cargada antes que todos los demás valores y por lo tanto, se puede reemplazar. Algunos plugins usan este mecanismo para proporcionar uno o más conjuntos de configuración por defecto que puede incluir en la configuración de su aplicación.Grails also supports the concept of property place holders and property override configurers as defined in Spring For more information on these see the section on Grails and Spring
Grails también soporta el concepto de titulares de la propiedad y configuradores de reemplazo de propiedad tal como se define en Spring Para obtener más información sobre estos, consulte la sección Grails y Spring
3.5 Versionado
Versioning Basics
Grails has built in support for application versioning. The version of the application is set to0.1 when you first create an application with the create-app command. The version is stored in the application meta data file application.properties in the root of the project.To change the version of your application you can edit the file manually, or run the set-version command:Conceptos básicos de versionado
Grails se ha construido con soporte a la creación de versiones de aplicaciones. La versión de la aplicación se establece en0,1 cuando se crea una aplicación con el comando create-app. La versión se almacena en el archivo de meta datos de la aplicación application.properties en la raíz del proyecto.Para cambiar la versión de la aplicación puede editar manualmente el archivo o ejecute el comando set-version:grails set-version 0.2
The version is used in various commands including the war command which will append the application version to the end of the created WAR file.
La versión se utiliza en varios comandos incluyendo el comando war que anexará la versión de la aplicación al final en el nombre del archivo war creado.Detecting Versions at Runtime
You can detect the application version using Grails' support for application metadata using the GrailsApplication class. For example within controllers there is an implicit grailsApplication variable that can be used:Detectar versiones en tiempo de ejecución
Puede detectar la versión de la aplicación mediante el soporte de Grails para metadatos de aplicación mediante la clase GrailsApplication. Por ejemplo dentro de los controllers es una variable implícita grailsApplication que puede utilizarse:def version = grailsApplication.metadata['app.version']
You can retrieve the the version of Grails that is running with:
Puede recuperar la versión de Grails que se ejecuta con:def grailsVersion = grailsApplication.metadata['app.grails.version']
or the
o en la clase GrailsUtil class:
GrailsUtil:import grails.util.GrailsUtil
…
def grailsVersion = GrailsUtil.grailsVersionnull
3.6 Documentación del projecto
Since Grails 1.2, the documentation engine that powers the creation of this documentation has been available for your own Grails projects.The documentation engine uses a variation on the Textile syntax to automatically create project documentation with smart linking, formatting etc.
Desde Grails 1.2, el motor de documentación usado para la creación de esta documentación ha estado disponible para sus propios proyectos de Grails.El motor de documentación utiliza una variación de la sintaxis de Textile para crear automáticamente la documentación del proyecto con enlaces, formato, etc..Creating project documentation
To use the engine you need to follow a few conventions. First, you need to create asrc/docs/guide directory where your documentation source files will go. Then, you need to create the source docs themselves. Each chapter should have its own gdoc file as should all numbered sub-sections. You will end up with something like:Creación de documentación del proyecto
Para utilizar el motor tiene que seguir unos convenios. En primer lugar, debe crear a un directoriosrc/docs/guide donde irán sus archivos de documentación. A continuación, debe crear a los documentos propiamente. Cada capítulo debe tener su propio archivo de gdoc así como las subsecciones. Acabará con algo así como:+ src/docs/guide/introduction.gdoc + src/docs/guide/introduction/changes.gdoc + src/docs/guide/gettingStarted.gdoc + src/docs/guide/configuration.gdoc + src/docs/guide/configuration/build.gdoc + src/docs/guide/configuration/build/controllers.gdoc
Note that you can have all your gdoc files in the top-level directory if you want, but you can also put sub-sections in sub-directories named after the parent section - as the above example shows.Once you have your source files, you still need to tell the documentation engine what the structure of your user guide is going to be. To do that, you add a
Tenga en cuenta que puede tener todos los archivos gdoc en el directorio de nivel superior si quiere, pero también puede poner subsecciones en subdirectorios después de la sección principal, como se muestra en el ejemplo anterior.Una vez que tenga los archivos origen, aún necesita decirle al motor de documentación lo que va a ser la estructura de la Guía de Usuario. Para hacerlo, debe agregar un archivo src/docs/guide/toc.yml file that contains the structure and titles for each section. This file is in YAML format and basically represents the structure of the user guide in tree form. For example, the above files could be represented as:src/docs/guide/toc.yml que contiene la estructura y los títulos de cada sección. Este archivo está en formato YAML y básicamente representa la estructura de la Guía de Usuario en forma de árbol. Por ejemplo, los archivos anteriores podrían representarse como:introduction:
title: Introduction
changes: Change Log
gettingStarted: Getting Started
configuration:
title: Configuration
build:
title: Build Config
controllers: Specifying Controllers
The format is pretty straightforward. Any section that has sub-sections is represented with the corresponding filename (minus the .gdoc extension) followed by a colon. The next line should contain
El formato es bastante sencillo. Cualquier sección que tiene subsecciones se representa con el nombre de archivo correspondiente (menos la extensión .gdoc) seguido de dos puntos. La siguiente línea debe contener title: plus the title of the section as seen by the end user. Every sub-section then has its own line after the title. Leaf nodes, i.e. those without any sub-sections, declare their title on the same line as the section name but after the colon.That's it. You can easily add, remove, and move sections within the toc.yml to restructure the generated user guide. You should also make sure that all section names, i.e. the gdoc filenames, should be unique since they are used for creating internal links and for the HTML filenames. Don't worry though, the documentation engine will warn you of duplicate section names.Creating reference items
Reference items appear in the Quick Reference section of the documentation. Each reference item belongs to a category and a category is a directory located in thesrc/docs/ref directory. For example, suppose you have defined a new controller method called renderPDF. That belongs to the Controllers category so you would create a gdoc text file at the following location:title: además el título de la sección como lo verá el usuario final. Así, cada subsección tiene su propia línea después del título. Los nodos hoja, es decir, aquellos sin ningún subsección, declaran su título en la misma línea que el nombre de sección pero después de los dos puntos.Eso es todo. Puede agregar, eliminar y mover secciones dentro de toc.yml para reestructurar la Guía de Usuario generada. También debe asegurarse de que todos los nombres de sección, es decir, los nombres de los archivos gdoc, deben ser únicos, ya que se utilizan para crear enlaces internos y los nombres de archivo HTML. No se preocupe de ello, porque el motor de documentación le avisará de los nombres de sección duplicados.Creación de elementos de referencia
Elementos de referencia aparecen en la sección de referencia rápida de la documentación. Cada elemento de referencia pertenece a una categoría y una categoría es un directorio ubicado en el directoriosrc/docs/ref. Por ejemplo, suponga que ha definido un nuevo método de controlador llamado renderPDF. Pertenece a la categoría controladores por lo que debe crear un archivo de texto gdoc en la siguiente ubicación:+ src/docs/ref/Controllers/renderPDF.gdoc
Configuring Output Properties
There are various properties you can set within yourgrails-app/conf/Config.groovy file that customize the output of the documentation such as:
- grails.doc.authors - The authors of the documentation
- grails.doc.license - The license of the software
- grails.doc.copyright - The copyright message to display
- grails.doc.footer - The footer to use
Configuración de las propiedades de salida
Hay varias propiedades que se pueden definir en el archivograils-app/conf/Config.groovy que personalizan el resultado de la documentación, como:
- grails.doc.authors - los autores de la documentación
- grails.doc.license - la licencia del software
- grails.doc.copyright - el mensaje de copyright para mostrar
- grails.doc.footer - el pie de página para utilizar
Other properties such as the name of the documentation and the version are pulled from your project itself.
Otras propiedades como el nombre de la versión y la documentación son extraídos de su propio proyecto.Generating Documentation
Once you have created some documentation (refer to the syntax guide in the next chapter) you can generate an HTML version of the documentation using the command:Generación de documentación
Una vez haya creado alguna documentación (consulte la Guía de sintaxis en el capítulo siguiente) puede generar una versión HTML de la documentación mediante el comando:grails doc
This command will output an
Este comando generará un docs/manual/index.html which can be opened in a browser to view your documentation.Documentation Syntax
As mentioned the syntax is largely similar to Textile or Confluence style wiki markup. The following sections walk you through the syntax basics.Basic Formatting
docs/manual/index.html que se puede abrir en un navegador para ver la documentación.Sintaxis de documentación
Como se ha mencionado, la sintaxis es muy similar al estilo de marcado de wiki de Textile o Confluence. Las siguientes secciones le guían a través de los fundamentos de la sintaxis.Formato básico
Monospace:monospace
@monospace@
_italic_
*bold*
_italic_

!http://grails.org/images/new/grailslogo_topNav.png!
Linking
There are several ways to create links with the documentation generator. A basic external link can either be defined using confluence or textile style markup:[SpringSource|http://www.springsource.com/]
"SpringSource":http://www.springsource.com/Enlazando
Hay varias formas de crear vínculos con el generador de documentación. Un enlace externo básico puede definirse mediante el estilo marcado de Confluence o Textile:[SpringSource|http://www.springsource.com/]
"SpringSource":http://www.springsource.com/
For links to other sections inside the user guide you can use the The section name comes from the corresponding gdoc filename. The documentation engine will warn you if any links to sections in your guide break.To link to reference items you can use a special syntax:
Para enlaces a otras secciones dentro de la Guía de Usuario puede utilizar el prefijo guide: prefix with the name of the section you want to link to:[Intro|guide:introduction]
guide: con el nombre de la sección que desea enlazar:[Intro|guide:introduction]
[controllers|renderPDF]
In this case the category of the reference item is on the left hand side of the | and the name of the reference item on the right.Finally, to link to external APIs you can use the
En este caso la categoría del elemento de referencia es el lado izquierdo de la | y el nombre del elemento de referencia es el de la derecha.Finalmente, para vincular a las API externas puede utilizar el prefijo api: prefix. For example:api:. Por ejemplo:[String|api:java.lang.String]
The documentation engine will automatically create the appropriate javadoc link in this case. To add additional APIs to the engine you can configure them in The above example configures classes within the
El motor de documentación creará automáticamente el vínculo javadoc apropiado en este caso. Para agregar APIs adicionales al motor se puede configurar en grails-app/conf/Config.groovy. For example:grails.doc.api.org.hibernate=
"http://docs.jboss.org/hibernate/stable/core/javadocs"org.hibernate package to link to the Hibernate website's API docs.grails-app/conf/Config.groovy. Por ejemplo:grails.doc.api.org.hibernate=
"http://docs.jboss.org/hibernate/stable/core/javadocs"org.hibernate para vincular documentos de APIs del sitio web de Hibernate.Lists and Headings
Headings can be created by specifying the letter 'h' followed by a number and then a dot:h3.<space>Heading3 h4.<space>Heading4
Listas y cabeceras
Las cabeceras pueden crearse mediante la especificación de la letra 'h' seguido de un número y un punto:h3.<space>Título3 h4.<space>Heading4
* item 1 ** subitem 1 ** subitem 2 * item 2
Numbered lists can be defined with the # character:
Las listas numeradas pueden definirse con el carácter #:# item 1
Tables can be created using the
Las tablas pueden ser generadas usando la macro table macro:| Name | Number |
|---|---|
| Albert | 46 |
| Wilma | 1348 |
| James | 12 |
table:| Name | Number |
|---|---|
| Albert | 46 |
| Wilma | 1348 |
| James | 12 |
{table}
*Nombre* | *Número*
Albert | 46
Wilma | 1348
James | 12
{table}Code and Notes
You can define code blocks with thecode macro:Código y notas
Puede definir bloques de código con la macrocode:class Book {
String title
}{code}
class Book {
String title
}
{code}
The example above provides syntax highlighting for Java and Groovy code, but you can also highlight XML markup:
El ejemplo anterior proporciona resaltado de sintaxis para código Java y Groovy, pero también puede resaltar código XML:<hello>world</hello>
{code:xml}
<hello>world</hello>
{code}There are also a couple of macros for displaying notes and warnings:
También hay un par de macros para mostrar notas y avisos:Note:
This is a note!
{note}
This is a note!
{note}Warning:
Advertencia:This is a warning!
{warning}
This is a warning!
{warning}3.7 Resolución de dependencias
Grails features a dependency resolution DSL that lets you control how plugins and JAR dependencies are resolved.You specify a
Grails ofrece un DSL de resolución de dependencia que le permite controlar cómo se resuelven las dependencias de plugins y de los JAR.Especifica una propiedad grails.project.dependency.resolution property inside the grails-app/conf/BuildConfig.groovy file that configures how dependencies are resolved:grails.project.dependency.resolution dentro del archivo grails-app/conf/BuildConfig.groovy que configura cómo se resuelven las dependencias:grails.project.dependency.resolution = {
// config here
}The default configuration looks like the following:
La configuración por defecto el siguiente aspecto:grails.project.class.dir = "target/classes" grails.project.test.class.dir = "target/test-classes" grails.project.test.reports.dir = "target/test-reports" //grails.project.war.file = "target/${appName}-${appVersion}.war"grails.project.dependency.resolution = { // inherit Grails' default dependencies inherits("global") { // uncomment to disable ehcache // excludes 'ehcache' } log "warn" repositories { grailsPlugins() grailsHome() grailsCentral() // uncomment these to enable remote dependency resolution // from public Maven repositories //mavenCentral() //mavenLocal() //mavenRepo "http://snapshots.repository.codehaus.org" //mavenRepo "http://repository.codehaus.org" //mavenRepo "http://download.java.net/maven/2/" //mavenRepo "http://repository.jboss.com/maven2/" } dependencies { // specify dependencies here under either 'build', 'compile', // 'runtime', 'test' or 'provided' scopes eg. // runtime 'mysql:mysql-connector-java:5.1.16' } plugins { compile ":hibernate:$grailsVersion" compile ":jquery:1.6.1.1" compile ":resources:1.0" build ":tomcat:$grailsVersion" } }
The details of the above will be explained in the next few sections.
Los detalles sobre lo anterior se explica en las siguientes secciones.
3.7.1 Configuración y dependencias
Grails features five dependency resolution configurations (or 'scopes'):
Grails ofrece cinco configuraciones de resolución de dependencia (o 'ámbitos'):
-
build: Dependencies for the build system only -
compile: Dependencies for the compile step -
runtime: Dependencies needed at runtime but not for compilation (see above) -
test: Dependencies needed for testing but not at runtime (see above) -
provided: Dependencies needed at development time, but not during WAR deployment
dependencies block you can specify a dependency that falls into one of these configurations by calling the equivalent method. For example if your application requires the MySQL driver to function at runtime you can specify that like this:build: dependencias sólo para el sistema de compilación.compile: dependencias para el tiempo de compilación.runtime: dependencias necesarias en tiempo de ejecución, pero no para la compilación (véase más arriba).test: dependencias necesarias para las pruebas, pero no en tiempo de ejecución (véase más arriba).provided: dependencias necesarias en el tiempo de desarrollo, pero no durante el despliegue de WAR.
dependencies puede especificar una dependencia que corresponde con una de estas configuraciones llamando al método equivalente. Por ejemplo, si su aplicación requiere el controlador MySQL funcione en tiempo de ejecución(runtime) puede especificaro así:runtime 'com.mysql:mysql-connector-java:5.1.16'
This uses the string syntax:
Esto utiliza la sintaxis de cadena: group:name:version. You can also use a Map-based syntax:group:name:version. También puede utilizar una sintaxis basada en mapas:runtime group: 'com.mysql',
name: 'mysql-connector-java',
version: '5.1.16'In Maven terminology,
En la terminología de Maven, group corresponds to an artifact's groupId and name corresponds to its artifactId.Multiple dependencies can be specified by passing multiple arguments:group corresponde al groupId de un artefacto y name corresponde a su artifactId.Varias dependencias pueden especificarse pasando varios argumentos:runtime 'com.mysql:mysql-connector-java:5.1.16',
'net.sf.ehcache:ehcache:1.6.1'// oruntime(
[group:'com.mysql', name:'mysql-connector-java', version:'5.1.16'],
[group:'net.sf.ehcache', name:'ehcache', version:'1.6.1']
)Disabling transitive dependency resolution
By default, Grails will not only get the JARs and plugins that you declare, but it will also get their transitive dependencies. This is usually what you want, but there are occasions where you want a dependency without all its baggage. In such cases, you can disable transitive dependency resolution on a case-by-case basis:Deshabilitar la resolución de dependencias transitiva
De forma predeterminada, Grails no sólo obtendrá los jars y plugins que se declaran, sino también sus dependencias transitivas. Esto suele ser lo que se desea, pero hay ocasiones donde desea una dependencia sin todo su equipaje. En tales casos, puede deshabilitar la resolución de dependencia transitivas:runtime('com.mysql:mysql-connector-java:5.1.16',
'net.sf.ehcache:ehcache:1.6.1') {
transitive = false
}// o
runtime group:'com.mysql',
name:'mysql-connector-java',
version:'5.1.16',
transitive:falseExcluding specific transitive dependencies
A far more common scenario is where you want the transitive dependencies, but some of them cause issues with your own dependencies or are unnecessary. For example, many Apache projects have 'commons-logging' as a transitive dependency, but it shouldn't be included in a Grails project (we use SLF4J). That's where theexcludes option comes in:Excluyendo las dependencias transitivas específicas
Un escenario mucho más común es cuando desea las dependencias transitivas, pero algunos de ellos causan problemas con sus propias dependencias o son innecesarias. Por ejemplo, muchos proyectos de Apache tienen 'commons-logging' como una dependencia transitiva, pero no debería ser incluido en un proyecto Grails (utilizamos SLF4J). Ahí es donde la opciónexcludes interviene:runtime('com.mysql:mysql-connector-java:5.1.16',
'net.sf.ehcache:ehcache:1.6.1') {
excludes "xml-apis", "commons-logging"
}// o
runtime(group:'com.mysql', name:'mysql-connector-java', version:'5.1.16') {
excludes([ group: 'xml-apis', name: 'xml-apis'],
[ group: 'org.apache.httpcomponents' ],
[ name: 'commons-logging' ])As you can see, you can either exclude dependencies by their artifact ID (also known as a module name) or any combination of group and artifact IDs (if you use the Map notation). You may also come across
Como puede ver, puede excluir las dependencias por su ID de artefacto (también conocido como un nombre de módulo) o cualquier combinación de ID de grupo y artefacto (si se utiliza la notación del mapa). También puede utilizar exclude as well, but that can only accept a single string or Map:exclude, pero este sólo puede aceptar una sola cadena o mapa:runtime('com.mysql:mysql-connector-java:5.1.16',
'net.sf.ehcache:ehcache:1.6.1') {
exclude "xml-apis"
}Using Ivy module configurations
If you use Ivy module configurations and wish to depend on a specific configuration of a module, you can use thedependencyConfiguration method to specify the configuration to use.Utilizando las configuraciones de módulo de Ivy
Si utiliza las configuraciones de módulo de Ivy y desea depender de una configuración específica de un módulo, puede utilizar el métododependencyConfiguration para especificar la configuración a usar.provided("my.org:web-service:1.0") { dependencyConfiguration "api" }
If the dependency configuration is not explicitly set, the configuration named
Si no se establece explícitamente la configuración de la dependencia, la configuración denominada "default" will be used (which is also the correct value for dependencies coming from Maven style repositories).
"default" se utilizará (que es también el valor correcto para dependencias procedentes de repositorios de estilo Maven).
3.7.2 Repositorios de dependencias
Remote Repositories
Initially your BuildConfig.groovy does not use any remote public Maven repositories. There is a defaultgrailsHome() repository that will locate the JAR files Grails needs from your Grails installation. To use a public repository, specify it in the repositories block:Repositorios remotos
Inicialmente su BuildConfig.groovy no utiliza los repositorios Maven públicos remotos. Existe un repositorio por defectograilsHome() que buscará los archivos JAR Grails necesarios para la instalación de Grails. Para usar un público, especifiquelo en bloque repositories:repositories {
mavenCentral()
}In this case the default public Maven repository is specified. To use the SpringSource Enterprise Bundle Repository you can use the
En este caso se especifica el repositorio de Maven público predeterminado. Para utilizar el repositorio de paquetes empresarial de SpringSource (Enterprise Bundle Repository) puede utilizar el método ebr() method:ebr() método:repositories {
ebr()
}You can also specify a specific Maven repository to use by URL:
También puede especificar un repositorio Maven específico utilizando una URL:repositories {
mavenRepo "http://repository.codehaus.org"
}Controlling Repositories Inherited from Plugins
A plugin you have installed may define a reference to a remote repository just as an application can. By default your application will inherit this repository definition when you install the plugin.Repositorios de control heredados de Plugins
Un plugin que ha instalado puede definir una referencia a un repositorio remoto igual que una aplicación. Por defecto la aplicación heredará esta definición de repositorio al instalar el plugin.If you do not wish to inherit repository definitions from plugins then you can disable repository inheritance:
Si no desea heredar las definiciones de repositorio de plugins puede desactivar herencia del repositorio:repositories {
inherit false
}En este caso su aplicación no heredará las definiciones de repositorio de plugins y es su labor proporcionar definiciones adecuadas de repositorio (posiblemente internos).
Local Resolvers
If you do not wish to use a public Maven repository you can specify a flat file repository:repositories {
flatDir name:'myRepo', dirs:'/path/to/repo'
}Resoluciones locales
Si no desea usar un repositorio Maven puede especificar un repositorio de archivos planos:repositories {
flatDir name:'myRepo', dirs:'/path/to/repo'
}~/.m2/repository) as a repository:Para especificar su memoria caché local de Maven (
~/.m2/repository) como un repositorio:repositories {
mavenLocal()
}Custom Resolvers
If all else fails since Grails builds on Apache Ivy you can specify an Ivy resolver:Resoluciones personalizadas
Si todo lo demás falla como Grails se basa en Apache Ivy puede especificar una resolución Ivy:/* * Configure our resolver. */ def libResolver = new org.apache.ivy.plugins.resolver.URLResolver() ['libraries', 'builds'].each { libResolver.addArtifactPattern( "http://my.repository/${it}/" + "[organisation]/[module]/[revision]/[type]s/[artifact].[ext]") libResolver.addIvyPattern( "http://my.repository/${it}/" + "[organisation]/[module]/[revision]/[type]s/[artifact].[ext]") }libResolver.name = "my-repository" libResolver.settings = ivySettingsresolver libResolver
It's also possible to pull dependencies from a repository using SSH. Ivy comes with a dedicated resolver that you can configure and include in your project like so:
También es posible extraer las dependencias de un repositorio mediante SSH. Ivy viene con una resolutor dedicado que puede configurar e incluir en el proyecto como tal:import org.apache.ivy.plugins.resolver.SshResolver … repositories { ... def sshResolver = new SshResolver( name: "myRepo", user: "username", host: "dev.x.com", keyFile: new File("/home/username/.ssh/id_rsa"), m2compatible: true) sshResolver.addArtifactPattern( "/home/grails/repo/[organisation]/[artifact]/" + "[revision]/[artifact]-[revision].[ext]") sshResolver.latestStrategy = new org.apache.ivy.plugins.latest.LatestTimeStrategy() sshResolver.changingPattern = ".*SNAPSHOT" sshResolver.setCheckmodified(true) resolver sshResolver }
Download the JSch JAR and add it to Grails' classpath to use the SSH resolver. You can do this by passing the path in the Grails command line:
Descargue el JAR JSch y añadalo al classpath de Grails para utilizar el resolutor SSH. Puede hacerlo pasando la ruta en la línea de comandos de Grails:grails -classpath /path/to/jsch compile|run-app|etc.
You can also add its path to the
También puede agregar su ruta a la variable de entorno CLASSPATH environment variable but be aware this it affects many Java applications. An alternative on Unix is to create an alias for grails -classpath ... so that you don't have to type the extra arguments each time.CLASSPATH pero tenga en cuenta este afecta a muchas aplicaciones de Java. Una alternativa en Unix es crear un alias para grails - classpath..., por lo que no es necesario que escriba los argumentos adicionales cada vez.Authentication
If your repository requires authentication you can configure this using acredentials block:Autenticación
Si su repositorio requiere autenticación puede configurar esto utilizando el bloquecredentials:credentials {
realm = ".."
host = "localhost"
username = "myuser"
password = "mypass"
}This can be placed in your
Esto puede ser colocado en el archivo USER_HOME/.grails/settings.groovy file using the grails.project.ivy.authentication setting:USER_HOME/.grails/settings.groovy mediante la configuración de grails.project.ivy.authentication:grails.project.ivy.authentication = {
credentials {
realm = ".."
host = "localhost"
username = "myuser"
password = "mypass"
}
}3.7.3 Depurando la resolución de dependencias
If you are having trouble getting a dependency to resolve you can enable more verbose debugging from the underlying engine using the
Si está teniendo problemas para conseguir que una dependencia se resuelva puede habilitar un modo de depueración más detallado del motor subyacente mediante el método log method:log:// log level of Ivy resolver, either 'error', 'warn',
// 'info', 'debug' or 'verbose'
log "warn"3.7.4 Dependencias heredadas
By default every Grails application inherits several framework dependencies. This is done through the line:Inside the
De forma predeterminada cada aplicación Grails hereda varias dependencias del framework. Esto se realiza a través de la línea:inherits "global"BuildConfig.groovy file. To exclude specific inherited dependencies you use the excludes method:inherits "global"BuildConfig.groovy. Para excluir dependencias heredadas específicas usa el método excludes:inherits("global") { excludes "oscache", "ehcache" }
3.7.5 Dependencias por defecto
Most Grails applications have runtime dependencies on several jar files that are provided by the Grails framework. These include libraries like Spring, Sitemesh, Hibernate etc. When a war file is created, all of these dependencies will be included in it. But, an application may choose to exclude these jar files from the war. This is useful when the jar files will be provided by the container, as would normally be the case if multiple Grails applications are deployed to the same container.The dependency resolution DSL provides a mechanism to express that all of the default dependencies will be provided by the container. This is done by invoking the
La mayoría de las aplicaciones Grails tienen dependencias de tiempo de ejecución sobre varios archivos jar que proporcionan el framwork Grails. Estos incluyen bibliotecas como Spring, Sitemesh, Hibernate, etc… Cuando se crea un archivo war, todas estas dependencias se incluirá en él. Sin embargo, una aplicación puede excluir estos archivos jar del war. Esto es útil cuando los archivos jar serán proporcionados por el contenedor, ya que normalmente sería el caso si varias aplicaciones Grails se despliegan en el mismo contenedor.La resolución de dependencias DSL proporciona un mecanismo para expresar que todas las dependencias predeterminado serán proporcionados por el contenedor. Esto se hace invocando al método defaultDependenciesProvided method and passing true as an argument:defaultDependenciesProvided y pasando true como argumento:grails.project.dependency.resolution = { defaultDependenciesProvided true // all of the default dependencies will
// be "provided" by the container inherits "global" // inherit Grails' default dependencies repositories {
grailsHome()
…
}
dependencies {
…
}
}defaultDependenciesProvidedmust come beforeinherits, otherwise the Grails dependencies will be included in the war.
defaultDependenciesProvideddebe venir antes deinherits, de lo contrario las dependencias Grails se incluirá en el war.
3.7.6 Informes de dependencias
As mentioned in the previous section a Grails application consists of dependencies inherited from the framework, the plugins installed and the application dependencies itself.To obtain a report of an application's dependencies you can run the dependency-report command:By default this will generate reports in the
Como se menciona en la sección anterior una aplicación Grails consiste en dependencias heredadas del framwork, los plugins instalados y las dependencias de las aplicaciones en sí.Para obtener un informe de las dependencias de una aplicación puede ejecutar el comando dependency-report:grails dependency-report
target/dependency-report directory. You can specify which configuration (scope) you want a report for by passing an argument containing the configuration name:grails dependency-report
target/dependency-report. Puede especificar qué configuración (alcance) desea en un informe pasando un argumento que contiene el nombre de configuración:grails dependency-report runtime
3.7.7 Dependencias Jar de plugins
Specifying Plugin JAR dependencies
The way in which you specify dependencies for a plugin is identical to how you specify dependencies in an application. When a plugin is installed into an application the application automatically inherits the dependencies of the plugin.To define a dependency that is resolved for use with the plugin but not exported to the application then you can set theexport property of the dependency:Especificación de las dependencias JAR de un plugin
La forma en que se especifican las dependencias para un plugin es idéntica a la que permite especificar las dependencias en una aplicación. Cuando se instala un plugin en una aplicación la aplicación hereda automáticamente las dependencias del plugin.Para definir una dependencia que se resuelve para su uso con el plugin pero no se exporta a la aplicación, puede definir la propiedadexport de la dependencia:test('org.spockframework:spock-core:0.5-groovy-1.8') {
export = false
}In this case the Spock dependency will be available only to the plugin and not resolved as an application dependency. Alternatively, if you're using the Map syntax:
En este caso la dependencia Spock estará disponibles sólo para el plugin y no será resuelta como una dependencia de la aplicación. Alternativamente, si utiliza la sintaxis de mapa:test group: 'org.spockframework', name: 'spock-core',
version: '0.5-groovy-1.8', export: falseYou can useexported = falseinstead ofexport = false, but we recommend the latter because it's consistent with the Map argument.
Puede utilizarexported = falseen lugar deexport = false, pero recomendamos este último porque es coherente con el argumento de mapa.
Overriding Plugin JAR Dependencies in Your Application
If a plugin is using a JAR which conflicts with another plugin, or an application dependency then you can override how a plugin resolves its dependencies inside an application using exclusions. For example:Reemplazar las dependencias JAR de un plugin en su aplicación
Si un plugin está utilizando un JAR que crea conflictos con otro plugin, o con una dependencia de la aplicación, se puede modificar cómo un plugin resuelve sus dependencias dentro de una aplicación mediante las exclusiones. Por ejemplo:plugins {
compile(":hibernate:$grailsVersion") {
excludes "javassist"
}
}dependencies {
runtime "javassist:javassist:3.4.GA"
}In this case the application explicitly declares a dependency on the "hibernate" plugin and specifies an exclusion using the
En este caso la aplicación explícitamente declara una dependencia en el plugin de "hibernate" y especifica una exclusión utilizando el método excludes method, effectively excluding the javassist library as a dependency.
excludes, excluyendo la biblioteca de javassist como una dependencia.
3.7.8 Integración con Maven
When using the Grails Maven plugin, Grails' dependency resolution mechanics are disabled as it is assumed that you will manage dependencies with Maven's
Cuando se utiliza el plugin Grails Maven, los mecánismos de resolución de dependencias de Grails están deshabilitados porque se supone que gestionará las dependencias con el archivo de pom.xml file.However, if you would like to continue using Grails regular commands like run-app, test-app and so on then you can tell Grails' command line to load dependencies from the Maven pom.xml file instead.To do so simply add the following line to your BuildConfig.groovy:pom.xml de Maven.Sin embargo, si desea seguir utilizando los comandos Grails como run-app, test-app,etc… puede indicarle a la línea de comandos de Grails que cargue las dependencias del archivo pom.xml Maven en su lugar.Así que simplemente añada la siguiente línea a su BuildConfig.groovy :grails.project.dependency.resolution = {
pom true
..
}
The line
La línea pom true tells Grails to parse Maven's pom.xml and load dependencies from there.
pom true le dice a Grails que analice el pom.xml de Maven y cargue las dependencias desde allí.
3.7.9 Desplegando a un repositorio Maven
If you use Maven to build your Grails project, you can use the standard Maven targets
Si utiliza a Maven para construir su proyecto Grails, puede utilizar el target estándar de Maven mvn install and mvn deploy.
If not, you can deploy a Grails project or plugin to a Maven repository using the maven-publisher plugin.The plugin provides the ability to publish Grails projects and plugins to local and remote Maven repositories. There are two key additional targets added by the plugin:
- maven-install - Installs a Grails project or plugin into your local Maven cache
- maven-deploy - Deploys a Grails project or plugin to a remote Maven repository
pom.xml for you unless a pom.xml is already present in the root of the project, in which case this pom.xml file will be used.mvn install and mvn deploy.
Si no es así, puede desplegar un proyecto Grails o un plugin en un repositorio de Maven utilizando el plugin maven-publisher.El plugin permite publicar proyectos Grails y plugins en repositorios Maven locales y remotos. Hay dos target principales adicionales agregados por el plugin:
- maven-install - instala un plugin o un proyecto Grails en la caché local de Maven.
- maven-deploy - despliega un proyecto Grails o plugin para un repositorio Maven remoto.
pom.xml válido a menos que un pom.xml ya está presente en la raíz del proyecto, en cuyo caso se utilizará este archivo pom.xml.maven-install
Themaven-install command will install the Grails project or plugin artifact into your local Maven cache:grails maven-install
maven-install
El comandomaven-install instalará el proyecto o plugin Grails en la caché local de Maven:grails maven-install
maven-deploy
Themaven-deploy command will deploy a Grails project or plugin into a remote Maven repository:grails maven-deploy
<distributionManagement> configuration within a pom.xml or that you specify the id of the remote repository to deploy to:maven-deploy
El comandomaven-deploy desplegará un proyecto Grails o plugin en un repositorio de Maven remoto:grails maven-deploy
<distributionmanagement> dentro de un pom.xml o que especifica el id del repositorio remoto en el que desplegar:grails maven-deploy --repository=myRepo
The
El argumento repository argument specifies the 'id' for the repository. Configure the details of the repository specified by this 'id' within your grails-app/conf/BuildConfig.groovy file or in your $USER_HOME/.grails/settings.groovy file:repository especifica el 'id' para el repositorio. Configure los detalles del repositorio especificado por este 'id' en el archivo grails-app/conf/BuildConfig.groovy o en el archivo $USER_HOME/.grails/settings.groovy:grails.project.dependency.distribution = {
localRepository = "/path/to/my/local"
remoteRepository(id: "myRepo", url: "http://myserver/path/to/repo")
}The syntax for configuring remote repositories matches the syntax from the remoteRepository element in the Ant Maven tasks. For example the following XML:
La sintaxis para configurar repositorios remotos coincide con la sintaxis del elemento remoteRepository en las tareas Ant Maven. Por ejemplo, el siguiente XML:<remoteRepository id="myRepo" url="scp://localhost/www/repository"> <authentication username="..." privateKey="${user.home}/.ssh/id_dsa"/> </remoteRepository>
Can be expressed as:
Puede ser expresada como:remoteRepository(id: "myRepo", url: "scp://localhost/www/repository") { authentication username: "...", privateKey: "${userHome}/.ssh/id_dsa" }
By default the plugin will try to detect the protocol to use from the URL of the repository (ie "http" from "http://.." etc.), however to specify a different protocol you can do:
De forma predeterminada el plugin intentará detectar el protocolo a usar desde la URL del repositorio (es decir "http" desde "http://..." etc.), sin embargo para especificar otro protocolo puede hacer:grails maven-deploy --repository=myRepo --protocol=webdav
The available protocols are:
Los protocolos disponibles son:
- http
- scp
- scpexe
- ftp
- webdav
- http
- scp
- scpexe
- ftp
- webdav
Groups, Artifacts and Versions
Maven defines the notion of a 'groupId', 'artifactId' and a 'version'. This plugin pulls this information from the Grails project conventions or plugin descriptor.Versiones, artefactos y grupos
Maven define la noción de 'IdGrupo', 'artifactId' y 'versión'. Este plugin extrae esta información de los convenciones de proyecto Grails o del descriptor del plugin.Projects
For applications this plugin will use the Grails application name and version provided by Grails when generating thepom.xml file. To change the version you can run the set-version command:Proyectos
Para las aplicaciones de este plugin utilizará el nombre de la aplicación de Grails y la versión proporcionada por Grails al generar el archivopom.xml. Para cambiar la versión puede ejecutar el comando set-version:grails set-version 0.2
The Maven
El groupId will be the same as the project name, unless you specify a different one in Config.groovy:groupId de Maven será el mismo que el nombre del proyecto, a menos que se especifique otro diferente en Config.groovy:grails.project.groupId="com.mycompany"Plugins
With a Grails plugin thegroupId and version are taken from the following properties in the GrailsPlugin.groovy descriptor:Plugins
Con un plugin de Grails elgroupId y version proceden de las siguientes propiedades en el descriptor de GrailsPlugin.groovy:String groupId = 'myOrg' String version = '0.1'
The 'artifactId' is taken from the plugin name. For example if you have a plugin called
El 'artifactId' se toma del nombre del plugin. Por ejemplo, si tienes un plugin llamado FeedsGrailsPlugin the artifactId will be "feeds". If your plugin does not specify a groupId then this defaults to "org.grails.plugins".FeedsGrailsPlugin el artifactId será "feeds". Si tu plugin no especifica el groupId entonces por defecto utiliza "org.grails.plugins".
3.7.10 Dependencias de plugin
As of Grails 1.3 you can declaratively specify plugins as dependencies via the dependency DSL instead of using the install-plugin command:
Como en Grails 1.3 puede especificar los plugins declarandolos como dependencias a través de la dependencia DSL en lugar de utilizar el comando install-plugin:grails.project.dependency.resolution = {
…
repositories {
…
} plugins {
runtime ':hibernate:1.2.1'
} dependencies {
…
}
…
}If you don't specify a group id the default plugin group id of
Si no especifica un id de grupo se utiliza el id de grupo del plugin predeterminado de org.grails.plugins is used. You can specify to use the latest version of a particular plugin by using "latest.integration" as the version number:org.grails.plugins. Se puede especificar el uso de la versión más reciente de un plugin determinado mediante "latest.integration" como el número de versión:plugins {
runtime ':hibernate:latest.integration'
}Integration vs. Release
The "latest.integration" version label will also include resolving snapshot versions. To not include snapshot versions then use the "latest.release" label:Integration vs. Release
La etiqueta de versión "latest.integration" también incluirá resolver versiones snapshot. Para no incluir versiones snapshot utilice la etiqueta "latest.release":plugins {
runtime ':hibernate:latest.release'
}The "latest.release" label only works with Maven compatible repositories. If you have a regular SVN-based Grails repository then you should use "latest.integration".And of course if you use a Maven repository with an alternative group id you can specify a group id:
La etiqueta de "latest.release" sólo funciona con repositorios compatibles con Maven. Si tienes un repositorio basado en SVN Grails debe utilizar "latest.integration".Y por supuesto si utiliza un repositorio Maven con un id de grupo alternativo puede especificar un id de grupo:
plugins {
runtime 'mycompany:hibernate:latest.integration'
}Plugin Exclusions
You can control how plugins transitively resolves both plugin and JAR dependencies using exclusions. For example:Exclusiones de plugin
Puede controlar cómo los plugins resuelven transitoriamente tanto las dependencias de plugin como de JAR usando las exclusiones. Por ejemplo:plugins {
runtime(':weceem:0.8') {
excludes "searchable"
}
}Here we have defined a dependency on the "weceem" plugin which transitively depends on the "searchable" plugin. By using the
Aquí hemos definido una dependencia en el plugin "weceem" que transitoriamente depende el plugin "searchable". Mediante el uso del método excludes method you can tell Grails not to transitively install the searchable plugin. You can combine this technique to specify an alternative version of a plugin:excludes puede decirle a Grails que NO resuelva transitoriamente el plugin para búsquedas. Puede combinar esta técnica para especificar una versión alternativa de un plugin:plugins {
runtime(':weceem:0.8') {
excludes "searchable" // excludes most recent version
}
runtime ':searchable:0.5.4' // specifies a fixed searchable version
}You can also completely disable transitive plugin installs, in which case no transitive dependencies will be resolved:
Puede deshabilitar también completamente la instalación transitiva de plugins, en cuyo caso se resolverán las dependencias no transitivas:plugins {
runtime(':weceem:0.8') {
transitive = false
}
runtime ':searchable:0.5.4' // specifies a fixed searchable version
}
