Difference between revisions of "Java package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
[[Category:Package development (Italiano)]]
 
[[Category:Package development (Italiano)]]
[[Category:Guidelines (Italiano)]]
+
[[en:Java Package Guidelines]]
{{i18n|Java_Package_Guidelines}}
+
[[zh-CN:Java Package Guidelines]]
 
+
{{translateme}}
+
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
+
 
+
 
:''Questo documento definisce uno standard proposto per pacchettizzare i programmi Java sotto Arch Linux. I programmi Java sono notoriamente difficili da pacchettizzare in maniera pulita senza sovrascrivere dipendenze. Questo documento descrive un metodo per rimediare a questa situazione. Queste linee guida sono flessibili nell'ottica di coprire i molti possibili scenari che si possono verificare quando si ha a che fare con applicazioni Java.''
 
:''Questo documento definisce uno standard proposto per pacchettizzare i programmi Java sotto Arch Linux. I programmi Java sono notoriamente difficili da pacchettizzare in maniera pulita senza sovrascrivere dipendenze. Questo documento descrive un metodo per rimediare a questa situazione. Queste linee guida sono flessibili nell'ottica di coprire i molti possibili scenari che si possono verificare quando si ha a che fare con applicazioni Java.''
  
 
==Introduzione==
 
==Introduzione==
  
