gradle cargo plugin
1.0.0
| En los últimos años, este complemento ha visto muchos lanzamientos. ¡Gracias a todos los involucrados! Desafortunadamente, ya no tengo mucho tiempo para contribuir. En la práctica, esto significa mucha menos actividad, capacidad de respuesta en problemas y nuevos lanzamientos de mi parte. |
| Estoy buscando activamente contribuyentes dispuestos a asumir el mantenimiento y la implementación del proyecto. Si está interesado y me encantaría ver que este complemento continúe prosperando, envíeme un correo. |
El complemento proporciona capacidades de implementación para aplicaciones web a contenedores locales y remotos en cualquier construcción de Gradle dada aprovechando las tareas de carga de carga. El complemento admite artefactos de guerra y oído.
El caso de uso típico para este complemento es admitir la implementación durante el desarrollo. Tenga en cuenta que la carga utiliza la implementación en caliente que con el tiempo llena la memoria Permgen del proceso JVM que ejecuta su contenedor. Implementar continuamente un artefacto inevitable conducirá a un java.lang.OutOfMemoryError . La carga admite capacidades de gestión de contenedores (inicio/detención de contenedores remotos) a través del llamado demonio de carga. Sin embargo, en los escenarios de implementación continua, a menudo desea necesitar realizar operaciones más complejas.
Para usar la funcionalidad del complemento, deberá agregar el artefacto binario ITS al classpath de su script de compilación y aplicar el complemento.
El jar del complemento debe definirse en la classpath de su script de compilación. Está disponible en el portal del complemento de Gradle. El siguiente fragmento de código muestra un ejemplo sobre cómo recuperarlo con la sintaxis buildscript :
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.bmuschko:gradle-cargo-plugin:2.9.0'
}
}
El archivo jar viene con dos complementos:
| Identificador de complemento | Depende de | Tipo | Descripción |
|---|---|---|---|
| com.bmuschko.cargo-base | - | Cargobaseplugin | Proporciona tipos de tareas personalizadas de carga, classpath previa a las configuras y desplegables. |
| com.bmuschko.cargo | com.bmuschko.cargo-base | Cargoplugin | Proporciona un conjunto de tareas de carga locales y remotas y expone la extensión para la configuración. |
El complemento com.bmuschko.cargo lo ayuda a comenzar rápidamente. Si solo necesita tratar con un solo producto de contenedor, esta es la opción preferible. La mayoría de los usuarios de complementos irán con esta opción. Para usar el complemento de carga, incluya el siguiente fragmento de código en su script de compilación:
apply plugin: 'com.bmuschko.cargo'
Si necesita control total sobre sus tareas de implementación, querrá usar el complemento com.bmuschko.cargo-base . La desventaja es que cada tarea debe configurarse individualmente en su script de compilación. Para usar el complemento de la base de carga, incluya el siguiente fragmento de código en su script de compilación:
apply plugin: 'com.bmuschko.cargo-base'
El complemento com.bmuschko.cargo-base ya establece las dependencias para la carga. Para hacerlo, elige una versión predeterminada de las bibliotecas. Alternativamente, puede definir una versión personalizada de las bibliotecas de carga. Para hacerlo, utilice el nombre de configuración cargo en el cierre de su dependencies y tenga en cuenta lo siguiente:
dependencies {
def cargoVersion = '1.9.10'
cargo "org.codehaus.cargo:cargo-core-uberjar:$cargoVersion",
"org.codehaus.cargo:cargo-licensed-dtds:$cargoVersion",
"org.codehaus.cargo:cargo-ant:$cargoVersion"
}
El complemento cargo predefine las siguientes tareas fuera de la caja:
| Nombre de la tarea | Depende de | Tipo | Descripción |
|---|---|---|---|
| cargodeployremote | - | Cargodeployremote | Implementa una implementación de un contenedor remoto. |
| cargoundeployremote | - | Cargoundeployremote | Desbloys un despliegue desde un contenedor remoto. |
| cargoredeployremote | - | Cargoredeployremote | Redexoras un contenedor desplegable al contenedor remoto. |
| cargorunlocal | - | Cargorunlocal | Inicia el contenedor local, implementa un desplegable y espera a que el usuario presione CTRL + C para detener. |
| cargastartlocal | - | Cargastartlocal | Inicia el contenedor local, implementa un desplegable y luego realiza otras tareas (por ejemplo, ejecutar pruebas). |
| cargoredeploilocal | - | Cargoredeploilocal | Redextando un desplegable en un contenedor local. |
| cargaloplocal | - | Cargaloplocal | Detiene el contenedor local. |
| cargoconfigurelocal | - | Cargoconfigurelocal | Configura el contenedor local. |
El complemento de carga utiliza el mismo diseño que el complemento de guerra.
El complemento de carga define las siguientes propiedades de la convención en el cierre cargo :
containerId : la identificación del contenedor a la que está dirigido. Consulte la lista de contenedores compatibles en el sitio web de carga.port : el puerto TCP en el que responde el contenedor (predeterminados a 8080). Dentro de cargo , puede definir propiedades opcionales para los artefactos de implementación de 1..N en un cierre llamado deployable . Cada artefacto de implementación se especificaría en su propio cierre:
file : Cualquier tipo que se pueda pasar a Project.files (Object ...) y se resuelve en un solo archivo o un directorio que incluye artefactos arbitrarios, directorios de guerra explotados y configuraciones de dependencia que se implementarán en el contenedor (valores predeterminados en proyectos/artefactos de módulo - guerra o archivo de oído).context : el contexto de URL en el que el contenedor está manejando su aplicación web (vale el valor predeterminado al nombre de la guerra/oído). Tenga en cuenta que no tiene que definir el cierre deployable si solo desea implementar el artefacto definido por su proyecto/módulo de Gradle.
Dentro de cargo , puede definir propiedades para contenedores remotos en un cierre llamado remote :
protocol : el protocolo del contenedor remoto (predeterminado es http ).hostname : el nombre de host del contenedor remoto.username : la credencial de nombre de usuario para el contenedor remoto (opcional).password : la credencial de contraseña para el contenedor remoto (opcional). Dentro de cargo , puede definir propiedades para contenedores locales en un cierre llamado local :
jvmArgs : Los argumentos JVM para un contenedor local.outputFile : el archivo de registro de su contenedor local (predeterminado se escribe en la consola).logFile : el archivo de registro de carga de su contenedor local (predeterminado se escribe en la consola).logLevel : el nivel de registro para ejecutar el contenedor con (opcional). Los niveles válidos son low , medium y high .homeDir : el directorio de inicio de la instalación de su contenedor local.configHomeDir : el directorio de inicio de la configuración de su contenedor local.configFile : los archivos de configuración que desea agregar a la configuración de su contenedor. configFile es un cierre en sí y requiere que proporcione los files de atributos y toDir . Se debe usar una FileCollection como atributo files y toDir debe ser una String . Se pueden definir múltiples destinos de archivo de configuración creando más de un cierre configFile .rmiPort : el puerto para usar cuando se comunica con este servidor, por ejemplo, para iniciarlo y detenerlo.startStopTimeout : el tiempo de espera (en MS) para determinar si el contenedor se inicia o se detiene con éxito (el valor predeterminado a 120000 ms).extraClasspath : una FileCollection que proporciona elementos adicionales al contenedor local classpath (opcional).sharedClasspath : una FileCollection que proporciona elementos adicionales a la clasificación de solicitud, y no al contenedor local (opcional). Dentro de local y remote , puede definir propiedades específicas del contenedor. Estas propiedades se pueden buscar en la página de inicio de la carga. El siguiente ejemplo muestra cómo establecer el puerto AJP para un contenedor Tomcat local:
cargo {
local {
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Los contenedores locales pueden usar las propiedades del sistema que se le pasan. El siguiente ejemplo muestra cómo establecer una propiedad de sistema único llamado myproperty :
cargo {
local {
systemProperties {
property 'myproperty', 'myvalue'
}
}
}
Si decide usar la carga del instalador ZIP, descargará automáticamente su contenedor. Puede definir sus propiedades en el installer de cierre. El instalador solo se aplica a tareas de carga "locales".
installUrl : la URL para descargar la distribución del contenedor.downloadDir : Directorio de destino para descargar la distribución del contenedor.extractDir : directorio para extraer la distribución de contenedores descargados.Consulte las propiedades de configuración individuales en la página de inicio de la carga. Todas estas propiedades pueden ser anuladas por las propiedades del proyecto. El nombre de las propiedades del proyecto es el mismo que en el manual de carga.
Si desea beneficiarse de la caché de dependencia de Gradle al resolver distribuciones de contenedores, puede usar una configuración en lugar de una URL al configurar el instalador:
configurations {
tomcat
}
dependencies {
tomcat "org.apache.tomcat:tomcat:9.0.14@zip"
}
cargo {
local {
installer {
installConfiguration = configurations.tomcat
}
}
}
cargo {
containerId = 'tomcat6x'
port = 9090
deployable {
context = 'myawesomewebapp'
}
remote {
hostname = 'cloud.internal.it'
username = 'superuser'
password = 'secretpwd'
}
local {
homeDir = file('/home/user/dev/tools/apache-tomcat-6.0.32')
outputFile = file('build/output.log')
startStopTimeout = 60000
containerProperties {
property 'cargo.tomcat.ajp.port', 9099
}
}
}
Quiero reunir automáticamente el artefacto de mi proyecto al ejecutar una tarea de implementación de carga.
La tarea cargoRunLocal no depende automáticamente de la tarea assemble . La razón detrás de eso es que es posible que no desee implementar el artefacto de su proyecto o su proyecto no genera un archivo de guerra o oído. En su lugar, es posible que desee implementar uno o más artefactos externos. Si su flujo de trabajo parece "compilar el código", "generar el artefacto" y "implementar", entonces hace que una tarea de implementación de carga dependa de la tarea assemble . Aquí hay un ejemplo:
cargoRunLocal.dependsOn assemble
Estoy trabajando en una construcción de proyectos múltiples. ¿Puedo aplicar la misma configuración de carga a todos mis proyectos web?
Gradle permite filtrar subproyectos por ciertos criterios. Para inyectar la configuración relevante del proyecto raíz de su compilación, deberá identificar todos los subproyectos que apliquen el complemento de guerra (por supuesto, el mismo concepto funciona para proyectos EAR). Use el método configure para aplicar el complemento de carga y su configuración como se muestra en el siguiente fragmento de código:
def webProjects() {
subprojects.findAll { subproject -> subproject.plugins.hasPlugin('war') }
}
gradle.projectsEvaluated {
configure(webProjects()) {
apply plugin: 'com.bmuschko.cargo'
cargo {
containerId = 'tomcat7x'
remote {
hostname = 'localhost'
username = 'manager'
password = 'manager'
}
}
}
}
Me gustaría implementar múltiples artefactos en mi contenedor. ¿Cómo hago eso?
Especificaría cada artefacto en un cierre deployable separado. Cada uno de los cierres debe asignar un contexto de URL único. El siguiente ejemplo demuestra cómo una configuración de carga con tres artefactos diferentes desplegados en un Tomcat local:
cargo {
containerId = 'tomcat6x'
port = 9090
deployable {
file = file('/home/foo/bar/web-services.war')
context = 'web-services'
}
deployable {
file = file('/home/foo/bar/web-app.war')
context = 'web-app'
}
deployable {
file = file('/home/foo/bar/enterprise-app.ear')
context = 'enterprise-app'
}
local {
homeDir = file('/home/user/dev/tools/apache-tomcat-6.0.32')
}
}
¿Hay alguna manera de dejar que la carga instale automáticamente el contenedor que me gustaría usar?
La carga permite definir un contenedor que se descarga e instale automáticamente en su disco local. Todo lo que necesita hacer es especificar el cierre installer . El siguiente código de fragmento descarga, instala y usa Tomcat 7:
cargo {
containerId = 'tomcat7x'
local {
installer {
installUrl = 'http://apache.osuosl.org/tomcat/tomcat-7/v7.0.27/bin/apache-tomcat-7.0.27.zip'
downloadDir = file("$buildDir/download")
extractDir = file("$buildDir/extract")
}
}
}
Me gustaría agregar un archivo de configuración a mi contenedor local. ¿Cómo hago eso?
Para los contenedores locales se puede usar un cierre llamado configFile que define los archivos de origen y el directorio que desea usar el archivo desde el tiempo de ejecución. Si necesita copiar archivos en más de un destinos, simplemente cree múltiples cierres configFile .
cargo {
containerId = 'jboss5x'
local {
configFile {
files = project.files('src/main/jboss5/login-config.xml')
toDir = 'conf'
}
configFile {
files = project.files('src/main/jboss5/login-config.xml', 'src/main/jboss5/sample-users.properties')
toDir = 'conf/props'
}
}
}
Para agregar archivos binarios, debe usar el cierre (s) file en su lugar:
cargo {
containerId = 'glassfish3x'
local {
file {
file = file('../config/db/mysql-connector-java-5.1.23-bin.jar')
toDir = 'lib'
}
}
}
Quiero configurar y configurar mi propia tarea de carga para más de un contenedor. ¿Se puede hacer esto?
Absolutamente. El complemento de la base de carga proporciona todas las tareas necesarias para configurar tareas de implementación. Todo lo que necesita hacer es crear una o más tareas y configurar las propiedades obligatorias. El siguiente ejemplo muestra cómo configurar tareas de contenedores locales para Tomcat y Jetty:
apply plugin: 'com.bmuschko.cargo-base'
task myTomcatRun(type: com.bmuschko.gradle.cargo.tasks.local.CargoRunLocal) {
containerId = 'tomcat7x'
homeDir = file('/home/user/dev/tools/apache-tomcat-7.0.42')
}
task myJettyRun(type: com.bmuschko.gradle.cargo.tasks.local.CargoRunLocal) {
containerId = 'jetty9x'
homeDir = file('/home/user/dev/tools/jetty-distribution-9.0.4.v20130625')
}
Me gustaría crear tareas de implementación para una implementación continua en múltiples contenedores remotos. ¿Cómo hago esto?
Gradle permite crear dinámicamente tareas basadas en su lógica de secuencia de comandos de compilación. El siguiente ejemplo muestra cómo crear tres tareas de implementación de Tomcat y cómo configurarlas con la ayuda de una estructura de datos simple. Al final del script, también agregamos otra tarea que desencadena la implementación a todos los contenedores remotos.
class RemoteContainer {
String name
String hostname
Integer port
String username
String password
}
def remoteContainers = [new RemoteContainer(name: 'tomcat1', hostname: 'remote-tomcat1',
port: 9090, username: 'admin', password: 's3cr3t'),
new RemoteContainer(name: 'tomcat2', hostname: 'remote-tomcat2',
port: 8050, username: 'deployer', password: 'qwerty'),
new RemoteContainer(name: 'tomcat3', hostname: 'remote-tomcat3',
port: 8888, username: 'su', password: 'powerful')]
apply plugin: 'com.bmuschko.cargo-base'
remoteContainers.each { config ->
task "deployRemote${config.name.capitalize()}"(type: com.bmuschko.gradle.cargo.tasks.remote.CargoDeployRemote) {
description = "Deploys WAR to remote Tomcat '${config.name}'."
containerId = 'tomcat7x'
hostname = config.hostname
port = config.port
username = config.username
password = config.password
}
}
task deployToAllRemoteTomcats {
dependsOn remoteContainers.collect { "deployRemote${it.name.capitalize()}" }
description = 'Deploys to all remote Tomcat containers.'
group = 'deployment'
}
Antes de una implementación remota, me gustaría reiniciar mi contenedor. ¿Se puede hacer esto?
Sí, esto es posible con la ayuda de la funcionalidad de Daemon de carga. Consulte la documentación en línea de carga para configurar el proceso de Cargo Daemon JVM y configurar un contenedor. Con este complemento, puede usar tareas personalizadas para iniciar y detener un contenedor. El siguiente ejemplo se detiene, comienza y luego se vuelve a colocar un artefacto.
apply plugin: 'com.bmuschko.cargo'
cargo {
...
}
ext.tomcat7HandleId = 'tomcat7'
task cargoDaemonStop(type: com.bmuschko.gradle.cargo.tasks.daemon.CargoDaemonStop) {
handleId = tomcat7HandleId
}
task cargoDaemonStart(type: com.bmuschko.gradle.cargo.tasks.daemon.CargoDaemonStart) {
handleId = tomcat7HandleId
}
cargoDaemonStart.mustRunAfter cargoDaemonStop
cargoRedeployRemote.dependsOn cargoDaemonStop, cargoDaemonStart
