Publicité
+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 9 sur 9
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro Hinault Romaric
    Consultant
    Inscrit en
    janvier 2007
    Messages
    3 909
    Détails du profil
    Informations personnelles :
    Nom : Homme Hinault Romaric
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 3 909
    Points : 57 513
    Points
    57 513

    Par défaut Oracle introduit la création des packages natifs dans JavaFX 2.2

    Oracle introduit la création des packages natifs dans JavaFX 2.2
    permettant d’exécuter une application sans dépendances externes


    Oracle a annoncé que JavaFX 2.2, sa solution pour la création d'applications internet riches (RIA), pourra être empaquetée en natif pour diverses plateformes.

    Cette nouvelle possibilité permettra aux développeurs de créer des applications qui pourront être installées et exécutées sans nécessiter de dépendances externes comme JRE ou encore le SDK FX.

    Le système "native package" pour les applications JavaFX fonctionne en créant un wrapper de votre application JavaFX, comprenant le code de l’application et les ressources, le runtime Java et JavaFX, le « launcher » d’application natif et autres métadonnées (icônes, etc).

    La création des packages se fera via l'utilitaire en ligne de commande javafxpackager.

    Le support de cette nouveauté est déjà intégré dans la Developer Preview de Java 7 Update 6 build 14 qui embarque JavaFX 2.2. Les autres mécanismes disponibles pour la publication des applications Java ne seront pas pour autant obsolètes.

    Cette nouvelle possibilité sera disponible pour les applications exe et msi sous Windows, dmg sous Mac et enfin les programmes d’installation rpm et zip pour les systèmes Linux.

    L’équipe de JavaFX espère également que ce nouveau système d’empaquetage en natif pourra être disponible pour les futures applications Java SE, construites avec Swing ou AWT.

    En dehors de la taille du programme d’installation qui augmente à cause de l’inclusion du JRE et du SDK Java FX, un autre inconvénient de cette nouveauté est que les packages ne peuvent être créés que sur les plateformes ciblées.


    Source : Oracle
    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog Mes articles
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre Expert
    Avatar de la.lune
    Homme Profil pro Bilal Soidik
    Ingénieur développement logiciels
    Inscrit en
    décembre 2010
    Messages
    514
    Détails du profil
    Informations personnelles :
    Nom : Homme Bilal Soidik
    Localisation : Comores

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2010
    Messages : 514
    Points : 1 949
    Points
    1 949

    Par défaut

    La question que je me pose si ça serait possible de paramétrer qu'au cas où un JRE serait déjà installé de pouvoir choisir de ne pas installer la JRE et donné juste le répertoire ou bien que le programme le détecte automatiquement comme les autres application en Java s'il est indiqué dans le variables d’environnement, ce qui permettra d'optimiser la taille du programme d'installation.

    En tout cas un déploiement en natif tout en un (servi comme du café) est une chose extrêmement intéressante pour les développeurs en Java. Car distribuer les application java était très simple(un simple .jar) mais pour faire un truc d'habitude pour un utilisateur lamda il fallait chercher un luncher et un installateur et commencer à faire tout à la manuellement, mais maintenant tout serait fait avec le JDK c'est une nouvelle qui m'a jouit vraiment quand je l'ai lu pour la première fois.

  3. #3
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 719
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 719
    Points : 6 864
    Points
    6 864

    Par défaut

    Citation Envoyé par la.lune Voir le message
    La question que je me pose si ça serait possible de paramétrer qu'au cas où un JRE serait déjà installé de pouvoir choisir de ne pas installer la JRE et donné juste le répertoire ou bien que le programme le détecte automatiquement comme les autres application en Java s'il est indiqué dans le variables d’environnement, ce qui permettra d'optimiser la taille du programme d'installation.
    Ca m'étonnerait pas mal qu'ils offrent ce choix...

    L'intérêt je pense est de pouvoir livrer justement livrer le programme avec la JRE sur laquelle tu as développé en standalone et ainsi justement s'affranchir de la dépendance sur le poste client et de la version de celle-ci.
    En cela je doute qu'il soit possible d'opter pour un mix des deux (mode jre embarqué et mode jre client) car ça reviendrait à livrer 2 applications différentes. Cependant, c'est possible qu'un logiciel tiers style installshield permette de le faire moyennant un peu de configuration (déployeur minimal puis téléchargement d'une version ou l'autre).

    Sinon l'idée est pas mal mais ce genre de produit existait déjà, il est déjà possible de bundler une jre avec son application et de démarrer avec un bootstrapper natif. Reste que c'est très bien que ce soit officiellement supporté pour les canaux de déploiement du style app market qui n'ont pas de gestion de dépendances centralisées.

  4. #4
    Expert Confirmé
    Avatar de kolodz
    Homme Profil pro Patrick Kolodziejczyk
    Développeur informatique
    Inscrit en
    avril 2008
    Messages
    901
    Détails du profil
    Informations personnelles :
    Nom : Homme Patrick Kolodziejczyk
    Âge : 27
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : avril 2008
    Messages : 901
    Points : 2 986
    Points
    2 986

    Par défaut

    J'ai déjà eu le cas du déploiement d'une application Java où les postes n'avais pas Java.
    L'installateur lançait la mise à jour / installation de JRE. C'était dépendant d'une connexion internet, mais ça se passait bien.

    Cordialement,
    Patrick Kolodziejczyk.
    N'oubliez pas de marquer vos discussions
    Si une réponse vous a été utile pensez à voter Pour
    Pensez à la javadoc

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    avril 2009
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : avril 2009
    Messages : 170
    Points : 208
    Points
    208

    Par défaut

    Il y a une question que je me posais:

    Est ce que on peut package plusieur applications .jar independante ensemble avec la meme JRE ?

    edit:
    un autre inconvénient de cette nouveauté est que les packages ne peuvent être créés que sur les plateformes ciblées.
    très dommage pour l'instant

  6. #6
    Rédacteur/Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 508
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 38
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 508
    Points : 9 845
    Points
    9 845

    Par défaut

    Mouai, j'ai installe le JDK 1.7.0_06 b20 64bit*, j'ai modifié NB7.2 pour qu'il démarre sur ce JDK et défini une nouvelle plateforme Java utilisant ce JDK + les runtimes FX qu'il contient (apparemment FX 2.2 b18) et ai modifié mon projet pour qu'il repose sur cette plateforme et rajouté dans mon build.xml (comme indiqué ici) :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
        <!-- FB : JavaFX - native packager builder - start -->
        <target name="-post-jfx-deploy">
           <fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" 
                     nativeBundles="all"
                     outdir="${basedir}/${dist.dir}" outfile="${application.title}">
              <fx:application name="${application.title}" mainClass="${javafx.main.class}"/>
              <fx:resources>
                  <fx:fileset dir="${basedir}/${dist.dir}" includes="MFCL-viewer-j.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="MFCL-chart.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="MFCL-IO.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="OFP-core2.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="OFP-fx2.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="ScenicView.jar"/>
              </fx:resources>
              <fx:info title="${application.title}" vendor="${application.vendor}"/>
            </fx:deploy>          
        </target>    
        <!-- FB : JavaFX - native packager builder - end -->
    Et j'ai droit a

    Code :
    1
    2
    3
    4
    5
    6
    7
     
    Launching <fx:jar> task from C:\Program Files\Java\jdk1.7.0_06\lib\ant-javafx.jar
    Launching <fx:deploy> task from C:\Program Files\Java\jdk1.7.0_06\lib\ant-javafx.jar
    Using base JDK at: C:\Program Files\Java\jdk1.7.0_04\jre
      Skip [Windows Application Bundler] due to [Java Runtime does not include lib\jfxrt.jar]
      Skip [MSI Bundler (WiX based)] due to [Java Runtime does not include lib\jfxrt.jar]
      Skip [Exe Bundler (based on Inno Setup)] due to [Java Runtime does not include lib\jfxrt.jar]
    Je me demande bien d’où il choppe qu'il doit utiliser le JDK 1.7.0_04...
    Bref, c'est pas encore ça

    *Ce qui au passage fait que SceneBuilder ne fonctionne plus car il ne reconnait pas le JRE 1.7.0_06 b20 64bit.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  7. #7
    Membre confirmé
    Inscrit en
    novembre 2004
    Messages
    129
    Détails du profil
    Informations personnelles :
    Âge : 33

    Informations forums :
    Inscription : novembre 2004
    Messages : 129
    Points : 299
    Points
    299

    Par défaut

    j'avais des soucis avec ça sous Linux.. va jeter un oeil dans ton fichier etc/netbeans.conf (dans le repertoire d'installation), t'as une variable netbeans_jdkhome qui te permet de définir le JDK par défaut... le probleme vient p'tet de là.

    En tout cas, je sais que Netbeans 7.1, sous linux, utilise toujours ce JDK pour les projets Freeform, et ce même si tu modifies les propriétés de ton projet...

    Teo

  8. #8
    Rédacteur/Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 508
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 38
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 508
    Points : 9 845
    Points
    9 845

    Par défaut

    Non, j'ai fini par trouver que le JDK 1.70_04 était encore référencé malgré une désinstallation complète.

    Au final, c’était un mix d'entre le fait que j'avais édité C:\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf sans passer en admin et donc que
    <mon compte>\appdata\local\virtual store\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf referencait le JDK 1.70_06 tandis que C:\Program Files (x86)\NetBeans 7.2\etc\netbeans.conf referencait le JDK 1.70_04... et donc NetBeans utilisait alternativement soit l'un soit l’autre des JDK.
    Stupide stupide Windows...

    Donc après lecture du post blog et du guide de références et quelques tests (JDK 1.7.0_06 b21 + JFX 2.2 b19 qui est inclus dedans), j'ai pu rajouter une tache en fin de mon build.xml :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
        <target name="-post-jfx-deploy">
           <fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" 
                     nativeBundles="all"
                     embedJNLP="true"
                     outdir="${basedir}/${dist.dir}" outfile="${application.title}">
              <fx:application id="mainApplication" name="${application.title}" mainClass="${javafx.main.class}"/>
              <fx:info title="${application.title}" description="${application.desc}" vendor="${application.vendor}">
                  <fx:icon href="${basedir}/Hei_Matau.ico" kind="default" width="64" height="64" depth="32"/>
              </fx:info>
              <fx:platform id="mainPlatform" javafx="2.2" j2se="7.0">
                  <fx:jvmarg value="-server"/>
                  <fx:jvmarg value="-XX:+UseG1GC"/>
              </fx:platform>
              <fx:resources>
                  <fx:fileset dir="${basedir}/${dist.dir}" includes="MFCL-viewer-j.jar"/>
                  <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="*.jar"/>
              </fx:resources>
            </fx:deploy>          
        </target>
    Ce qui produit le répertoire dist/bundle avec :
    • Répertoire bundle
      • le fichier MSI (nécessite Wix sur le PATH sinon ce n'est pas généré). Dans mon cas 47Mo.
      • le setup wizard (nécessite Inno Setup sur le PATH sinon ce n'est pas généré). Dans mon cas 31Mo.
      • Répertoire <nom de l'application>
        • Un launcher natif Windows. Dans mon cas 97Ko.
        • son icône (actuellement l’icône par défaut 4Ko).
        • Répertoire app
          • le fichier de config du launcher package.cfg
            Code package.cfg :
            1
            2
            3
            4
            5
            mainjar=OFP-fx2.jar
            version=null
            app.id=mainApplication
            jvmarg.1=-server
            jvmarg.2=-XX:+UseG1GC
          • Une copie de tous les JARs du projet (main jar + dépendances). Dans mon cas 1Mo.
        • Répertoire runtime
          • une copie complète du JRE + runtimes FX. Actuellement 139Mo sur Windows.


    Tout n'est pas parfait cependant :
    • Je déconseille de mettre tout de suite Wix et Inno setup dans le PATH (ou alors commenter la tache -post-jfx-deploy dans build.xml) car on passe alors de quelques secondes pour la compilation d'un (petit) projet (compilation + génération et compression des JAR + regroupement pour le bundle natif) a plus d'une minute (génération du MSI et du setup wizard et j'ai même pas encore rajouté la signature numérique). Ça devient donc assez lourdingue a chaque fois qu'on veut tester son app.
    • Même si ma tache référence correctement des propriétés du projet NetBeans (${application.desc}, ${application.vendor}), elles semblent pour le moment être ignorées (voir le fichier package.cfg produit).
    • Les arguments de la VM eux sont correctement inclus dans package.cfg.
    • Le JNLP est généré correctement mais le launcher natif ne reçoit pas une bonne configuration : genre il a décrété que c'est un des JAR des dépendances qui devient le main jar de l'application et il insiste pour démarrer une classe qui est en fait un test dans cette même dépendance. Coté JNLP tout est décrit correctement par contre.
    • Idem l’icône définie pour l'app ne vient pas remplacer celle fournie par défaut par le native bundler. Idem ici aussi tout est correct dans le JNLP.
    • Dans les options de packaging du projet dans NetBeans j'ai demandé a ce que les JAR soient compressés (PACK200) mais c'est pas encore le cas apparemment.
    • Idem contrairement a NetBeans 7.1 pour le moment je n'arrive plus avec cette config a pré-compiler les CSS de FX en binaire.


    Faudra que je vois comment ca marche sous Linux et, pour le moment, je n'ai pas de MacOS sous la main pour voir comment ça marche (a noter qu'Oracle a poste ça concernant Mountain Lion qui se voit désormais dote d'une fonction GateKeeper qui semble marche de manière un peu similaire a l'UAC dans Windows).

    Bref, c'est pas encore ça , et ça fait un peu gros pour une app qui fait a la base 1Mo. Dommage que la modularisation soit encore repoussée a Java 9.

    En attendant, j'ai soumis le bug RT-23778 sur le Jira de JavaFX.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  9. #9
    Rédacteur/Modérateur
    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 508
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 38
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 508
    Points : 9 845
    Points
    9 845

    Par défaut

    Citation Envoyé par bouye Voir le message
    En attendant, j'ai soumis le bug RT-23778 sur le Jira de JavaFX.
    comme prévu, cela ne fonctionne pas correctement pour le moment quand on a plusieurs JAR contenant des JavaFX main-class dans le projet (NetBeans 7.0 et 7.1 avaient parfois des comportement similaire lorsque des projets JavaFX avaient de genre de dépendances également). Ce qui est d'autant plus gênant puisque NetBeans ne permet toujours pas de définir des JavaFX library (c-a-d des JAR sans application JavaFX dedans).
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •