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

[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