Difference between revisions of "Eclipse plugin package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
m (add tag translateme)
Line 2: Line 2:
  
 
{{i18n|Eclipse plugin package guidelines}}
 
{{i18n|Eclipse plugin package guidelines}}
{{translateme}}
 
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
 
  
== Introduction ==
+
== Introduzione ==
There are many ways to install working Eclipse plugins, especially since the introduction of the ''dropins'' directory in Eclipse 3.4, but some or them are messy, and having a standardized and consistent way of packaging is very important to lead to a clean system structure. It's not easy, however, to achieve this without the packager knowing every detail about how Eclipse plugins work. This page aims to define a standard and simple structure for Eclipse plugin PKGBUILDs, so that the filesystem structure can remain consistent between all plugins without having the packager to start again for every new package.
+
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 l'avere un forma di pacchettizzazione standardizzata e coerente è molto importante per ottenere una struttura di sistema pulita. Non è facile comunque ottenere questo risultato, senza la consapevolezza di come funzioni il plugin Eclipse. Questa pagina ha lo scopo di definire una struttura standard semplice per il PKGBUILD del plugin Eclipse, cosicché  la struttura del filesystem possa rimanere costantemente tra i plugin senza dover necessariamente far partire il packager ad ogni nuovo pacchetto.
  
== Eclipse plugin structure and installation ==
+
== Struttura ed installazione del plugin Eclipse ==
The typical Eclipse plugin contains two directories, ''features'' and ''plugins'', and since Eclipse 3.3 they could only be placed in ''/usr/share/eclipse/''. The content of these two directories could be mixed with that of other plugins, but it created a mess and rendered the structure difficult to manage. It was also very difficult to tell at a glance which package contained which file.
+
Il tipico plugin Eclipse contiene due cartelle, ''features'' e ''plugins'', e a partire da Eclipse 3.3 possono essere posizionate solamente in {{filename | /usr/share/eclipse/}} . Il contenuto di queste due cartelle può essere mescolato con quello degli altri plugin, ma ciò creerebbe confusione, rendendo la struttura di difficile amministrazione. Sarebbe addirittura difficoltoso dire con certezza quale pacchetto contenga quale file.  
  
This installation method is still supported in Eclipse 3.4, but the preferred one is now using the ''/usr/share/eclipse/dropins/'' directory. Inside this directory can live an unlimited number of subdirectories, each one containing its own ''features'' and ''plugins'' subdirectories. This allows to keep a tidy and clean structure, and should be the standard packaging way.
+
Questo metodo di installazione è ancora supportato in Eclipse 3.4 ma quello preferibile ora è quello che usa la cartella {{filename | /usr/share/eclipse/dropins/}}. All'interno di questa cartella possono trovarsi un numero indefinito di sottocartelle, ognuna delle quali contenente le proprie sottocartelle di ''features'' e ''plugins''. Ciò permette di mantenere una struttura ordinata e pulita, e dovrebbe essere la maniera più corretta di pacchettizzazione.
  
== Packaging ==
+
== Pacchettizzazione ==
  
=== Sample PKGBUILD ===
+
=== Esempio di PKGBUILD ===
Here's an example, we'll detail how to customize it below.
+
Qui c'è un esempio; discuteremo più avanti su come personalizzarlo.
  
 
  pkgname=eclipse-mylyn
 
  pkgname=eclipse-mylyn
Line 52: Line 50:
 
  }
 
  }
  
=== How to customize the build ===
+
=== Come personalizzare il pacchetto ===
The main variable which needs to be customized is the ''pkgname''. If you are packaging a typical plugin, then this is the only thing you need to do: most plugins are distributed in zip files which only contain the two ''features'' and ''plugins'' subdirectories. So, if you're packaging the ''foo'' plugin and the source file only contains the ''features'' and ''plugins'', you just need to change ''pkgname'' to ''eclipse-foo'' and you're set.
+
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.
  
