Apr=E8s moults recherches infructeuses, je me d=E9cide =E0 poster ici mon
probl=E8me. Certes, pas pr=E9cis=E9ment li=E9 au langage Java mais un peu
d'aide serait grandement appr=E9ci=E9e.
Sous Eclipse (3.2) j'ai d=E9velopp=E9 un certain nombre de classes
ventil=E9es dans des jars lesquels sont cr=E9=E9s par le menu contextuel
Export des projets.
Quand je teste mes classes depuis Eclipse tout fonctionne correctement.
En revanche lorsque ces jar sont utilis=E9s dans d'autres projets sur un
autre environnement Eclipse =E7a part en sucette.
Exemple avec le code suivant qui a un comportement =E9trange :
// Localisation du fichier xsd adequat...
URL ficDTDURL =3D this.getClass().getResource(NOM_FIC_XSD);
File schemaLocation =3D new File(ficDTDURL.getFile());
// ... puis on construit un nouveau schema de validation
schema =3D factory.newSchema(schemaLocation);
La derni=E8re instruction g=E9n=E8re l'=E9xception suivante :
org.xml.sax.SAXParseException: schema_reference.4: Failed to read
schema document
'file:///D:/eclipse/file:/C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b=
2b/xml/FicCde.xsd',
because
1) could not find the document;
2) the document could not be read;
3) the root element of the document is not <xsd:schema>.
La derniere instruction semble ajouter le path D:/eclipse/file au
chemin d'acc=E8s du jar sans qu'on sache pourquoi alors que
'schemaLocation' pointe sur le bon chemin
(C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd).
J'ai tent=E9 de r=E9soudre le probl=E8me en faisant : schema =3D
factory.newSchema(schemaLocation.getAbsolutePath()) et schema =3D
factory.newSchema(schemaLocation.getCanonicalPath()) mais =E7a ne change
rien.
L'environnement Eclipse sur lequel =E7a ne marche pas a pourtant
exactement les m=EAmes buildpath (mis =E0 jour dans les propri=E9t=E9s du
projet depuis Eclipse) que le mien.
Ce probleme que je n'arrive pas =E0 r=E9soudre semble faire parti d'un
ensemble d'autres probl=E8mes que j'ai rencontr=E9s lors de l'appel de
classes contenues dans les jars (NoClassDefFound,
'this.getClass().getResource(NOM_FIC)' qui renvoit un null etc.),
appels qui fonctionnent parfaitement sur l'environnement dans lequel
les classes ont =E9t=E9 d=E9velopp=E9es mais qui posent soucis ailleurs.
Une id=E9e pour r=E9soudre mon probl=E8me ?
Merci d'avance.
K
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
TestMan
Bonjour,
Après moults recherches infructeuses, je me décide à poster ici mon problème. Certes, pas précisément lié au langage Java mais un peu d'aide serait grandement appréciée. Sous Eclipse (3.2) j'ai développé un certain nombre de classes ventilées dans des jars lesquels sont créés par le menu contextuel Export des projets. Quand je teste mes classes depuis Eclipse tout fonctionne correctement. En revanche lorsque ces jar sont utilisés dans d'autres projets sur un autre environnement Eclipse ça part en sucette. Exemple avec le code suivant qui a un comportement étrange :
// Localisation du fichier xsd adequat... URL ficDTDURL = this.getClass().getResource(NOM_FIC_XSD); File schemaLocation = new File(ficDTDURL.getFile()); // ... puis on construit un nouveau schema de validation schema = factory.newSchema(schemaLocation);
La dernière instruction génère l'éxception suivante : org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'file:///D:/eclipse/file:/C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
La derniere instruction semble ajouter le path D:/eclipse/file au chemin d'accès du jar sans qu'on sache pourquoi alors que 'schemaLocation' pointe sur le bon chemin (C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd). J'ai tenté de résoudre le problème en faisant : schema > factory.newSchema(schemaLocation.getAbsolutePath()) et schema > factory.newSchema(schemaLocation.getCanonicalPath()) mais ça ne change rien.
L'environnement Eclipse sur lequel ça ne marche pas a pourtant exactement les mêmes buildpath (mis à jour dans les propriétés du projet depuis Eclipse) que le mien. Ce probleme que je n'arrive pas à résoudre semble faire parti d'un ensemble d'autres problèmes que j'ai rencontrés lors de l'appel de classes contenues dans les jars (NoClassDefFound, 'this.getClass().getResource(NOM_FIC)' qui renvoit un null etc.), appels qui fonctionnent parfaitement sur l'environnement dans lequel les classes ont été développées mais qui posent soucis ailleurs.
Une idée pour résoudre mon problème ? Merci d'avance. K
Assurez vous que le fichier .xsd soit bien déployé dans le même paquet (=répertoire du JAR) que la classe correspondant au this.
A+ TM
Bonjour,
Après moults recherches infructeuses, je me décide à poster ici mon
problème. Certes, pas précisément lié au langage Java mais un peu
d'aide serait grandement appréciée.
Sous Eclipse (3.2) j'ai développé un certain nombre de classes
ventilées dans des jars lesquels sont créés par le menu contextuel
Export des projets.
Quand je teste mes classes depuis Eclipse tout fonctionne correctement.
En revanche lorsque ces jar sont utilisés dans d'autres projets sur un
autre environnement Eclipse ça part en sucette.
Exemple avec le code suivant qui a un comportement étrange :
// Localisation du fichier xsd adequat...
URL ficDTDURL = this.getClass().getResource(NOM_FIC_XSD);
File schemaLocation = new File(ficDTDURL.getFile());
// ... puis on construit un nouveau schema de validation
schema = factory.newSchema(schemaLocation);
La dernière instruction génère l'éxception suivante :
org.xml.sax.SAXParseException: schema_reference.4: Failed to read
schema document
'file:///D:/eclipse/file:/C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd',
because
1) could not find the document;
2) the document could not be read;
3) the root element of the document is not <xsd:schema>.
La derniere instruction semble ajouter le path D:/eclipse/file au
chemin d'accès du jar sans qu'on sache pourquoi alors que
'schemaLocation' pointe sur le bon chemin
(C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd).
J'ai tenté de résoudre le problème en faisant : schema > factory.newSchema(schemaLocation.getAbsolutePath()) et schema > factory.newSchema(schemaLocation.getCanonicalPath()) mais ça ne change
rien.
L'environnement Eclipse sur lequel ça ne marche pas a pourtant
exactement les mêmes buildpath (mis à jour dans les propriétés du
projet depuis Eclipse) que le mien.
Ce probleme que je n'arrive pas à résoudre semble faire parti d'un
ensemble d'autres problèmes que j'ai rencontrés lors de l'appel de
classes contenues dans les jars (NoClassDefFound,
'this.getClass().getResource(NOM_FIC)' qui renvoit un null etc.),
appels qui fonctionnent parfaitement sur l'environnement dans lequel
les classes ont été développées mais qui posent soucis ailleurs.
Une idée pour résoudre mon problème ?
Merci d'avance.
K
Après moults recherches infructeuses, je me décide à poster ici mon problème. Certes, pas précisément lié au langage Java mais un peu d'aide serait grandement appréciée. Sous Eclipse (3.2) j'ai développé un certain nombre de classes ventilées dans des jars lesquels sont créés par le menu contextuel Export des projets. Quand je teste mes classes depuis Eclipse tout fonctionne correctement. En revanche lorsque ces jar sont utilisés dans d'autres projets sur un autre environnement Eclipse ça part en sucette. Exemple avec le code suivant qui a un comportement étrange :
// Localisation du fichier xsd adequat... URL ficDTDURL = this.getClass().getResource(NOM_FIC_XSD); File schemaLocation = new File(ficDTDURL.getFile()); // ... puis on construit un nouveau schema de validation schema = factory.newSchema(schemaLocation);
La dernière instruction génère l'éxception suivante : org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'file:///D:/eclipse/file:/C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
La derniere instruction semble ajouter le path D:/eclipse/file au chemin d'accès du jar sans qu'on sache pourquoi alors que 'schemaLocation' pointe sur le bon chemin (C:/JAR/B2B/Java/lib/Etudes/gco.b2b.xml.jar!/gco/b2b/xml/FicCde.xsd). J'ai tenté de résoudre le problème en faisant : schema > factory.newSchema(schemaLocation.getAbsolutePath()) et schema > factory.newSchema(schemaLocation.getCanonicalPath()) mais ça ne change rien.
L'environnement Eclipse sur lequel ça ne marche pas a pourtant exactement les mêmes buildpath (mis à jour dans les propriétés du projet depuis Eclipse) que le mien. Ce probleme que je n'arrive pas à résoudre semble faire parti d'un ensemble d'autres problèmes que j'ai rencontrés lors de l'appel de classes contenues dans les jars (NoClassDefFound, 'this.getClass().getResource(NOM_FIC)' qui renvoit un null etc.), appels qui fonctionnent parfaitement sur l'environnement dans lequel les classes ont été développées mais qui posent soucis ailleurs.
Une idée pour résoudre mon problème ? Merci d'avance. K
Assurez vous que le fichier .xsd soit bien déployé dans le même paq uet (=répertoire du JAR) que la classe correspondant au this.
A+ TM
Merci pour la solution !!! Elle fonctionne. Il m'a suffit de supprimer la ligne : File schemaLocation = new File(ficDTDURL.getFile());
K.
Aurélien
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que je n'ai pas de sous mais je découvre ces derniers temps Maven 2 (http://maven.apache.org/) et c'est le bonheur, plus de souci de dépendances et de gestion des jars. Bref je vous le conseille fortement. Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Aurélien Barbier-Accary.
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que je n'ai
pas de sous mais je découvre ces derniers temps Maven 2
(http://maven.apache.org/) et c'est le bonheur, plus de souci de dépendances et
de gestion des jars.
Bref je vous le conseille fortement.
Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que je n'ai pas de sous mais je découvre ces derniers temps Maven 2 (http://maven.apache.org/) et c'est le bonheur, plus de souci de dépendances et de gestion des jars. Bref je vous le conseille fortement. Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Aurélien Barbier-Accary.
TestMan
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que je n'ai pas de sous mais je découvre ces derniers temps Maven 2 (http://maven.apache.org/) et c'est le bonheur, plus de souci de dépendances et de gestion des jars. Bref je vous le conseille fortement. Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Aurélien Barbier-Accary.
Bjr,
Maven est vraiment un bon outil mais pour les petits projets je préfère rester sur ant (plus focalisé sur la construction ou les taches unitaires).
Car le fort de Maven est surtout pratique pour de la gestion de projet. Et s'il est associé à une construction intégrée par exemple luntbuild (ou cruisecontrol, maven/continuum ou hudson) et c'est vraiment le pied :)
Attention, mettre en place un environement de projet vraiment intégré (subversion ou CVS + maven + luntbuild ou autre + fisheye ou statcvs ...) prend pas mal de temps et d'organisation.
Mais lorsqu'on commence un projet qui va durer au minimum 2 m-h, je trouve que celà vaut largement la peine. Et gagnera pas mal de temps par la suite.
A+ TM
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que
je n'ai pas de sous mais je découvre ces derniers temps Maven 2
(http://maven.apache.org/) et c'est le bonheur, plus de souci de
dépendances et de gestion des jars.
Bref je vous le conseille fortement.
Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Aurélien Barbier-Accary.
Bjr,
Maven est vraiment un bon outil mais pour les petits projets je préfère
rester sur ant (plus focalisé sur la construction ou les taches unitaires).
Car le fort de Maven est surtout pratique pour de la gestion de projet.
Et s'il est associé à une construction intégrée par exemple luntbuild
(ou cruisecontrol, maven/continuum ou hudson) et c'est vraiment le pied :)
Attention, mettre en place un environement de projet vraiment intégré
(subversion ou CVS + maven + luntbuild ou autre + fisheye ou statcvs
...) prend pas mal de temps et d'organisation.
Mais lorsqu'on commence un projet qui va durer au minimum 2 m-h, je
trouve que celà vaut largement la peine. Et gagnera pas mal de temps par
la suite.
Bon, je n'ai pas d'actions chez eux parce que c'est open source et que je n'ai pas de sous mais je découvre ces derniers temps Maven 2 (http://maven.apache.org/) et c'est le bonheur, plus de souci de dépendances et de gestion des jars. Bref je vous le conseille fortement. Et bien sûr il existe un plugin pour eclipse (lien sur la page indiquée).
Aurélien Barbier-Accary.
Bjr,
Maven est vraiment un bon outil mais pour les petits projets je préfère rester sur ant (plus focalisé sur la construction ou les taches unitaires).
Car le fort de Maven est surtout pratique pour de la gestion de projet. Et s'il est associé à une construction intégrée par exemple luntbuild (ou cruisecontrol, maven/continuum ou hudson) et c'est vraiment le pied :)
Attention, mettre en place un environement de projet vraiment intégré (subversion ou CVS + maven + luntbuild ou autre + fisheye ou statcvs ...) prend pas mal de temps et d'organisation.
Mais lorsqu'on commence un projet qui va durer au minimum 2 m-h, je trouve que celà vaut largement la peine. Et gagnera pas mal de temps par la suite.
