Discussion :

[helene90]

Bonjour,

Je suis débutante en JAVA et souhaiterais un petit coup de main pour faire mon build.xml (Je suis également nouvelle sur le forum )

Je vous résume le problème lorsque je compile avec ant, le jar créé ne fonctionne pas et son contenu est différent du jar que me génére eclipse.

Le .jar créé m'inclus tous les .jar des biblio utilisées ce que ne fait pas eclipse, puisqu'eclipse ne va chercher que les .class qui l'interesse dans les lib utilisées.

Ci-dessous mon build.xml :

Code XML :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<?xml version="1.0"?>
 
<project name="all" default="all" basedir=".">
 
    <property name="src.home" value="${basedir}/src" />
    <property name="lib.dir" value="${basedir}/lib" />
    <property name="build.home" value="${basedir}/build" />
    <property name="jar.file" value="xxxx.jar" />
    <property name="main.class" value="main.Main" />
 
    <property name="compile.debug" value="true" />
 
 
    <!--  targets -->
 
    <target name="all" depends="distclean, jar" description="Clean build, then create the jars" />
 
    <target name="build">
        <mkdir dir="${build.home}" />
        <javac srcdir="${src.home}" destdir="${build.home}"
            includeantruntime="false" debug="${compile.debug}">
            <classpath>
                <fileset dir="${lib.dir}" includes="**/*.jar" />
            </classpath>
        </javac>
    </target>
 
    <target name="jar" depends="build" description="Create ${jar.file}">
        <jar destfile="${basedir}/${jar.file}" basedir="${build.home}">
            <fileset dir="${lib.dir}" includes="**/*.jar" />
            <manifest>
                <attribute name="Main-Class" value="${main.class}" />
            </manifest>
        </jar>
    </target>
 
    <target name="clean">
        <delete dir="${build.home}" failonerror="false" />
    </target>
 <target name="distclean" depends="clean">
	<delete file="${basedir}/${jar.file}" failonerror="false" />
    </target>
 
    <target name="doc">
        <echo message="toto" />
    </target>
 
</project>

Je craque meme apres avoir lu les differentes doc, je ne trouve pas le problème, comme ci les bibliotheques et les .class n'était finalement pas linké.

Merci de votre aide.

Helene

[Logan Mauzaize]

Bonjour
Je suis également nouvelle sur le forum

Bonjour et bienvenue à toi.

Je suis débutante en JAVA et souhaiterais un petit coup de main pour faire mon build.xml

Pas de soucis, il s'agit bien d'un forum d’entraide.

Je vous résume le problème lorsque je compile avec ant, le jar créé ne fonctionne pas

Je ne dirais pas que les choses ne fonctionnent pas mais plutôt qu'elles ne fonctionnent pas comme tu l'attendrais.

son contenu est différent du jar que me génére eclipse.
Le .jar créé m'inclus tous les .jar des biblio utilisées ce que ne fait pas eclipse, puisqu'eclipse ne va chercher que les .class qui l'interesse dans les lib utilisées.

A juste titre ! Il est fortement déconseillé de "désassembler" les librairies. Tu perds beaucoup d'information et notamment la provenance (éditeur, nom de la librairie, version utilisée). Et cela n'apporte rien.

Je craque meme apres avoir lu les differentes doc, je ne trouve pas le problème, comme ci les bibliotheques et les .class n'était finalement pas linké.

Il n'y a pas de link lors de la compilation en Java. Chaque ".class" peut être considéré comme une .dll/.so

Tu devrais regarder du côté de la propriété "Class-Path" du Manifest : http://docs.oracle.com/javase/tutori...r/downman.html

[bulbo]

Bonjour et Bienvenue par ici,

Les jars ne doivent pas se trouver dans un autre jar pour pouvoir être utilisés ainsi.

Tu as différents choix qui s'offrent à toi:

- Soit tu inclus dans ton jar les .class contenus dans les autres jar: bof et tu risques de ne pas être très compatible avec les licences des librairies externes que tu utilises.
Tu peux faire ça soit avec un plugin pour ant (One-Jar ou jarjar par exemple) soit manuellement en ajoutant des zipfileset à ta task ant qui crée ton jar.