Read on to get to the internals of the PKGBUILD, which help to understand how to setup the build for all the other cases.
+
Si legga avanti per le istruzioni sulla parte interna del PKGBUILD, che aiutano a capire come impostarlo per tutte le altre situazioni.
  
=== In-depth PKGBUILD review ===
+
=== Analisi dell'interno del PKGBUILD ===
  
==== Package naming ====
+
==== Nominare il pacchetto ====
Packages should be named eclipse-''pluginname'', so that they're recognizable as eclipse-related packages and it's easy to extract the plugin name with a simple shell substitution like ''${pkgname/eclipse-}'', not having to resort to an unneeded ''${_realname}'' variable. The plugin name is necessary to tidy up everything during installation and to avoid conflicts.
+
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 {{codeline | ${pkgname/eclipse-}}}, senza dover ricorrere a una variabile {{codeline | ${_reale}}} non necessaria. Il nome del plugin è necessario per ordinare ogni cosa durante l'installazione ed evitare conflitti.
  
==== Files ====
+
==== File ====
  
===== Extraction =====
+
===== Estrazione =====
Some plugins need the features to be extracted from jar files. The ''jar'' utility, already included in the JRE, is used to do this. However, ''jar'' can't extract to directories other than the current one: this means that, after every directory creation, it's necessary to ''cd'' inside it before extracting. The ''${_dest}'' variable is used in this context to improve readability and PKGBUILD tidiness.
+
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 {{codeline | ${_dest}}} è usata in questo contesto per aumentare la leggibilità e l'ordine del PKGBUILD.  
  
===== Locations =====
+
===== Posizione =====
As we said, source archives provide two directories, features and plugins, each one packed up with jar files. The preferred dropins structure should look like this:
+
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/feature1/...
Line 75: Line 73:
 
  /usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar
 
  /usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar
  
This structure allows for mixing different versions of libraries that may be needed by different plugins while being clear about which package owns what. It will also avoid conflicts in case different packages provide the same library. The only alternative would be splitting every package from its libraries, with all the extra fuss it requires, and it wouldn’t even be guaranteed to work because of packages needing older library versions.
+
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.  
Features have to be unjarred since Eclipse won't detect them otherwise, and the whole plugin installation won’t work. This happens because Eclipse treats update sites and local installations differently (don't ask why, it just does).
+
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).
  
==== The build() function ====
+
==== La funzione build() ====
First thing to be noticed is the ''cd ${srcdir}'' command. Usually source archives extract the ''features'' and ''plugins'' folders directly under ''${srcdir}'', but this is not always the case. Anyway, for most non-''(de facto)''-standard plugins this is the only line that needs to be changed.
+
La prima cosa da notare è il comando {{codeline | ${srcdir}}}. 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.
Next is the ''features'' section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the ''plugins'' section installs the jar files in their directory. A while cycle is used to prevent funny-named files.
+
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.

Revision as of 14:33, 4 May 2011


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 – فارسی

Introduzione

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 l'avere un forma di pacchettizzazione standardizzata e coerente è molto importante per ottenere una struttura di sistema pulita. Non è facile comunque ottenere questo risultato, senza la consapevolezza di come funzioni il plugin Eclipse. Questa pagina ha lo scopo di definire una struttura standard semplice per il PKGBUILD del plugin Eclipse, cosicché la struttura del filesystem possa rimanere costantemente tra i plugin senza dover necessariamente far partire il packager ad ogni nuovo pacchetto.

Struttura ed installazione del plugin Eclipse

Il tipico plugin Eclipse contiene due cartelle, features e plugins, e a partire da Eclipse 3.3 possono essere posizionate solamente in Template:Filename . Il contenuto di queste due cartelle può essere mescolato con quello degli altri plugin, ma ciò creerebbe confusione, rendendo la struttura di difficile amministrazione. Sarebbe addirittura difficoltoso dire con certezza quale pacchetto contenga quale 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 di features e plugins. Ciò permette di mantenere una struttura ordinata e pulita, e dovrebbe essere la maniera più corretta 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.