Eclipse plugin package guidelines (Italiano)

From ArchWiki
Revision as of 21:27, 10 October 2011 by Kynikos (Talk | contribs) (riallineamento (50%))

Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Ci sono numerosi modi per installare un plugin funzionante di Eclipse, sopratutto da quando è stata introdotta la cartella "dropins" in Eclipse 3.4, tuttavia alcune di queste maniere risultano disordinate, e avere un forma di pacchettizzazione standardizzata e coerente è molto importante per ottenere una struttura di sistema pulita. Non è facile però ottenere questo risultato senza che il gestore di pacchetti sia consapevole di come funzionino i plugin di Eclipse. Questa pagina ha lo scopo di definire una struttura standard semplice per i PKGBUILD dei plugin di Eclipse, cosicché la struttura del filesystem possa rimanere coerente tra i plugin senza che il manutentore dei pacchetti debba fare tutto daccapo per ogni nuovo pacchetto.

Struttura ed installazione dei plugin di Eclipse

Il tipico plugin di Eclipse contiene due cartelle, Template:Filename e Template:Filename, e a partire da Eclipse 3.3 potevano essere posizionate solamente in Template:Filename. Il contenuto di queste due cartelle poteva essere mescolato con quello degli altri plugin, e ciò creava confusione, rendendo la struttura di difficile amministrazione. Era inoltre molto difficile capire a colpo d'occhio a quale pacchetto appartenesse ciascun file.

Questo metodo di installazione è ancora supportato in Eclipse 3.4, ma quello preferibile ora è quello che usa la cartella Template:Filename. All'interno di questa cartella possono trovarsi un numero indefinito di sottocartelle, ognuna delle quali contenente le proprie sottocartelle Template:Filename e Template:Filename. Ciò permette di mantenere una struttura ordinata e pulita, e dovrebbe essere la maniera standard di pacchettizzazione.

Pacchettizzazione

Esempio di PKGBUILD

Qui c'è un esempio, discuteremo più avanti su come personalizzarlo.

pkgname=eclipse-mylyn
pkgver=3.0.3
pkgrel=1
pkgdesc="A task-focused interface for Eclipse"
arch=('i686' 'x86_64')
url="http://www.eclipse.org/mylyn/"
license=('EPL')
depends=('eclipse')
optdepends=('bugzilla: ticketing support')
source=(http://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip)
md5sums=('e98cd7ab3c5d5aeb7c32845844f85c22')

build() {
  _dest=${pkgdir}/usr/share/eclipse/dropins/${pkgname/eclipse-}/eclipse

  cd ${srcdir}

  # Features
  find features -type f | while read _feature ; do
    if [[ ${_feature} =~ (.*\.jar$) ]] ; then
      install -dm755 ${_dest}/${_feature%*.jar}
      cd ${_dest}/${_feature/.jar}
      jar xf ${srcdir}/${_feature} || return 1
    else
      install -Dm644 ${_feature} ${_dest}/${_feature}
    fi
  done

  # Plugins
  find plugins -type f | while read _plugin ; do
    install -Dm644 ${_plugin} ${_dest}/${_plugin}
  done
}

Come personalizzare il pacchetto

La variabile principale che dev'essere personalizzata è il pkgname. Se si sta pacchettizzando un plugin tipo, allora questa è l'unica cosa da fare: la maggior parte dei plugin viene distribuita in file zip che contengono solamente le due sottocartelle features e plugins. Così, se si sta pacchettizzando il plugin "foo" e il file sorgente contiene solamente features e plugins, allora occorre cambiare solamente il pkgname in eclipse-foo e si è apposto.

Si legga avanti per le istruzioni sulla parte interna del PKGBUILD, che aiutano a capire come impostarlo per tutte le altre situazioni.

Analisi dell'interno del PKGBUILD

Nominare il pacchetto

I pacchetti dovrebbe sempre chiamarsi eclipse-nome del plugin, così da renderli riconoscibili come pacchetti relativi a eclipse e rendere facile il riconoscimento del nome del plugin con una semplice sostituzione tramite shell come Template:Codeline}, senza dover ricorrere a una variabile Template:Codeline} non necessaria. Il nome del plugin è necessario per ordinare ogni cosa durante l'installazione ed evitare conflitti.

File

Estrazione

Alcuni plugin necessitano dell'opzione per essere estratti dal file jar. L'utilità jar, già inclusa in JRE, serve a ciò. Comunque, i file jar non possono essere estratti in una cartella diversa da quella corrente: ciò significa che, dopo avere creato ogni cartella, è necessario spostarsi all'interno con cd prima di effettuare l'estrazione. La variabile Template:Codeline} è usata in questo contesto per aumentare la leggibilità e l'ordine del PKGBUILD.

Posizione

Come abbiamo detto, gli archivi sorgenti forniscono due cartelle, feature e plugins, ognuna delle quali contenente i file jar. La struttura interna migliore dovrebbe apparire così:

/usr/share/eclipse/dropins/pluginname/eclipse/features/feature1/...
/usr/share/eclipse/dropins/pluginname/eclipse/features/feature2/...
/usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin1.jar
/usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar

Questa struttura permette di mescolare diverse versioni di librerie che potrebbero essere necessarie a plugin differenti mantenendo chiara la struttura di appartenenza dei pacchetti. Permette anche di evitare conflitti nel caso in cui diversi pacchetti forniscano le stesse librerie. L'unica alternativa sarebbe quella di dividere ogni pacchetto dalle proprie librerie, con tutta la confusione che ne deriverebbe, e non sarebbe nemmeno assicurato il funzionamento a causa di pacchetti che hanno bisogno di vecchie versioni di librerie. La cartella features dev'essere estratta altrimenti Eclipse non sarà in grado di vederla, e l'intera installazione del plugin non funzionerà. Ciò accade perché Eclipse tratta i siti di aggiornamento e le installazioni locali in maniera differente (non chiedere il perché, lo fa e basta).

La funzione build()

La prima cosa da notare è il comando Template:Codeline}. Solitamente gli archivi sorgente estraggono le cartelle features e plugins direttamente sotto ${srcdir}, ma questo non è sempre vero. Ad ogni modo, per la maggior parte dei plugin non-(de facto)-standard questa è l'unica linea che dev'essere cambiata. La prossima è la sezione features. Essa crea le cartelle necessarie, una per ogni file jar, ed estrae il file nella cartella corrispondente. Alla stessa maniera, la sezione plugins installa i file jar nelle proprie cartelle. Un ciclo nel frattempo viene usato per evitare file dal nome buffo.