Eclipse plugin package guidelines (Español)
32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel modules – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust - Security – Shell – VCS – Web – Wine
Hay muchas formas de instalar complementos de trabajo Eclipse (Español), especialmente desde la introducción del directorio dropins en Eclipse 3.4, pero algunos de ellos son desordenados, y tener una forma de empaquetado estandarizada y consistente es muy importante para llevar a una estructura de sistema limpia. Sin embargo, no es fácil lograr esto sin que el empaquetador sepa cada detalle sobre cómo funcionan los complementos de Eclipse. Esta página tiene como objetivo definir una estructura estándar y simple para el complemento Eclipse PKGBUILDs, de modo que la estructura del sistema de archivos pueda permanecer consistente entre todos los complementos sin tener que empacar nuevamente el paquete para cada nuevo paquete.
Estructura e instalación de complementos de eclipse
El complemento típico de Eclipse contiene dos directorios, características y complementos, y desde Eclipse 3.3 solo se pueden colocar en /usr/lib/eclipse/. El contenido de estos dos directorios podría mezclarse con el de otros complementos, lo que creó un desorden y dificultó la administración de la estructura. También fue muy difícil saber de un vistazo qué paquete contenía qué archivo.
Este método de instalación aún es compatible con Eclipse 3.4, pero el preferido ahora es usando el directorio/usr/lib/eclipse/dropins/. Dentro de este directorio pueden haber un número ilimitado de subdirectorios, cada uno con sus propias características y complementos. Esto permite mantener una estructura ordenada y limpia, y debe ser el método de empaquetado estándar.
Empaquetado
Muestra de PKGBUILD
Aquí hay un ejemplo, detallaremos cómo personalizarlo a continuación.
PKGBUILD-eclipse.proto
pkgname=eclipse-mylyn
pkgver=3.0.3
pkgrel=1
pkgdesc="A task-focused interface for Eclipse"
arch=('any')
url="https://eclipse.org/mylyn/"
license=('EPL')
depends=('eclipse')
optdepends=('bugzilla: ticketing support')
source=(https://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip)
sha512sums=('aa6289046df4c254567010b30706cc9cb0a1355e9634adcb2052127030d2640f399caf20fce10e8b4fab5885da29057ab9117af42472bcc1645dcf9881f84236')
prepare() {
# remove features and plug-ins containing sources
rm -f features/*.source_*
rm -f plugins/*.source_*
# remove gz files
rm -f plugins/*.pack.gz
}
package() {
_dest="${pkgdir}/usr/lib/eclipse/dropins/${pkgname/eclipse-}/eclipse"
# Features
find features -type f | while read -r _feature ; do
if [[ "${_feature}" =~ (.*\.jar$) ]] ; then
install -dm755 "${_dest}/${_feature%*.jar}"
cd "${_dest}/${_feature/.jar}"
# extract features (otherwise they are not visible in about dialog)
jar xf "${srcdir}/${_feature}" || return 1
else
install -Dm644 "${_feature}" "${_dest}/${_feature}"
fi
done
# Plugins
find plugins -type f | while read -r _plugin ; do
install -Dm644 "${_plugin}" "${_dest}/${_plugin}"
done
}
Cómo personalizar la construcción
La principal variable que necesita ser personalizada es la pkgname. Si está empaquetando un complemento típico, entonces esto es lo único que debe hacer: la mayoría de los complementos se distribuyen en archivos zip que solo contienen dos subdirectorios features y plugins. Entonces, si está empaquetando el complemento foo y el archivo de origen solo contiene features y plugins, solo necesita cambiar pkgname a eclipse-foo y ya está configurado.
Siga leyendo para acceder a las partes internas de PKGBUILD, que ayudan a entender cómo configurar la compilación para todos los demás casos.
Revisión en profundidad de PKGBUILD
Nombre del paquete
Los paquetes deben llamarse eclipse-pluginname, para que sean reconocibles como paquetes relacionados con Eclipse y sea fácil extraer el nombre del complemento con una simple sustitución de intérprete de órdenes como ${pkgname/eclipse-}, sin tener que recurrir a una variable ${_realname} innecesaria. El nombre del complemento es necesario para ordenar todo durante la instalación y evitar conflictos.
Archivos
Extracción
Algunos complementos necesitan las características para ser extraídos de los archivos jar. La utilidad jar, ya incluida en el JRE, se usa para hacer esto. Sin embargo, jar no puede extraer directorios que no sean el actual: esto significa que, después de cada creación de directorio, es necesario cd dentro de él antes de extraer. La variable ${_dest} se utiliza en este contexto para mejorar la legibilidad y el orden de PKGBUILD.
Ubicaciones
Como dijimos, los archivos de origen proporcionan dos directorios, características y complementos, cada uno empaquetado con archivos jar. La estructura de dropins preferida debe verse así:
/usr/lib/eclipse/dropins/pluginname/eclipse/features/feature1/... /usr/lib/eclipse/dropins/pluginname/eclipse/features/feature2/... /usr/lib/eclipse/dropins/pluginname/eclipse/plugins/plugin1.jar /usr/lib/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar
Esta estructura permite mezclar diferentes versiones de bibliotecas que pueden ser necesarias por diferentes complementos y tener claro qué paquete posee qué. También evitará conflictos en caso de que diferentes paquetes proporcionen la misma biblioteca. La única alternativa sería dividir cada paquete de sus bibliotecas, con todo el alboroto adicional que requiere, y ni siquiera se garantizaría que funcione debido a los paquetes que necesitan versiones anteriores de la biblioteca. Las características deben estar desactivadas ya que Eclipse no las detectará de otra manera, y la instalación completa del complemento no funcionará. Esto sucede porque Eclipse trata los sitios de actualización y las instalaciones locales de manera diferente (no pregunte por qué, simplemente lo hace).
La funsión build()
Lo primero que debe notarse es la orden cd ${srcdir}. Por lo general, los archivos de origen extraen las carpetas features y plugins directamente en ${srcdir}, pero no siempre es así. De todos modos, para la mayoría de los complementos que no son (de facto), ésta es la única línea que se debe cambiar.
Algunas características lanzadas incluyen sus fuentes, también. Para una versión de lanzamiento normal, estas fuentes no son necesarias y se pueden eliminar. Además, las mismas características incluyen archivos *.pack.gz, que contienen los mismos archivos en comparación con los archivos jar. Así que estos archivos pueden ser eliminados, también.
La siguiente es la sección features. Crea los directorios necesarios, uno para cada archivo jar, y extrae el jar en el directorio correspondiente. De manera similar, la sección plugins instala los archivos jar en su directorio. Se utiliza un ciclo while para evitar archivos con nombres divertidos.
Solución de problemas
- Algunas veces la limpieza de Eclipse ayuda a reparar algunos problemas:
$ eclipse -clean
- Si los nuevos complementos instalados no aparecen en Eclipse, intente con un directorio limpio
~/.eclipse, por ejemplo, cambiando el nombre del existente. Tenga en cuenta que esto, por supuesto, hará que todos los complementos instalados por el usuario a través de Marketplace no estén disponibles.