- Soit tu t'arranges pour distribuer ton jar et à coté les jars externes que tu utilises (NetBeans par exemple les copie dans un répertoire lib qui sera distribué en même temps que le jar de l'application.
Les avantages:
* plus de problème de licences
* une nouvelle version de ton appli sans changement des dépendances c'est juste un petit jar à reprendre
* on peut upgrader une librairie externe (si l'API ne change pas) sans tout recompiler

Voilà,

Bulbo

[helene90]

Merci pour vos reponses

J'utilise un zipfileset pour tout mes .jar et ca marche, y'aurait il un moyen plus generale de generer mon .jar sans avoir a ecrire

<zipfileset src="XXXX.jar">
<zipfileset src="YYYY.jar">
<zipfileset src="ZZZZ.jar">

Merci.

[tchize_]

Les jars ne doivent pas se trouver dans un autre jar pour pouvoir être utilisés ainsi.

Tu as différents choix qui s'offrent à toi:

Tu semble oublié l'option prise par eclipse: des jar dans le jar, avec un classloader maison pour gérer tout ça. Ca évite à la fois d'exploser les jar pour les recompacter ensemble après, et ça permet de garder fonctionnel les notions de service, licence, etc. Par contre, je suis étonné, il me semblait que ça devait être intégré dans java 7, mais aucune trace....

[bulbo]

Tu semble oublié l'option prise par eclipse: des jar dans le jar, avec un classloader maison pour gérer tout ça. Ca évite à la fois d'exploser les jar pour les recompacter ensemble après, et ça permet de garder fonctionnel les notions de service, licence, etc. Par contre, je suis étonné, il me semblait que ça devait être intégré dans java 7, mais aucune trace....

Désolé je ne suis pas du tout l'actu Eclipse, je suis passé sur NetBeans il y a bien longtemps

Dans tous les cas, j'aime pas trop l'approche du classloader dédié, même si le packaging est plus "propre", ya un coût en perfs et ça c'est bof bof, sans parler des possibles side effect suivant les frameworks embarqués etc etc..

Bulbo

[tchize_]

Le sides effects: pas convaicu: ce classloader étends urlclassloader, et apparait comme étant l'unique classloader existant auprès de l'application. Et pour les perfs.... Je vois pâs où serait la perte

Me semblati d'ailleurs que netbeans avait un système similaire, vu leur tendance à faire les même choses entre eux deux

[bulbo]

NetBeans colle toutes les dépendances externes dans un répertoire dist/lib à la compilation.

Pour les performances, un-jarer les jars du jar principal puis un-jarer la classe que l'on veut charger, il y a des chances que ce soit plus long que la version ou on un-jar seulement une fois.

Idem si on fait un getResource ou un getResourceAsStream, la recherche va être plus lente forcément.

Autre point, quelle va être l'URL retournée par un getResource ? Pas sur que cela n'ai pas un impact sur le code qu'il faudrait écrire pour accéder à une telle ressource par son URL.

Et finalement, dans le cadre d'une applet signée (ou jnlp), les jars internes seront ils considérés comme signés vu leur inclusion dans un jar signé, ou faudra t'il les signer avant leur inclusion ?

Bulbo

[tchize_]

Ben, tout simplement:

machin.jar!/META-INF/lib/truc.jar!/com/company/.... Le URLs gèrent déjà ça en base il me semble.

Déjarrer deux fois, ok ça a peut être un léger impact, mais si il était important, il serait le même que l'impact entre déjarrer 1 fois et tout exploser => Tout le monde explioserait tout. De plus, t'as un seul file handle, au lieu d'en avoir un centaine sur une grosse app. Y a du gain là, au contraire

Edit: ha ben non, c'est de la forme

jar:rsrc:librairieX.jar!/path/in/library

[bulbo]

Ben, tout simplement:
...
jar:rsrc:librairieX.jar!/path/in/library

Humm super simple tout ça en effet

Et dans un type de packaging tu as ce truc qui nécessite un processing spécial et/ou librairie pour accéder au fichier et dans l'autre tu as une URL standard et comprise de base par l'API ..

Et pour ce qui est du coup du File handle unique pour une grosse appli .. tu penses que du coup tout extraire en mémoire est un plus ?

Bulbo

[tchize_]

Pourquoi tout serait extrait en mémoire? C'est pas comme ça que marche les classloader. Ils extraient à la demande. De la même manière que pour une applet on charge pas toutes les ressoures distantes, juste ce qui est nécessaire.

Quand aux url, ben désolé, mais en java, les URLHandler, c'est standard et transparent. Si j'ai envie de créer des urls de type zip: je peux. D'ailleurs, jboss ne se prive pas avec ses classpath: comme urls


Bref, mon point de base était: c'est possible de tout mettre dans un seul jar, les jar dans les jars c'est possible, et ça coute pas cher à mettre en place (dans eclipse). Après il y a surement des cas borderline où ça ne passe pas. Comme ça ne passe pas parfois non plus quand on package sa classe dans un jar simple.

[bulbo]

Et mon point de base était que je ne suis guère fan, je crains que l'on ne tombe pas d'accord sur ce point

Par contre en y repensant je me demande si une telle approche reste valide pour une applet signée ...
Comment le gestionnaire de sécurité va-t'il considérer les jars internes ? Sont-ils signés ? Doit-on les signer individuellement avant et est-ce qu'Eclipse s'en occupe automatiquement ?

[tchize_]

Je vois mal l'intérêt de ce truc pour un applet. L'intérêt pour moi, c'est pour une appli desktop, où t'as juste le jar à fournir au user, et ça fonctionne en un coup de double clic. Si t'es capable de signer des jar, de mettre une applet sur un serveur web et de faire le html, t'es bien capable d'ajouter les librairies en dépendances dans le archive="..." du html

[bulbo]

C'était juste pour ma culture, pour moi du moment que tu fournis ce genre de packaging, il paraîtrait logique de supporter l'ensemble de l'eco-system.

En même temps avec les nouvelles normes de sécu qui vont entrer en vigueur avec la release 1.7.0u51, ce genre de déploiement (jarinjar) s'il marchait pour une applet pourrait se révéler du pain béni.
Perso je trouve complètement crétin de devoir mettre le nom de l'application dans mes jars externes sous peine d'avoir un warning par classe chargée depuis ces jars.. Oracle a fait fort sur ce coup là..

Bon je vais m'arrêter là, le problème initial est résolu si je ne m'abuse et je ne pense pas qu'on apportera une quelconque valeur ajoutée à la solution au final

Bulbo

[tchize_]

C'était juste pour ma culture, pour moi du moment que tu fournis ce genre de packaging, il paraîtrait logique de supporter l'ensemble de l'eco-system.

Le export as jar de eclipse ne génère déjà pas la signature. Mais à priori, je dirais que c'est le jar in jar qui doit être signé, et non pas chaque classe à l'intérieur dudit jar, puisque

C'est vu comme un ressource dans le jar principal
La vérification des signature se fait au chargement desdit jars par l'applet


De la même manière, si je génère du code avec cglib à la volé, ce code n'a pas à être signé

[Mickael_Istria]

Tu semble oublié l'option prise par eclipse

C'est pas Eclipse, c'est du OSGi avec des nested jars.
C'est quand meme considere comme un truc un peu crade en general, a eviter autant que possible.

[tchize_]

Heu non, y a pas d'OSGI impliqué quand tu fais "package required libraries into generated jar". Ou alors OSGi occupe maintenant moins de 10k et se cache vachement bien dans l'application générée. Ne pas confondre le jar généré par file -> export et l'architecture même d'eclipse ou des procjets basés sur eclipse rcp qui utilisent OSGi

[Mickael_Istria]

Ne pas confondre le jar généré par file -> export et l'architecture même d'eclipse ou des procjets basés sur eclipse rcp qui utilisent OSGi

Deformation professionnelle