Sortie de IzPack 3

Posté par  . Modéré par Manuel Menal.
Étiquettes :
0
13
août
2002
Java
IzPack, générateur d'installateurs de logiciels en Java vient de sortir en version 3.0.0 (stable). IzPack est disponible en 14 langues différentes et peut s'utiliser de façon indifférente depuis un frontend Swing, la ligne de commande ainsi que sous la forme d'une tache pour Jakarta Ant. IzPack est très modulaire, les différents panneaux sont implémentés sous la forme de plugins - c'est donc un jeu d'enfant que d'étendre ses possibilités. Les installations sont "non polluantes" et offrent un bon compromis entre les diverses plateformes.

IzPack a été testé avec succés sur diverses plateformes Unix / Win32 / Mac. La prochaine version apportera le support de la création de raccourcis pour divers Window Managers X11 et peut-etre meme pour MacOS X.

N'hésitez pas à apporter votre aide si vous en avez l'envie :-)

Aller plus loin

  • # Que pour Java :-(

    Posté par  . Évalué à 4.

    Si j'ai bien tout compris, je trouve dommage qu'IzPack ne soit que pour installer des programmes JAVA. Un générateur d'installateurs GPL muliplateforme, multi-windows-manager, multilangage et multilangue serait la panacée.

    • [^] # Re: Que pour Java :-(

      Posté par  . Évalué à 7.

      Et poourquoi ne pas partir d'un projet comme Loki Installer.

      Si c'est capable d'installer un jeu ça doit bien etre capable d'installer une appli quelconque, non ?

      • [^] # Sus à la caballe

        Posté par  (site web personnel) . Évalué à 2.

        Et pourquoi le SMS il est tout scoré négativement? C'était un avis tout à fait intéressant, non dénué de sens, pas con du tout alors je m'insurge contre les personnes qui score négativement les gens rien qu'à la vue de leur ID. "On a à apprendre quelque chose de chacun" c'est pas de moi mais je sais plus de qui.
        Par contre SMS, le jour où tu sortiras un gris FUD ou une grosse connerie, je serai le premier à te mettre [-].

        A vot' bon coeur

    • [^] # Re: Que pour Java :-(

      Posté par  . Évalué à 10.

      Comme c'est un installateur fait en Java, son application la plus naturelle est d'installer des programmes Java.

      MAIS tu peux installer ce que tu veux avec ...

      • [^] # Re: Que pour Java :-(

        Posté par  . Évalué à 5.

        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.

        Comme c'est un installateur fait en Java, son application la plus naturelle est d'installer des programmes 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.

        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 ( http://www.izforge.com/izpack/index.php3?content=references(...) ) semblent être des programmes Java.

        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.

        • [^] # Re: Que pour Java :-(

          Posté par  . Évalué à 10.

          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 :-)

          En espérant avoir répondu à tes questions ...

          • [^] # Re: Que pour Java :-(

            Posté par  (site web personnel) . Évalué à -5.

            Je vais encore me faire descendre en flammes mais si c'est un auto-exécutable (donc risque de virus) et que ça ne gère pas les dépendances, mais qu'est-ce que c'est que cette m..de?

            • [^] # Re: Que pour Java :-(

              Posté par  . Évalué à 0.

              Autoexécutable ? Pas vraiment.

              Risque de Virus ? Quand tu respires dans l'air il y a risque de virus aussi. Là je ne vois pas de 'risque' particulier. Bien sur on peut s'amuser à en mettre un dedans, comme on peut mettre des chevaux de troie dans des sources (cf openssl).

              Pour le reste, tu n'as qu'à essayer, tu comprendra peut-etre mieux, qui sait ?

          • [^] # Re: Que pour Java :-(

            Posté par  . Évalué à 6.

            Sur un Windows par exemple, tu es bon pour te payer un scan du disque :-/

            Un scan de la base de registre devrait suffire, encore que je ne sais pas si c'est possible avec Java. Et je ne sais pas si "non polluant" et "base de registres" sont compatibles.
            Par exemple, pour savoir où sont normalement installés les programmes, je pense qu'on devrait consulter HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\SFC\ProgramFilesDir.

            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.

            C'est clair que c'est compliqué, mais ça devient indispensable. Un programme qui aurait besoin de kde3 et pas de kde2 ou des lib java1.3 et pas java 1.1 devrait réclamer avant de s'installer.

            Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?

            Mais si tu trouves une méthode efficace (style en O(0.5))

            C'est quoi "en O(0.5)"?

            • [^] # Re: Que pour Java :-(

              Posté par  . Évalué à 5.

              Un scan de la base de registre devrait suffire, encore que je ne sais pas si c'est possible avec Java. Et je ne sais pas si "non polluant" et "base de registres" sont compatibles.

              La base de registre n'est pas accessible directement en Java, il faut passer par des librairies natives. Pour le support des raccourcis sauce Windows, on a été obligé d'en arriver là :-/ En meme temps on a bien limité la casse et on écrit rien dans la base de registre et au final IzPack reste bien "non polluant" sur un système Win32. De plus le support des raccourcis (et donc le besoin d'une librairie native) est optionnel. En meme temps, rien ne garanti qu'un soft aura une entrée dans la base de registre. Par exemple si tu dépend de Tomcat, il faut le chercher sur le disque, pas dans la base de registre. Donc au final c'est un problème assez compliqué :-/


              Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?

              On peut considérer que si on cherche un fichier en particulier pour tester la présence d'un logiciel, les différentes versions seront différentes. Par exemple si je cherche la présence de Jakarta Ant, je vais chercher un fichier nommé "ant.jar". C'est lui qui contient les classes Java de Ant, donc d'une version à l'autre il est forcémment différent. Donc sa signature MD5 sera différente. Pour que l'on ait un conflit de signatures (2 fichiers différents avec la meme signature), la probabilité est très faible. Un MD5 permettrait donc d'identifier une version de fichier. Est-ce raisonnable de stocker différentes signatures ? Non :-) Tout ça pour dire que ce style de dépendance est très difficile à vérifier. Tout ce que l'on peut faire est implémenter des heuristiques assez lourdes, ce n'est pas très raisonnable.

              C'est quoi "en O(0.5)"?

              C'est quelque chose d'impossible :-) Plus sérieusement, reportes-toi à un cours de complexité algorithmique. Des exemples, meme si c'est hors-sujet :


              
