Ok, IzPack utilise les JAR un peu comme on peut utiliser des zip auto-exécutables sous MS Windows et ce n'est pas seulement pour des programmes Java qui auraient des librairies fournis sous formes .JAR.
Heu ... je vais expliquer. Un .jar n'est qu'un fichier zip. On a l'habitude en Java de grouper les classes compilées + d'autres resources (images, etc) dans le Jar. Un Jar peut etre exécutable, en spécifiant dans un fichier qu'il contient (nommé manifeste) la classe principale à utiliser (une qui contient une méthode statique main - idem int main(int argc, char **argv) en C/C++). Un installateur est donc un Jar exécutable. Autrement dit tu fais :
java -jar IzPack-install.jar
et ça le lance. L'avantage est aussi que tout est groupé dans le Jar, et accessoirement compressé. Après un Jar peut servir aussi à contenir des librairies. Il faut voir un Jar avant tout comme un groupement de classes Java.
Le boulot d'un générateur d'installateurs est de générer des installateurs et qu'il soit fait en Java, en C ou en smlurph ne doit pas changer cet objectif.
Tout à fait, sauf qu'en général si tu veux un installateur en Java, c'est que tu distribues quelque chose qui a un rapport avec Java. Sinon tu auras plutot tendance à utiliser des méthodes d'installations spécialisée pour chaque plateforme. C'est juste qu'en général, on utilise IzPack pour des logiciels Java car il y a un intéret immédiat. Pour installer un soft uniquement Linux par exemple, l'intéret serait bien moindre car tout le monde n'a pas de machine Java installée. Donc tu utilises plutot un installateur Java si ta cible d'utilisateurs utilise Java aussi.
La phrase IzPack, générateur d'installateurs de logiciels en Java vient... n'est AMHA pas très claire. Moi, j'ai compris que en Java était pour les logiciels, alors que c'était juste pour IzPack. Ce qui m'a conforté dans mon erreur était que toutes les réferences ( www.izforge.com/izpack/index.php3?content=references ) semblent être des programmes Java.
En effet ma phrase peut induire en erreur. Java est bien pour IzPack. Les références sont uniquement de programmes Java car à ma connaissance personne ne l'a utilisé pour autre chose que des programmes Java, ce qui correspond à ce que j'ai dit au paragraphe précédant.
Est-ce que ça gèrent aussi les dépendences? Histoire que ça n'installe pas un software qui auraient besoin de telles ou telles librairies.
Non. En fait on pourrait gérer des dépendances au niveau des paquets d'une installation (par exemple tu peux faire un paquet pour les fichiers obligatoires, un paquet pour la doc, etc). Pour une dépendance du style "ne pas installer si Jakarta Ant n'est pas sur la machine", le problème est très complexe. Sous un Unix-like, tu peux t'attendre à trouver ça dans /usr/**/ voir /opt/** . Sur un Windows par exemple, tu es bon pour te payer un scan du disque :-/ Sans compter que si tu veux vérifier la version, c'est encore moins simple. Avec des MD5 ça serait éventuellement envisageable. Mais dans l'ensemble ça reste sujet à erreurs et c'est très compliqué à faire. Mais si tu trouves une méthode efficace (style en O(0.5)) je suis preneur :-)
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 10.
Heu ... je vais expliquer. Un .jar n'est qu'un fichier zip. On a l'habitude en Java de grouper les classes compilées + d'autres resources (images, etc) dans le Jar. Un Jar peut etre exécutable, en spécifiant dans un fichier qu'il contient (nommé manifeste) la classe principale à utiliser (une qui contient une méthode statique main - idem int main(int argc, char **argv) en C/C++). Un installateur est donc un Jar exécutable. Autrement dit tu fais :
et ça le lance. L'avantage est aussi que tout est groupé dans le Jar, et accessoirement compressé. Après un Jar peut servir aussi à contenir des librairies. Il faut voir un Jar avant tout comme un groupement de classes Java.
Le boulot d'un générateur d'installateurs est de générer des installateurs et qu'il soit fait en Java, en C ou en smlurph ne doit pas changer cet objectif.
Tout à fait, sauf qu'en général si tu veux un installateur en Java, c'est que tu distribues quelque chose qui a un rapport avec Java. Sinon tu auras plutot tendance à utiliser des méthodes d'installations spécialisée pour chaque plateforme. C'est juste qu'en général, on utilise IzPack pour des logiciels Java car il y a un intéret immédiat. Pour installer un soft uniquement Linux par exemple, l'intéret serait bien moindre car tout le monde n'a pas de machine Java installée. Donc tu utilises plutot un installateur Java si ta cible d'utilisateurs utilise Java aussi.
La phrase IzPack, générateur d'installateurs de logiciels en Java vient... n'est AMHA pas très claire. Moi, j'ai compris que en Java était pour les logiciels, alors que c'était juste pour IzPack. Ce qui m'a conforté dans mon erreur était que toutes les réferences ( www.izforge.com/izpack/index.php3?content=references ) semblent être des programmes Java.
En effet ma phrase peut induire en erreur. Java est bien pour IzPack. Les références sont uniquement de programmes Java car à ma connaissance personne ne l'a utilisé pour autre chose que des programmes Java, ce qui correspond à ce que j'ai dit au paragraphe précédant.
Est-ce que ça gèrent aussi les dépendences? Histoire que ça n'installe pas un software qui auraient besoin de telles ou telles librairies.
Non. En fait on pourrait gérer des dépendances au niveau des paquets d'une installation (par exemple tu peux faire un paquet pour les fichiers obligatoires, un paquet pour la doc, etc). Pour une dépendance du style "ne pas installer si Jakarta Ant n'est pas sur la machine", le problème est très complexe. Sous un Unix-like, tu peux t'attendre à trouver ça dans /usr/**/ voir /opt/** . Sur un Windows par exemple, tu es bon pour te payer un scan du disque :-/ Sans compter que si tu veux vérifier la version, c'est encore moins simple. Avec des MD5 ça serait éventuellement envisageable. Mais dans l'ensemble ça reste sujet à erreurs et c'est très compliqué à faire. Mais si tu trouves une méthode efficace (style en O(0.5)) je suis preneur :-)
En espérant avoir répondu à tes questions ...