plugin dependency configurations gradle dependencies project ear libs

dependency - gradle maven publish



Gradle EAR con transitive libs de otros proyectos (2)

Encontré la solución yo mismo ... después de probar muchas, muchas "soluciones" de otras publicaciones. Esto es lo que hice, y es una combinación de otros:

En el PROYECTO CORE

Creé una configuración proporcionada, por lo que estas dependencias no aparecerán en la configuración de compilación, y la agregué al classpath del proyecto. ¡Entonces están en el classpath de compilación pero no en la configuración de compilación! Lo hice para todos mis proyectos.

// Libs need for compilation, but not to be published with EAR configurations { provided } dependencies { provided ''javax:javaee-api:6.0'' provided ''org.slf4j:slf4j-api:1.7.7'' compile ''com.application:application-common:1.4.5-SNAPSHOT'' } configurations.provided.each { logger.debug("PROVIDED::core: $it/n") } // Include the PROVIDED libs into compile classpath sourceSets { main { compileClasspath += configurations.provided } }

En el PROYECTO EAR

Tuve que incluir "implementar proyecto ..." para la entrada del módulo y el jar raíz. Para las bibliotecas transitivas utilicé el "proyecto earlib ... configuración: ''compilar''" para asegurar que solo los archivos que están dentro de la configuración de compilación (y por lo tanto son obligatorios para ejecutar el contenedor) se copian en el oído.

apply plugin: ''ear'' dependencies { // INCLUDE AS A MODULE with entry in application.xml deploy project(path: '':core'') // INCLUDE the TRANSITIVE LIBRARIES FOR RUNTIME not provided earlib project(path: '':core'', configuration: ''compile'') } ear { .... }

¡Eso es todo!

Para esto tengo que decir ... GRADLE ROCKS !!!!

Un script de compilación de Gradle crea un archivo EAR con algunas jarras y una guerra adentro. Todo esto se hizo antes en Maven y ahora es un tema de migración a Gradle.

ENV:

  • Gradle 1.12
  • Groovy 2.2.1
  • Java 1.7.0_60 Oracle
  • Eclipse Kepler SR 2

Problema:

... es simple: funciona hasta ahora: el complemento para el oído crea el archivo ear con todos los archivos del módulo incluidos desde

deploy project(:core)

dentro de la sección "dependencias" y el "core-0.0.1.jar" está en la raíz del oído y se ha creado una entrada en el módulo en la aplicación.xml. Ahora descubrí que las bibliotecas de tiempo de ejecución no están incluidas en el archivo ear. Entonces cambié (según docu) la inclusión a

earlib project(:core)

y encontró las libs dentro del directorio libs como se indica en la propiedad "libDirName" de la configuración del complemento ear. Pero ahora no hay entrada de módulo dentro de la aplicación.xml Y el "core-0.0.1.jar" está dentro del directorio libs.

Deseado

Queremos core-0.0.1.jar como un módulo dentro de la raíz de oído y todas las bibliotecas de tiempo de ejecución dentro del directorio libs, SIN el contenedor del módulo mismo. (core-0.0.1.jar no es una guerra!) Como que ...

[APP.EAR] |--/libs | |-- log4j.jar | |-- commons.jar | |>> app-core.0.0.1.jar <<== NOT ! | |-app-core-0.0.1.jar <== OK! |-app-xy-0.0.1.jar |-app-abc-0.0.1.war

Pregunta

¿Es esta una falta fundamental de comprensión de los conceptos de EAR de mi lado o por qué Gradle por sí mismo no se comporta de la manera que queremos? ¿O podría este paso pequeño y fácil requerir una configuración más compleja?


La solución aceptada falla si hay dependencias de tiempo de compilación entre los módulos ear. Así es como lo resolví en Gradle 2.14. Espero que esto ayude a alguien.

apply plugin: ''ear'' def deployedModules = [ ''projectA'', ''projectB'', ''projectC'' ] deployedModules.forEach { def projectPath = ":${it}" evaluationDependsOn(projectPath) dependencies.add(''deploy'', dependencies.project(path: projectPath, configuration: ''archives'')) findProject(projectPath).configurations.runtime.allDependencies.forEach { boolean isEarModule = it instanceof ProjectDependency && (it as ProjectDependency).dependencyProject.name in deployedModules if (!isEarModule) { dependencies.add(''earlib'', it) } } }