a = 2 + b;
              
c = (a == 3) ? (5 * x) : 0;

              Est de complexité O(1)


              
for (i = 0; i < 100; ++i)
              
  std::cout << "Coucou !" << endl;

              Est de complexité O(n)

              • [^] # Déterminer la version d'une bibliothèque Java

                Posté par  . Évalué à 5.

                En ce qui concerne la version d'une bibliothèque Java, il existe des champs prévus à cet effet dans META-INF/MANIFEST.MF (pour ceux qui ne connaissent pas Java, il s'agit du fichier décrivant l'archive Java, et entre autre quelle est la classe principale dans le cas d'un jar auto-exécutable).

                Tous les détails se trouvent ici : http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningS(...)

                Voici un exemple tiré de la page ci-dessus :
                Manifest-version: 1.0
                
Name: java/util/
                
Specification-Title: Java Utility Classes
                
Specification-Version: 1.3
                
Specification-Vendor: Sun Microsystems Inc.
                
Implementation-Title: java.util
                
Implementation-Version: build57
                
Implementation-Vendor: SunMicrosystems. Inc.


                Si l'on obtient un instance de Package décrivant le paquet en question (java.util dans notre exemple), les méthodes getImplementationVersion() et getSpecificationVersion() vont nous retourner respectivement "build57" et "1.3". Voir : http://java.sun.com/j2se/1.4/docs/api/java/lang/Package.html(...)

                Bien sûr, le problème est que tout le monde ne connait pas l'existence de cette gestion des versions, et qu'en pratique c'est très peu utilisé. Mais dans le cas où c'est fait correctement, si on peut localiser le jar ou s'il est placé dans le répertoire des extensions, on peut l'utiliser.

            • [^] # Re: Que pour Java :-(

              Posté par  . Évalué à 5.

              J'oubliais un truc !

              Pour les dépendances, ce qui simplifierait les choses ce serait d'avoir une base de donnée de packages installées dans tous les OS existants, comme c'est le cas dans beaucoup de distros Linux (Gentoo, Mdk, Debian, etc). Tu l'interroges et tu peux résoudre de suite les problèmes de compatibilité. Mais ça n'est pas le cas malheureusement, y compris pour les distros Linux qui n'ont pas toutes un système de gestion de packages. Pour Windows n'en parlons meme pas :-)

        • [^] # smlurph

          Posté par  . Évalué à -3.

          Encore un dialecte de ML fondé sur SML ?
          L'époque sera ML (SML, o'caml ...) ou ne sera pas !

          -1 et ----> []

  • # RPM/DEB KILLER?

    Posté par  (site web personnel) . Évalué à -6.

    Heu, je ne comprends pas bien, ç'est un concurrent aux packages rpm et deb ?

    • [^] # Re: RPM/DEB KILLER?

      Posté par  . Évalué à -7.

      pas du tout efface

      hop -1

    • [^] # Re: RPM/DEB KILLER?

      Posté par  . Évalué à 10.

      Non rien à voir du tout ...

      C'est une solution de déploiement multiplateformes, dont l'utilisation la plus courante est les logiciels Java.

      RPMs et Debs n'ont rien à voir avec IzPack ...

      • [^] # Re: RPM/DEB KILLER?

        Posté par  (site web personnel) . Évalué à 1.

        Pour moi, un installateur permet de choisir ce que l'on veut installer, ou on veut l'installer. C'est ensuite lui qui verifie si c'est possible.

        Il me semble donc que cet outil fait une part des boulots effectues par RPM/DEB. En tout cas, je ne vois pas comment on peut faire un installateur multi-plateforme en prenant en compte aussi bien RPM, DEB, tar.gz, etc.

        • [^] # Re: RPM/DEB KILLER?

          Posté par  . Évalué à 2.

          Le gestionnaire de packages de KDE s'en sort assez bien, pour ce qui est de la gestion des DEB/apt, et des RPM, sur de nombreuses distributions et architectures

    • [^] # Re: RPM/DEB KILLER?

      Posté par  . Évalué à 10.

      Non, c'est plutot un concurrent à Install Anywhere et consorts.

    • [^] # Re: RPM/DEB KILLER?

      Posté par  (site web personnel) . Évalué à -10.

      Inutile de me coller des [-], je pause juste une question >:o(

  • # Enfin !

    Posté par  . Évalué à 9.

    Enfin un installeur Java qui a l'air vraiment bien ! Ça faisait longtemps que je voulais un logiciel du genre pour mes projets Java ... (enfin, je devrais peut-être le tester avant de me réjouir, mais d'après les screenshots et la description ça semble tout à fait correct)

    Alors longue vie à IzPack !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.