java - traduccion - manifiesta la primera construcción OSGi con gradle-migrando de ant a Gradle
gradle tutorial español (2)
¿Hay un manifiesto primero http://wiki.osgi.org/wiki/Tooling_Approaches gradle plugin para OSGi? ¿O cómo hacerlo con gradle?
Hay un gran proyecto antiguo para el contenedor OSGi con muchos proyectos que tienen una relación complicada declarada en MANIFEST.MF. La construcción es larga. Ahora queremos simplificar las cosas y adoptar Gradle. Pero primero sin romper las cosas y manteniendo las construcciones hormiga y gradle en paralelo durante algún tiempo. Sin embargo, lo que veo es que Gradle sugiere definir MANIFEST dentro de build.gradle . https://docs.gradle.org/current/userguide/osgi_plugin.html
Eso haría mucho trabajo de copia.
ACTUALIZACIÓN Hay cerca de 100 módulos con una gran cantidad de información de dependencias entre los módulos y para el tarro anidado. En promedio, la longitud de MANIFEST.MF es de aproximadamente 50 líneas (varía de 20 a 300 líneas). Cómo empaquetar tarros anidados es otra pregunta . Esta pregunta es sobre el uso de archivos MANIFEST.MF existentes. Todos los complementos que vi utilizaron bnd que es exactamente contrario al primer enfoque manifiesto.
A partir de abril de 2016 no hay un enfoque de Manifest-first en las herramientas de construcción Maven o Gradle para OSGi.
Si bien para los complementos de Eclipse (que también son paquetes OSGi válidos) hay una compilación de maven / tycho , que es estándar en Eclipse Foundation, no es realmente una ayuda para los proyectos generales de OSGi.
Oposite to Manifest-first es la generación Manifest, y solo hay una herramienta bnd , que inicialmente fue para la creación de manifiestos, luego se convirtió en un generador de paquetes completos y ahora cuenta con la integración de BndTools Eclipse , que se parece a la integración de Maven / Gradle y la gestión de las dependencias.
Recomendaría mantener las instrucciones bnd en el archivo bnd.bnd estándar externo y no colocarlo dentro del script de compilación. *.bnd archivos *.bnd son similares a los archivos .properties Java habituales, por lo que en Eclipse IDE, haga clic con el botón derecho, Abrir con -> Otro ... seleccione Properties File Editor marque "Usar este editor para ..." y marque "Usar este editor para todos ''* .nbd'' archivos "
Para gradle
- [Gradle OSGi Plugin] (estándar, incorporado) ( https://docs.gradle.org/current/userguide/osgi_plugin.html ) proporciona solo manipulación manifiesta, por lo que GRADLE-1107 "Instrucción OSGi
Include-Resourcenot working" es edición abierta desde 2010 - Gradle Bundle Plugin te permite crear paquetes OSGI. Su principal diferencia con el complemento OSGI de Gradle es que utiliza la herramienta bnd para generar no solo un manifiesto, sino todo un tarro.
-
osgi-run"Osgi-Run - Un plugin de Gradle para hacer que el desarrollo de aplicaciones modulares utilizando OSGi sea completamente indoloro"
Para el experto
-
maven-bundle-pluginpaquete de Maven también conocido como Apache Felix Maven Bundle Plugin (BND) es el enfoque "primero de Maven" -
bnd-maven-pluginy comparación de 2 plugins
Todas las herramientas basadas en bnd ahora se collected en http://bnd.bndtools.org/chapters/700-tools.html
Hay algunos ejemplos en https://github.com/paulvi/OSGiBuildExamples
Nota: el enlace http://wiki.osgi.org/wiki/Tooling_Approaches ha estado en "El Wiki de la Comunidad OSGi desafortunadamente fue pirateado y actualmente no está disponible". Estado durante más de una semana, mientras esta pregunta estaba abierta.
Lamentablemente, @Richard se rindió demasiado pronto para recibir también un agradecimiento (por mencionar a Maven)
Gradle tiene una clase OsgiManifest , que es un manifiesto de tarro extendido:
https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/osgi/OsgiManifest.html
Hay una publicación en que muestra un uso similar:
¿Cómo agregar instrucciones de Import-Package para dependencias de tiempo de ejecución?
El bloque de gradle relevante se ve así:
apply plugin: ''java''
apply plugin: ''osgi''
jar {
baseName = ''awesome''
manifest {
name = ''An Awesome Application''
symbolicName = ''com.example.awesome''
instruction ''Import-Package'', ''org.springframework.orm'', ''*''
}
}
Si tiene manifiestos existentes y desea usar sus propios archivos personalizados, puede hacerlo configurando la ubicación del archivo de manifiesto dentro del cierre del archivo jar:
jar {
manifest {
def manif = "${resourcesDir}/MANIFEST.MF"
if (new File(manif).exists()) {
from file(manif)
}
else{
name = ''overwrittenSpecialOsgiName''
instruction ''Private-Package'', ''org.mycomp.somepackage''
instruction ''Bundle-Vendor'', ''MyCompany''
instruction ''Bundle-Description'', ''Platform2: Metrics''
}
}
}
La documentación para el manifiesto de Gradle se puede encontrar aquí: https://docs.gradle.org/current/javadoc/org/gradle/api/java/archives/Manifest.html
Para su ''otra pregunta'':
Hay complementos de Gradle adicionales para crear paquetes OSGI, en algunos casos, incluidas dependencias de otros paquetes OSGI.
Por ejemplo, existe el complemento Gradle Bundle , que utiliza la herramienta bnd y le permite especificar que incluya dependencias transitivas e incluso excluir las no deseadas. Como ejemplo:
jar {
manifest {
attributes ''Implementation-Title'': ''Bundle Quickstart'', // Will be added to manifest
''Import-Package'': ''*'' // Will be overwritten by the instuctions below
}
}
bundle {
includeTransitiveDependencies = true
instructions << [
''Bundle-Activator'': ''foo.bar.MyBundleActivator'',
''Import-Package'': ''foo.*'',
''-sources'': true
]
instruction ''Export-Package'', ''*'' // Specify an individual instruction
instruction ''-wab'', ''''
}
También está el complemento de ejecución osgi de Gradle , que incluye dependencias transitivas de forma predeterminada:
dependencies {
// all your usual dependencies
...
osgiRuntime( "your:dependency:1.0" ) {
transitive = false // transitive dependencies not included in OSGi runtime
}
}
Esperemos que sea suficiente para que te pongas en marcha.