Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Maxime Daniel
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332. Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332.
Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte
les entrées Class-Path: du manifeste.
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332. Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
remy
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332. Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar
à la main cela ne fct pas il ne trouve pas la lib
il faut que le jar lib soit dans le même répertoire et à l'extérieur du nouveau jar
MANIFEST.MF
Manifest-Version: 1.0 Created-By: MaPomme Main-Class: Main Class-Path: htmlparser.jar +retour chariot il parait que c'est important
jar cvfm Dico.jar ./MANIFEST.MF ./ java -jar Dico.jar
actuellement il n'est plus en ligne mais je peux le remettre
os ubuntu jdk java version "1.5.0_10" de sun
merci remy
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332.
Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte
les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar
à la main cela ne fct pas il ne trouve pas la lib
il faut que le jar lib soit dans le même répertoire et à l'extérieur du
nouveau jar
MANIFEST.MF
Manifest-Version: 1.0
Created-By: MaPomme
Main-Class: Main
Class-Path: htmlparser.jar +retour chariot il parait que c'est important
jar cvfm Dico.jar ./MANIFEST.MF ./
java -jar Dico.jar
actuellement il n'est plus en ligne mais je peux le remettre
Sauf erreur de ma part, ce pourrait être dû au bug eclipse N° 97332. Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar
à la main cela ne fct pas il ne trouve pas la lib
il faut que le jar lib soit dans le même répertoire et à l'extérieur du nouveau jar
MANIFEST.MF
Manifest-Version: 1.0 Created-By: MaPomme Main-Class: Main Class-Path: htmlparser.jar +retour chariot il parait que c'est important
jar cvfm Dico.jar ./MANIFEST.MF ./ java -jar Dico.jar
actuellement il n'est plus en ligne mais je peux le remettre
os ubuntu jdk java version "1.5.0_10" de sun
merci remy
Maxime Daniel
On 9 mar, 16:35, remy wrote:
Maxime Daniel a écrit :> Sauf erreur de ma part, ce pourrait être d û au bug eclipse N° 97332.
Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar à la main cela ne fct pas il ne trouve pas la lib
C'est au moment d'exploiter le jar que le bug joue.
Si vous avez un scénario très précis et que l'utilisation de l'anglais ne vous rebute pas, je vous engage à ouvrir un bug Eclipse. Je me ferai alors un devoir, et un plaisir, d'investiguer le problème plus avant. Si l'anglais pose problème, j'essayerai lundi de reproduire le problème et je vous tiendrai au courant.
On 9 mar, 16:35, remy <r...@fctpas.fr> wrote:
Maxime Daniel a écrit :> Sauf erreur de ma part, ce pourrait être d û au bug eclipse N° 97332.
Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte
les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar
à la main cela ne fct pas il ne trouve pas la lib
C'est au moment d'exploiter le jar que le bug joue.
Si vous avez un scénario très précis et que l'utilisation de l'anglais
ne vous rebute pas, je vous engage à ouvrir un bug Eclipse. Je me
ferai alors un devoir, et un plaisir, d'investiguer le problème plus
avant.
Si l'anglais pose problème, j'essayerai lundi de reproduire le
problème et je vous tiendrai au courant.
Maxime Daniel a écrit :> Sauf erreur de ma part, ce pourrait être d û au bug eclipse N° 97332.
Pour l'instant, le compilateur Java d'Eclipse ne prend pas en compte les entrées Class-Path: du manifeste.
c'est possible mais même quand je fais le jar à la main cela ne fct pas il ne trouve pas la lib
C'est au moment d'exploiter le jar que le bug joue.
Si vous avez un scénario très précis et que l'utilisation de l'anglais ne vous rebute pas, je vous engage à ouvrir un bug Eclipse. Je me ferai alors un devoir, et un plaisir, d'investiguer le problème plus avant. Si l'anglais pose problème, j'essayerai lundi de reproduire le problème et je vous tiendrai au courant.
remy
donc en gros et pour faire simple sans eclipse juste le jdk
mkdir testJar cd testJar
gedit Main.java
import unTest.*;
public class Main {
public static void main(String[] args) { System.out.println("Main 1"); Test t=new Test(); System.out.println(t.info()); }
} mkdir unTest cd unTest gedit Test.java
package unTest;
Public class Test {
String s; public Test() { s=new String("package unTest class Test"); } public String info() { return s+" fct info"; } }
cd .. javac Main.java java Main
Main 1 package unTest class Test fct info
gedit Manifest.mf
Manifest-Version: 1.0 Created-By: MaPomme Main-Class: Main
java -jar JarJar.jar Main 0 package unTest class Test fct info
donc tout est ok mais non...
cp JarJar.jar /home/remy/Desktop/ cd /home/remy/Desktop/ java -jar JarJar.jar Main 0 Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test at Main.main(Main.java:8)
donc je n'arrive pas a ecrire le 2 ime Manifeste si vous avez un idee
j'ai aussi essayer
CLASSPATH=. export CLASSPATH cd appli/ java -jar JarJar.jar Main 0 package unTest class Test fct info
cela fct par ce que le jar testJar.jar et present dans le repertoire appli et cela ne fct toujour pas si le Jar JarJar.jar et tous seul
cd /home/remy/Desktop/ java -jar JarJar.jar Main 0 Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test at Main.main(Main.java:8)
merci remy
donc en gros et pour faire simple sans eclipse juste le jdk
mkdir testJar
cd testJar
gedit Main.java
import unTest.*;
public class Main {
public static void main(String[] args)
{
System.out.println("Main 1");
Test t=new Test();
System.out.println(t.info());
}
}
mkdir unTest
cd unTest
gedit Test.java
package unTest;
Public class Test {
String s;
public Test()
{
s=new String("package unTest class Test");
}
public String info()
{
return s+" fct info";
}
}
cd ..
javac Main.java
java Main
Main 1
package unTest class Test fct info
gedit Manifest.mf
Manifest-Version: 1.0
Created-By: MaPomme
Main-Class: Main
java -jar JarJar.jar
Main 0
package unTest class Test fct info
donc tout est ok mais non...
cp JarJar.jar /home/remy/Desktop/
cd /home/remy/Desktop/
java -jar JarJar.jar
Main 0
Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test
at Main.main(Main.java:8)
donc je n'arrive pas a ecrire le 2 ime Manifeste
si vous avez un idee
j'ai aussi essayer
CLASSPATH=.
export CLASSPATH
cd appli/
java -jar JarJar.jar
Main 0
package unTest class Test fct info
cela fct par ce que le jar testJar.jar et present dans le repertoire
appli
et cela ne fct toujour pas si le Jar JarJar.jar et tous seul
cd /home/remy/Desktop/
java -jar JarJar.jar
Main 0
Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test
at Main.main(Main.java:8)
java -jar JarJar.jar Main 0 package unTest class Test fct info
donc tout est ok mais non...
cp JarJar.jar /home/remy/Desktop/ cd /home/remy/Desktop/ java -jar JarJar.jar Main 0 Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test at Main.main(Main.java:8)
donc je n'arrive pas a ecrire le 2 ime Manifeste si vous avez un idee
j'ai aussi essayer
CLASSPATH=. export CLASSPATH cd appli/ java -jar JarJar.jar Main 0 package unTest class Test fct info
cela fct par ce que le jar testJar.jar et present dans le repertoire appli et cela ne fct toujour pas si le Jar JarJar.jar et tous seul
cd /home/remy/Desktop/ java -jar JarJar.jar Main 0 Exception in thread "main" java.lang.NoClassDefFoundError: unTest/Test at Main.main(Main.java:8)
merci remy
remy
bon apres avoir écumé la toile
le fichier Manifest le champ Class-Path: fait reference à la variable CLASSPATH à l'extérieur du jar
et j'ai rien trouvé comme palliatif j'ai bien essayé de faire un .... Class classe = Class.forName("...."); Object obj = classe.newInstance(); ...
mais cela devient tres lourd puisque je n'ai pas accès au type de l'obj puisqu'il ne voit pas la class qui est dans le jar
donc en gros et ben tant pis ou unzip unJar.jar et jar cvfm....
remy
bon apres avoir écumé la toile
le fichier Manifest
le champ Class-Path:
fait reference à la variable CLASSPATH à l'extérieur du jar
et j'ai rien trouvé comme palliatif
j'ai bien essayé de faire un
....
Class classe = Class.forName("....");
Object obj = classe.newInstance();
...
mais cela devient tres lourd puisque je n'ai pas accès au type
de l'obj puisqu'il ne voit pas la class qui est dans le jar
donc en gros et ben tant pis
ou
unzip unJar.jar
et jar cvfm....
le fichier Manifest le champ Class-Path: fait reference à la variable CLASSPATH à l'extérieur du jar
et j'ai rien trouvé comme palliatif j'ai bien essayé de faire un .... Class classe = Class.forName("...."); Object obj = classe.newInstance(); ...
mais cela devient tres lourd puisque je n'ai pas accès au type de l'obj puisqu'il ne voit pas la class qui est dans le jar
donc en gros et ben tant pis ou unzip unJar.jar et jar cvfm....
remy
Maxime Daniel
Effectivement, la spec des fichiers jar parle seulement d'un chemin relatif par rapport à l'emplacement du fichier jar principal, mais ne dit rien par rapport à l'inclusion potentielle d'un fichier jar "subordonné". C'est probablement volontaire, les fichiers jars étant vus comme des briques de base de la livraison d'applications, par opposition à des unités plus macroscopiques (comme application, système, etc.). Dans un grand système, on cherche à minimiser le nombre de copies de jars qui rendent les mêmes services (ce qui arriverait très vite si chaque jar incluait sa propre version des librairies dont il a besoin). D'où aussi le découpage du JRE en plusieurs fichiers jars. Il existe des modèles de composants de plus haut niveau, dans Eclipse et ailleurs - comme OSGI, qui proposent des regroupements de grain plus gros. On s'applique toujours cependant à trouver un équilibre entre l'établissement d'un lien fort entre un code client et ses librairies (seule méthode garantissant que le système obtenu ressemble au système développé par le fournisseur - si on radicalise, chaque composant a alors sa propre copie de rt.jar) et la nécessité de maintenir le volume de code total dans des limites raisonnables (dans les exécutions à class loaders multiples, cela consiste à diminuer le nombre de copies de chaque classe ; dans les systèmes à class loader unique, il faut réussir à déterminer une version de chaque classe capable de répondre aux besoins de tous ses utilisants). Bon courage pour la suite.
Effectivement, la spec des fichiers jar parle seulement d'un chemin
relatif par rapport à l'emplacement du fichier jar principal, mais ne
dit rien par rapport à l'inclusion potentielle d'un fichier jar
"subordonné". C'est probablement volontaire, les fichiers jars étant
vus comme des briques de base de la livraison d'applications, par
opposition à des unités plus macroscopiques (comme application,
système, etc.). Dans un grand système, on cherche à minimiser le
nombre de copies de jars qui rendent les mêmes services (ce qui
arriverait très vite si chaque jar incluait sa propre version des
librairies dont il a besoin). D'où aussi le découpage du JRE en
plusieurs fichiers jars.
Il existe des modèles de composants de plus haut niveau, dans Eclipse
et ailleurs - comme OSGI, qui proposent des regroupements de grain
plus gros. On s'applique toujours cependant à trouver un équilibre
entre l'établissement d'un lien fort entre un code client et ses
librairies (seule méthode garantissant que le système obtenu ressemble
au système développé par le fournisseur - si on radicalise, chaque
composant a alors sa propre copie de rt.jar) et la nécessité de
maintenir le volume de code total dans des limites raisonnables (dans
les exécutions à class loaders multiples, cela consiste à diminuer le
nombre de copies de chaque classe ; dans les systèmes à class loader
unique, il faut réussir à déterminer une version de chaque classe
capable de répondre aux besoins de tous ses utilisants).
Bon courage pour la suite.
Effectivement, la spec des fichiers jar parle seulement d'un chemin relatif par rapport à l'emplacement du fichier jar principal, mais ne dit rien par rapport à l'inclusion potentielle d'un fichier jar "subordonné". C'est probablement volontaire, les fichiers jars étant vus comme des briques de base de la livraison d'applications, par opposition à des unités plus macroscopiques (comme application, système, etc.). Dans un grand système, on cherche à minimiser le nombre de copies de jars qui rendent les mêmes services (ce qui arriverait très vite si chaque jar incluait sa propre version des librairies dont il a besoin). D'où aussi le découpage du JRE en plusieurs fichiers jars. Il existe des modèles de composants de plus haut niveau, dans Eclipse et ailleurs - comme OSGI, qui proposent des regroupements de grain plus gros. On s'applique toujours cependant à trouver un équilibre entre l'établissement d'un lien fort entre un code client et ses librairies (seule méthode garantissant que le système obtenu ressemble au système développé par le fournisseur - si on radicalise, chaque composant a alors sa propre copie de rt.jar) et la nécessité de maintenir le volume de code total dans des limites raisonnables (dans les exécutions à class loaders multiples, cela consiste à diminuer le nombre de copies de chaque classe ; dans les systèmes à class loader unique, il faut réussir à déterminer une version de chaque classe capable de répondre aux besoins de tous ses utilisants). Bon courage pour la suite.