I packagers Arch Linux non sembrano trovare un accordo su come gestire i pacchetti Java. Vari metodi sono utilizzati nei <code>PKGBUILD</code> che si trovano sui repository ufficiali, in quelli non ufficiali e su [http://aur.archlinux.org/ AUR].  
+
I packagers Arch Linux non sembrano trovare un accordo su come gestire i pacchetti Java. Vari metodi sono utilizzati nei <code>PKGBUILD</code> che si trovano sui repository ufficiali, in quelli non ufficiali e su [https://aur.archlinux.org/ AUR].  
 
Queste soluzioni includono la presenza dell'intero pacchetto in <code>/opt </code> con script da shelli in <code>/usr/bin</code> o profili posizionati in <code>/etc/profile</code>. Altri pacchetti sono collocati nelle directories in <code>/usr/share</code> con script posizionati  
 
Queste soluzioni includono la presenza dell'intero pacchetto in <code>/opt </code> con script da shelli in <code>/usr/bin</code> o profili posizionati in <code>/etc/profile</code>. Altri pacchetti sono collocati nelle directories in <code>/usr/share</code> con script posizionati  
 
in <code>/usr/bin</code>. Molti aggiungono file non necessari a <code>CLASSPATH</code> and <code>PATH</code>.
 
in <code>/usr/bin</code>. Molti aggiungono file non necessari a <code>CLASSPATH</code> and <code>PATH</code>.
Line 16: Line 12:
 
==Struttura di una tipica Applicazione Java==
 
==Struttura di una tipica Applicazione Java==
  
Most Desktop Java applications have a similar structure. They are installed from a system-independent (but package dependent!) installer. This usually installs everything in a single directory with subdirectories called <code>bin</code>, <code>lib</code>, <code>jar</code>, <code>conf</code>, etc. There is usually a main jar file containing the main executable classes. A shellscript is usually provided to run the main class so users do not have to invoke the Java interpreter directly. This shell script is usually quite complex, as it is generic across distros, and often includes special cases for different systems (ie: CYGWIN).
+
La maggior parte delle applicazioni desktop Java ha una struttura simile. Esse sono installate da un installer indipendente dal sistema (ma dipendente dal pacchetto!). Questo installer solitamente installa tutto in una singola directory con sottodirectory chiamate <code>bin</code>, <code>lib</code>, <code>jar</code>, <code>conf</code>, etc. Solitamente c'è un file jar primario che contiene le principali classi eseguibili. Solitamente viene fornito uno script che esegue le classi fondamentali così che l'utente non debba invocare l'interprete Java direttamente. Questo script è solitamente abbastanza complesso, dato che è generico per tutte le distribuzioni, e spesso include opzioni particolari per i differenti sistemi (es: CYGWIN).
  
The <code>lib</code> directory, often contains bundled jar files that satisfy dependencies of the Java application. This makes it simple for a user to install the program (all dependencies included), but is a package developer's nightmare. It is a waste of space when several packages bundle the same dependency. This was not a big issue in the past when there were fewer desktop Java applications and libraries, and those that existed tended to be very large anyway. Things are different now...
+
La directory <code>lib</code> spesso contiene dei file jar collegati tra loro che soddisfano le dipendenze dell'applicazione Java.
 +
Ciò rende semplice per l'utente installare il programma (essendo incluse tutte le dipendenze), ma rende il pacchetto un incubo per lo sviluppatore. È uno spreco di spazio quando diversi pacchetti contengono la stessa dipendenza. In passato, quando c'erano meno applicazioni e librerie Java, e quelle esistenti tendevano comunque ad essere molto grandi, non rappresentava un problema rilevante. Ora però le cose sono cambiate...
  
Other files necessary to run the program are usually stored in the same folder as the main jar file, or a subdirectory thereof. Since Java programs don't know where their classes were loaded from, they usually need to be run from within this directory (i.e. the shell script should <code>cd</code> into the directory), or an environment variable is set to indicate the directory's location.
+
Altri file necessari ad eseguire il programma sono solitamente inclusi nella stessa cartella del file jar primario, in una sua sottodirectory. Dal momento che i programmi Java non sanno da dove le loro classi vengono prese, solitamente c'è bisogno di eseguirli nella stessa directory (per esempio uno scrpt potrebbe dare <code>cd</code> nella directory), oppure deve essere impostata una variabile d'ambiente che indichi la posizione della directory.
  
 
==Arch Java Packaging==
 
==Arch Java Packaging==
  
Packaging Java applications in Arch is going to take quite a bit more work for packagers than it currently does. The effort will be worth it, however, resulting in a cleaner filesystem and fewer bundled dependencies (as more and more Java libraries are refactored into their own packages, packaging will become easier). The following guidelines should be followed in creating an Arch Linux Java package:
+
Pacchettizzare applicazioni Java in Arch richiederà un po' più di lavoro per i manutentori rispetto a quanto ne richieda attualmente. Tuttavia ne varrà la pena, dal momento che si otterrà un filesystem più pulito e con meno dipendenze inglobate (e man mano che sempre più librerie Java saranno ricompilate nei loro pacchetti, pacchettizzare diventerà sempre più facile).  
 +
Nel creare un pacchetto Java per Arch Linux si dovrebbero seguire le seguenti linee guida:
  
* If a Java library has a generic name, the package name should be prepended with the title <code>java-</code> to help distinguish it from other libraries. This is not necessary with uniquely named packages (like JUnit), end-user programs (like Eclipse), or libraries that can be uniquely described with another prefix (like jakarta-commons-collections or apache-ant).
+
* Se una libreria Java ha un nome generico, il nome del pacchetto dovrebbe avere il prefisso <code>java-</code> in modo da distinguerlo dalle altre librerie. Ciò non è necessario per i pacchetti dal nome univoco (come JUnit), per i programmi end-user (come Eclipse), o per le librerie che possono essere descritte con un altro prefisso (come jakarta-commons-collections or apache-ant).
  
* You do not need to compile Java applications from source. Very little optimization goes into the compile process, as with gcc created binaries. If the source package provides an easy way to build from source go ahead and use it, but if its easier to just grab a binary release of a jar file or an installer you may use that as well.
+
* Non è necessario compilare le applicazioni Java dai sorgenti. Nel processo di compilazione ci va pochissima compilazione, come per i binari creati da gcc. Se il pacchetto originario fornisce un metodo semplice di costruire da sorgente, va usato quello; ma se è più semplice prendere semplicemente una release binaria di un file jar o un installer, si può usare anche quel metodo.
  
* Place all jar files (and no other files) distributed with the program in a <code>/usr/share/java/myprogram</code> directory. This includes all dependency jar files distributed with the application. However, effort should be made to place common or large dependency libraries into their own packages. This can only happen if the program does not depend on a specific version of a dependency library.
+
* Tutti i file jar (e solo quelli) distrubuiti col programma vanno posizionati nella directory <code>/usr/share/java/myprogram</code>. Ciò comprende tutte i file jar dipendenti distribuiti con l'applicazione. Va comunque fatto lo sforzo di mettere le dipendenze comuni o le grandi librerie dentro i loro rispettivi pacchetti. Ciò può avvenire solo se il programma non dipende da una specifica versione di una libreria dipendente.
  
This rule makes it possible to iteratively refactor dependencies. That is, the package and all its dependencies can be placed into one directory at first. After this has been tested, major dependencies can be refactored out one at a time. Note that some applications include bundled dependencies inside the main jar file. That is, they unjar the bundled dependencies and include them in the main jar. Such dependencies are usually very small and there is little point in refactoring them.
+
Questa regola rende possibile il refactoring iterarivo delle dipendenze. Cioè, il pacchetto e tutte le sue dipendendenze possono essere inizilamente messi dentro una sola directory, Dopo il test, le principali dipendenze possono essere sottoposte a refactoring una alla volta. È da notare come alcune applicazioni includono dipendenze bundle all'interno del file jar primario (cioè estraggono dal jar le dipendenze e le inglobano nel loro jar). Tali dipendenze sono solitamente poco ingombranti e vi è poco vantaggio nel sottoporle a refactoring.
  
* If the program is meant to be run by the user, write a custom shell script that runs the main jar file. This script should be placed in <code>/usr/bin</code>. Libraries generally don't require shell scripts. Write the shell script from scratch, rather than using one that is bundled with the program. Remove code that tests for custom environments (like CYGWIN), and code that tries to determine if <code>JAVA_HOME</code> has been set (The J2RE package ensures <code>JAVA_HOME</code> has been properly set, so we do not need to test for it).
+
* Se il programma deve essere eseguito dall'utente, scrivere uno script personalizzato che esegua il file jar primario. Questo script dovrebbe essere posizionato in <code>/usr/bin</code>. Le librerie generalmente non richiedono script. È meglio scrivere lo script da zero piuttosto che usarne uno incluso nel programma. Rimuovere il codice che controlla l'esistenza di di ambienti personalizzati (come CYGWIN), e il codice che tenta di determinare se la variabile <code>JAVA_HOME</code> è stata inizializzata (il pacchetto J2RE assicura che <code>JAVA_HOME</code> venga adeguatamente inizializzata)
 +
 
 +
Uno script con queste caratteristiche dovrebbe apparire così per i jar:
  
such script should look like this for jars:
 
 
  #!/bin/sh
 
  #!/bin/sh
 
  "$JAVA_HOME/bin/java" -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar'
 
  "$JAVA_HOME/bin/java" -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar'
  
and like this for single class files:
+
e così per i singoli file delle classi:
 +
 
 
  #!/bin/sh
 
  #!/bin/sh
 
  "$JAVA_HOME/bin/java" '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME'
 
  "$JAVA_HOME/bin/java" '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME'
  
* Set the <code>CLASSPATH</code> using the <code>-cp</code> option to the Java interpreter unless there is an explicit reason not to (ie: the <code>CLASSPATH</code> is used as a plugin mechanism). The <code>CLASSPATH</code> should include all jar files in the <code>/usr/share/java/myprogram</code> direcory, as well as jar files that are from dependency libraries that have been refactored to other directories. You can use something like the following code:
+
* Impostare il il <code>CLASSPATH</code> mediante l'opzione <code>-cp</code> nell'interprete Java, am meno che non vi sia una motivazione esplicita di non farlo (per esempio: il <code>CLASSPATH</code> è usato come un plugin ). Il <code>CLASSPATH</code> dovrebbe includere tutti i file jar nella directory <code>/usr/share/java/myprogram</code>, così come i file jar derivanti da librerie dipendenti che sono state sottoposte a refactoring in altre directory. Si potrebbe usare qualcosa di simile al codice seguente:
 +
 
 
  for name in /usr/share/java/myprogram/*.jar ; do
 
  for name in /usr/share/java/myprogram/*.jar ; do
 
   CP=$CP:$name
 
   CP=$CP:$name
Line 51: Line 52:
 
  java -cp $CP myprogram.java.MainClass
 
  java -cp $CP myprogram.java.MainClass
  
* Make sure the shellscript is executable!
+
* Assicurarsi che lo script sia eseguibile!
  
* Other files distributed with the package should be stored in a directory named after the package under <code>/usr/share</code>. You may need to set the location of this directory in a variable like <code>MYPROJECT_HOME</code> inside the shellscript. This guideline assumes that the program expects all files to be in the same directory (as is standard with Java packages). If it seems more natural to put a configuration file elsewhere (for example, a daemon in <code>/etc/rc.d</code> or logs in <code>/var/log</code>), then feel free to do so.
+
* Altri files distribuiti col pacchetto dovrebbero essere archiviati in una directory col nome del pacchetto dentro a <code>/usr/share</code>. La posizione di tale directory potrebbe essere impostata in una variabile come <code>MYPROJECT_HOME</code> dentre lo script. Questa regola assume che il programma si aspetti che tutti i files siano nella stessa directory (come è lo standard per i pacchetti Java ). Se sembra più naturale mettere un file di configurazione da un'altra parte (per esempio, un demone in <code>/etc/rc.d</code> o dei log in <code>/var/log</code>), si è liberi di farlo.
  
Bear in mind that <code>/usr</code> may be mounted as read-only on some systems. If there are files in the shared directory that need to be written by the application, they may have to be relocated to <code>/etc</code>, <code>/var</code>, or the user's home directory.
+
Tenere a mente che <code>/usr</code> potrebbe essere montata in modalità read-only in alcuni sistemi.
 +
Se ci sono file nella directory condivisa che necessitano di essere scritti dall'applicazione, questi potrebbero essere riposizionati sotto <code>/etc</code>, <code>/var</code>, o la home dell'utente.
  
* As is standard with Arch Linux packages, if the above standards cannot be adhered to without a serious amount of work, the package should be installed in its preferred manner, with the resulting directory located in <code>/opt</code>. This is useful for programs that bundle JREs or include customized versions of dependencies, or do other strange or painful tasks.
+
* Come è lo standard per i pacchetti Arch Linux, se non si può aderire agli standard proposti sopra senza un considerevole lavoro, il pacchetto dovrebbe essere installato nella maniera preferita, con la directory risultante posizionata sotto <code>/opt</code>.  
 +
Ciò è utile per programmi che includono JREs o versioni personalizzate delle dipendenze, o altri strani o difficili sistemi.
  
===Multiple API implementations===
+
===Implementazione di API multiple===
If your package distributes commonly used api implementation(like jdbc driver) you should place the library under /usr/share/java/<apiname>. So that applications that allow user to select from various implementations
+
Se il paccheto distribuisce api la cui implementazione è di uso comune (come il driver jdbc), la libreria dovrebbe essere posizionata in /usr/share/java/<apiname>.
will know where to look for them. Use this location only for raw library packages. If such a implementation is part of distribution of application, <strong>do not</strong> place this jarfile under common location, but  use ordinary package structure.
+
In tal modo le applicazioni che permetto all'utente di scegliere tra varie implementazioni sapranno dove andarle a cercare.  
 +
Questo percorso andrebbe utilizzato solo per pacchetti grezzi di librerie. Se una tale implementazione è parte della distribuzione dell'applicazione, '''non''' collocare il file jar nel percorso comune, ma utilizzare la struttura di pacchetto ordinaria.
  
===Example Directory Structure===
+
===Esempio di albero di directory===
  
To clarify, here is an example directory structure for a hypothetical program called <code>foo</code>. Since <code>foo</code> is a common name, the package is named <code>java-foo</code>, but notice this is not reflected in the directory structure:
+
Per chiarire meglio il concetto, ecco un esempio dell'albero di directory per un ipotetico programma chiamato <code>pippo</code>.  
 +
Dal momento che <code>pippo</code> è un nome comune, il pacchetto è chiamato <code>java-pippo</code>, ma occorre notare che ciò non si riflette enlla struttura delle directory:
  
* <code>/usr/share/java/foo/</code>
+
* <code>/usr/share/java/pippo/</code>
* <code>/usr/share/java/foo/foo.jar</code>
+
* <code>/usr/share/java/pippo/pippo.jar</code>
* <code>/usr/share/java/foo/bar.jar</code> (included dependency of <code>java-foo</code>)
+
* <code>/usr/share/java/pippo/bar.jar</code> (incluse le dipendenze di <code>java-pippo</code>)
* <code>/usr/share/foo/</code>
+
* <code>/usr/share/pippo/</code>
* <code>/usr/share/foo/*.*</code> (some general files required by <code>java-foo</code>)
+
* <code>/usr/share/pippo/*.*</code> (file generici richiesti da <code>java-pippo</code>)
* <code>/usr/bin/foo</code> (executable shell script)
+
* <code>/usr/bin/pippo</code> (script eseguibile da terminale)
  
===Dependencies===
+
===Dipendenze===
Java packages might specify 'java-runtime' or 'java-environment' as dependancy, depending on what they need.
+
I pacchetti Java potrebbero specificare ''java-runtime'' o ''java-environment'' come dipendenze, a seconda delle occorrenze.
  
For most of the package, 'java-runtime' is what is needed to simply run java software written in java.
+
Per la maggioranza dei pacchetti, ''java-runtime'' è tutto quanto è necessario per eseguire un software scritto in java.
  
'''java-runtime''' is a virtual dependancy provided by:
+
'''java-runtime''' è una dipendenza virtuale fornita da:
 
* '''java-gcj-compat''' (free)
 
* '''java-gcj-compat''' (free)
 
* '''openjdk6''' (free)
 
* '''openjdk6''' (free)
 
* '''jre''' (non-free)
 
* '''jre''' (non-free)
  
java-environment is needed by packages that will need to compile java source code into bytecode.
+
''java-environment'' è richiesto da quei pacchetti che necessitano di compilare il codice sorgente di java nel bytecode.
  
'''java-environment''' is a virtual dependancy provided by:
+
'''java-environment''' è una dipendenza virtuale fornita da:
 
* '''openjdk6''' (free)
 
* '''openjdk6''' (free)
 
* '''jdk''' (non-free)
 
* '''jdk''' (non-free)
  
''gcj'' was a long time the only free java environment but was never really useable. Then ''Sun'' started to make more and more parts of java opensource which are now bundeled in the ''openjdk6'' package. ''openjdk6'' is way superior than ''gcj''. Most java applications are at the moment with no problems useable with ''openjdk6''. Some few do still need ''jdk''. Nearly none run with ''gcj''.
+
''gcj'' è stato a lungo l'unico ambiente java free ma non è mai stato realmente utilizzabile. Allora ''Sun'' cominciò a rendere open le parti di Java che ora sono incluse nel pacchetto ''openjdk6''. ''openjdk6'' è di molto superiore a ''gcj''.  
 +
La maggior parte delle applicazioni java sono attualmente utilizzabili con ''openjdk6'', qualcuna ancora richiede ''jdk'' ma praticamente nessuna viene eseguita con ''gcj''.
  
'''Note:''' java-gcj-compat package will be the first package providing java-runtime that pacman will find and install. But it is not the best one. Far from it. java-gcj-compat might be removed in a distant future.
+
'''Nota:''' il pacchetto <code>java-gcj-compat</code> sarà il primo pacchetto a fornire java-runtime che pacman troverà e installerà, ma non è il migliore, anzi! java-gcj-compat potrebbe essere rimosso in un lontano futuro.

Revision as of 09:43, 13 June 2012

Questo documento definisce uno standard proposto per pacchettizzare i programmi Java sotto Arch Linux. I programmi Java sono notoriamente difficili da pacchettizzare in maniera pulita senza sovrascrivere dipendenze. Questo documento descrive un metodo per rimediare a questa situazione. Queste linee guida sono flessibili nell'ottica di coprire i molti possibili scenari che si possono verificare quando si ha a che fare con applicazioni Java.

Introduzione

I packagers Arch Linux non sembrano trovare un accordo su come gestire i pacchetti Java. Vari metodi sono utilizzati nei PKGBUILD che si trovano sui repository ufficiali, in quelli non ufficiali e su AUR. Queste soluzioni includono la presenza dell'intero pacchetto in /opt con script da shelli in /usr/bin o profili posizionati in /etc/profile. Altri pacchetti sono collocati nelle directories in /usr/share con script posizionati in /usr/bin. Molti aggiungono file non necessari a CLASSPATH and PATH.

Struttura di una tipica Applicazione Java

La maggior parte delle applicazioni desktop Java ha una struttura simile. Esse sono installate da un installer indipendente dal sistema (ma dipendente dal pacchetto!). Questo installer solitamente installa tutto in una singola directory con sottodirectory chiamate bin, lib, jar, conf, etc. Solitamente c'è un file jar primario che contiene le principali classi eseguibili. Solitamente viene fornito uno script che esegue le classi fondamentali così che l'utente non debba invocare l'interprete Java direttamente. Questo script è solitamente abbastanza complesso, dato che è generico per tutte le distribuzioni, e spesso include opzioni particolari per i differenti sistemi (es: CYGWIN).

La directory lib spesso contiene dei file jar collegati tra loro che soddisfano le dipendenze dell'applicazione Java. Ciò rende semplice per l'utente installare il programma (essendo incluse tutte le dipendenze), ma rende il pacchetto un incubo per lo sviluppatore. È uno spreco di spazio quando diversi pacchetti contengono la stessa dipendenza. In passato, quando c'erano meno applicazioni e librerie Java, e quelle esistenti tendevano comunque ad essere molto grandi, non rappresentava un problema rilevante. Ora però le cose sono cambiate...

Altri file necessari ad eseguire il programma sono solitamente inclusi nella stessa cartella del file jar primario, in una sua sottodirectory. Dal momento che i programmi Java non sanno da dove le loro classi vengono prese, solitamente c'è bisogno di eseguirli nella stessa directory (per esempio uno scrpt potrebbe dare cd nella directory), oppure deve essere impostata una variabile d'ambiente che indichi la posizione della directory.

Arch Java Packaging

Pacchettizzare applicazioni Java in Arch richiederà un po' più di lavoro per i manutentori rispetto a quanto ne richieda attualmente. Tuttavia ne varrà la pena, dal momento che si otterrà un filesystem più pulito e con meno dipendenze inglobate (e man mano che sempre più librerie Java saranno ricompilate nei loro pacchetti, pacchettizzare diventerà sempre più facile). Nel creare un pacchetto Java per Arch Linux si dovrebbero seguire le seguenti linee guida:

  • Se una libreria Java ha un nome generico, il nome del pacchetto dovrebbe avere il prefisso java- in modo da distinguerlo dalle altre librerie. Ciò non è necessario per i pacchetti dal nome univoco (come JUnit), per i programmi end-user (come Eclipse), o per le librerie che possono essere descritte con un altro prefisso (come jakarta-commons-collections or apache-ant).
  • Non è necessario compilare le applicazioni Java dai sorgenti. Nel processo di compilazione ci va pochissima compilazione, come per i binari creati da gcc. Se il pacchetto originario fornisce un metodo semplice di costruire da sorgente, va usato quello; ma se è più semplice prendere semplicemente una release binaria di un file jar o un installer, si può usare anche quel metodo.
  • Tutti i file jar (e solo quelli) distrubuiti col programma vanno posizionati nella directory /usr/share/java/myprogram. Ciò comprende tutte i file jar dipendenti distribuiti con l'applicazione. Va comunque fatto lo sforzo di mettere le dipendenze comuni o le grandi librerie dentro i loro rispettivi pacchetti. Ciò può avvenire solo se il programma non dipende da una specifica versione di una libreria dipendente.

Questa regola rende possibile il refactoring iterarivo delle dipendenze. Cioè, il pacchetto e tutte le sue dipendendenze possono essere inizilamente messi dentro una sola directory, Dopo il test, le principali dipendenze possono essere sottoposte a refactoring una alla volta. È da notare come alcune applicazioni includono dipendenze bundle all'interno del file jar primario (cioè estraggono dal jar le dipendenze e le inglobano nel loro jar). Tali dipendenze sono solitamente poco ingombranti e vi è poco vantaggio nel sottoporle a refactoring.

  • Se il programma deve essere eseguito dall'utente, scrivere uno script personalizzato che esegua il file jar primario. Questo script dovrebbe essere posizionato in /usr/bin. Le librerie generalmente non richiedono script. È meglio scrivere lo script da zero piuttosto che usarne uno incluso nel programma. Rimuovere il codice che controlla l'esistenza di di ambienti personalizzati (come CYGWIN), e il codice che tenta di determinare se la variabile JAVA_HOME è stata inizializzata (il pacchetto J2RE assicura che JAVA_HOME venga adeguatamente inizializzata)

Uno script con queste caratteristiche dovrebbe apparire così per i jar:

#!/bin/sh
"$JAVA_HOME/bin/java" -jar '/usr/share/java/PROGRAMNAME/PROGRAMNAME.jar'

e così per i singoli file delle classi:

#!/bin/sh
"$JAVA_HOME/bin/java" '/usr/share/java/PROGRAMNAME/PROGRAMCLASSNAME'
  • Impostare il il CLASSPATH mediante l'opzione -cp nell'interprete Java, am meno che non vi sia una motivazione esplicita di non farlo (per esempio: il CLASSPATH è usato come un plugin ). Il CLASSPATH dovrebbe includere tutti i file jar nella directory /usr/share/java/myprogram, così come i file jar derivanti da librerie dipendenti che sono state sottoposte a refactoring in altre directory. Si potrebbe usare qualcosa di simile al codice seguente:
for name in /usr/share/java/myprogram/*.jar ; do
  CP=$CP:$name
done
CP=$CP:/usr/share/java/dep1/dep1.jar
java -cp $CP myprogram.java.MainClass
  • Assicurarsi che lo script sia eseguibile!
  • Altri files distribuiti col pacchetto dovrebbero essere archiviati in una directory col nome del pacchetto dentro a /usr/share. La posizione di tale directory potrebbe essere impostata in una variabile come MYPROJECT_HOME dentre lo script. Questa regola assume che il programma si aspetti che tutti i files siano nella stessa directory (come è lo standard per i pacchetti Java ). Se sembra più naturale mettere un file di configurazione da un'altra parte (per esempio, un demone in /etc/rc.d o dei log in /var/log), si è liberi di farlo.

Tenere a mente che /usr potrebbe essere montata in modalità read-only in alcuni sistemi. Se ci sono file nella directory condivisa che necessitano di essere scritti dall'applicazione, questi potrebbero essere riposizionati sotto /etc, /var, o la home dell'utente.

  • Come è lo standard per i pacchetti Arch Linux, se non si può aderire agli standard proposti sopra senza un considerevole lavoro, il pacchetto dovrebbe essere installato nella maniera preferita, con la directory risultante posizionata sotto /opt.

Ciò è utile per programmi che includono JREs o versioni personalizzate delle dipendenze, o altri strani o difficili sistemi.

Implementazione di API multiple

Se il paccheto distribuisce api la cui implementazione è di uso comune (come il driver jdbc), la libreria dovrebbe essere posizionata in /usr/share/java/<apiname>. In tal modo le applicazioni che permetto all'utente di scegliere tra varie implementazioni sapranno dove andarle a cercare. Questo percorso andrebbe utilizzato solo per pacchetti grezzi di librerie. Se una tale implementazione è parte della distribuzione dell'applicazione, non collocare il file jar nel percorso comune, ma utilizzare la struttura di pacchetto ordinaria.

Esempio di albero di directory

Per chiarire meglio il concetto, ecco un esempio dell'albero di directory per un ipotetico programma chiamato pippo. Dal momento che pippo è un nome comune, il pacchetto è chiamato java-pippo, ma occorre notare che ciò non si riflette enlla struttura delle directory:

  • /usr/share/java/pippo/
  • /usr/share/java/pippo/pippo.jar
  • /usr/share/java/pippo/bar.jar (incluse le dipendenze di java-pippo)
  • /usr/share/pippo/
  • /usr/share/pippo/*.* (file generici richiesti da java-pippo)
  • /usr/bin/pippo (script eseguibile da terminale)

Dipendenze

I pacchetti Java potrebbero specificare java-runtime o java-environment come dipendenze, a seconda delle occorrenze.

Per la maggioranza dei pacchetti, java-runtime è tutto quanto è necessario per eseguire un software scritto in java.

java-runtime è una dipendenza virtuale fornita da:

  • java-gcj-compat (free)
  • openjdk6 (free)
  • jre (non-free)

java-environment è richiesto da quei pacchetti che necessitano di compilare il codice sorgente di java nel bytecode.

java-environment è una dipendenza virtuale fornita da:

  • openjdk6 (free)
  • jdk (non-free)

gcj è stato a lungo l'unico ambiente java free ma non è mai stato realmente utilizzabile. Allora Sun cominciò a rendere open le parti di Java che ora sono incluse nel pacchetto openjdk6. openjdk6 è di molto superiore a gcj. La maggior parte delle applicazioni java sono attualmente utilizzabili con openjdk6, qualcuna ancora richiede jdk ma praticamente nessuna viene eseguita con gcj.

Nota: il pacchetto java-gcj-compat sarà il primo pacchetto a fornire java-runtime che pacman troverà e installerà, ma non è il migliore, anzi! java-gcj-compat potrebbe essere rimosso in un lontano futuro.