Eclipse "ne trouve pas le descripteur de bibliothèque de balises" pour les balises personnalisées (pas JSTL!)
J'ai un projet Java EE qui fonctionne bien avec Ant, se déploie parfaitement sur JBoss et s'exécute sans problème. Ce projet comprend quelques personnalités bibliothèques de balises (qui ne sont pas JSTL !), qui fonctionnent également sans aucune difficulté.
Le problème concerne Eclipse IDE (Ganymede)]: dans chaque fichier JSP qui utilise nos balises personnalisées, l’analyseur JSP signale la ligne d’inclusion de taglib avec l’erreur suivante:
Cannot find the tag library descriptor for (example).tld
Cela entraîne également le signalement de chaque utilisation de la bibliothèque d'onglets comme une erreur. Etant donné que IDE n'a pas de définition, il ne peut pas vérifier les paramètres de balise, etc.
Nos fichiers JSP, qui fonctionnent parfaitement, sont un océan d’erreurs rouges et mes yeux commencent à brûler.
Comment puis-je simplement dire à Eclipse: "Le descripteur de bibliothèque de balises que vous recherchez est" src/web/WEB-INF/(exemple) -taglib/(exemple) .tld "?
J'ai déjà posé cette question sur les forums de support Eclipse, sans résultat utile.
Il s’avère que la cause en était que ce projet n’était pas considéré par Eclipse comme un projet Java EE du tout; c’était un ancien projet de la version 3.1, et le projet Eclipse 3.5 que nous sommes). L’utilisation de now nécessite la définition de plusieurs "natures" dans le fichier de configuration du projet.
<natures>
<nature>org.Eclipse.jdt.core.javanature</nature>
<nature>InCode.inCodeNature</nature>
<nature>org.Eclipse.dltk.javascript.core.nature</nature>
<nature>net.sf.eclipsecs.core.CheckstyleNature</nature>
<nature>org.Eclipse.wst.jsdt.core.jsNature</nature>
<nature>org.Eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.Eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.Eclipse.jem.workbench.JavaEMFNature</nature>
</natures>
J'ai pu trouver la cause en créant un nouveau "projet Web dynamique" qui lisait correctement ses fichiers JSP et différait de la configuration du projet plus ancien.
La seule façon pour moi de les ajouter était en modifiant le fichier .project, mais après la réouverture du projet, tout a fonctionné comme par magie. Les paramètres référencés par pribeiro, ci-dessus, n'étaient pas nécessaires car le projet était déjà conforme aux paramètres par défaut.
Les réponses de pribeiro et de nitind m'ont donné des idées pour relancer ma recherche, merci.
Existe-t-il un moyen de modifier ces "natures" à partir de l'interface utilisateur?
Dans Eclipse Helios, "Dépendances du module Java EE" dans les propriétés du projet a été remplacé par "Assemblage de déploiement".
Donc, pour résoudre ce problème avec Eclipse Helios, voici comment je l’ai fait:
- Faites un clic droit sur le projet dans le paquet Explorer et choisissez "Importer ..."
- Acceptez la sélection par défaut "Système de fichiers" et appuyez sur "Suivant"
- Appuyez sur "Parcourir" dans la ligne de répertoire De, accédez à votre installation Tomcat et localisez le fichier webapps/examples/WEB-INF/lib (j'ai Tomcat 6, d'autres versions de Tomcat peuvent avoir le chemin webapps/jsp-examples/WEB- INF/lib). Une fois dans le chemin, appuyez sur OK.
- Cliquez à côté de jstl.jar et standard.jar pour activer les cases à cocher
- Sur la ligne Dans le dossier, cliquez sur Parcourir et choisissez le dossier de la bibliothèque. J'utilise/lib à l'intérieur du projet.
- Cliquez sur "Terminer"
- Faites un clic droit sur le projet dans la vue Explorateur de packages et choisissez les propriétés (ou appuyez sur Alt + Entrée).
- Cliquez sur "Java Build Path"
- Cliquez sur "Ajouter un fichier jar", cliquez sur votre projet, le dossier lib, sélectionnez jstl.jar, appuyez sur OK.
- Cliquez sur "Ajouter un fichier", cliquez sur votre projet, le dossier lib, sélectionnez standard.jar, appuyez sur OK.
- Appuyez sur OK pour fermer la boîte de dialogue des propriétés.
- Cliquez sur la vue Problèmes et sélectionnez le message "L'entrée de classpath .../jstl.jar ne sera ni exportée ni publiée. L'exécution de ClassNotFoundExceptions peut en résulter.".
- Faites un clic droit dessus et sélectionnez "Quick Fix".
- Acceptez la valeur par défaut "Marquez l’entrée de chemin de classe brute associée en tant que dépendance de publication/exportation" et cliquez sur Terminer.
- Faites la même chose pour standard.jar
Cela résout le problème, mais si vous voulez vérifier ce qui s'est passé dans "Deployment Assembly", ouvrez à nouveau les propriétés du projet, sélectionnez "Deployment Assembly" et vous verrez que standard.jar et jstl.jar ont été ajoutés à WEB- Dossier INF/lib.
C'était mon problème et comment je l'ai résolu ...
J'avais fait tout ce que tout le monde avait mentionné ci-dessus, etc., mais j'avais toujours cette erreur. Il s'avère que j'utilisais les uri's de http://Java.Sun.com/jsp/jstl/fmt et http://Java.Sun.com/jsp/jstl/core qui étaient incorrects.
Essayez de changer l'uris d'en haut pour:
http://Java.Sun.com/jstl/fmt
http://Java.Sun.com/jstl/core
Assurez-vous également que les fichiers JAR corrects sont référencés dans votre chemin de classe.
J'ai eu le même problème avec une rayures taglib URI montrant comme non trouvé. J'utilisais Indigo et Maven et lorsque j'ai coché Propriétés -> Chemin de construction Java -> Onglet Ordre et exportation, j'ai constaté (lors du paiement d'un nouveau projet) que la case "Dépendances Maven" avait été décochée pour une raison quelconque. En cochant simplement cette case et en effectuant une nouvelle installation Maven, toutes les erreurs ont été effacées.
Je me demande pourquoi Eclipse ne suppose pas que je veux mes dépendances Maven dans le chemin de compilation ...
Couru dans le même problème, j'utilise maven alors j'ai ajouté ceci à la pom de mon projet web:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version> <!-- just used the latest version, make sure you use the one you need -->
<scope>provided</scope>
</dependency>
Cela a résolu le problème et j'ai utilisé la portée "fournie" car, à l'instar de l'OP, tout fonctionnait déjà dans JBoss.
Voici où j'ai trouvé la solution: http://alfredjava.wordpress.com/2008/12/22/jstl-connot-resolved/
Lorsque j'ai essayé d'inclure la bibliothèque principale JSTL dans mon JSP:
<%@ taglib prefix="c" uri="http://Java.Sun.com/jsp/jstl/core" %>
J'ai eu l'erreur suivante dans Eclipse (Indigo):
Can not find the tag library descriptor for "http://Java.Sun.com/jsp/jstl/core"
Je suis allé dans les Propriétés du projet -> Runtimes ciblés, puis j'ai vérifié le serveur que j'utilisais (Geronimo 3.0). La plupart des gens utiliseraient Tomcat. Cela a résolu mon problème. J'espère que ça aide!
Cela dépend beaucoup du type de projet. Le support JSP de WTP s’attend à ce que les fichiers JSP se trouvent dans le même dossier que le dossier parent du dossier WEB-INF (src/web, qu’il traitera alors comme "/" pour trouver les TLD), ou à ce que les métadonnées du projet soient configurées de manière à: aidez-le à savoir où se trouve cette racine (effectué pour vous dans un projet Web dynamique via Deployment Assembly). Comment faites-vous référence au fichier TLD et où se trouve le fichier JSP?
Et peut-être ai-je manqué le message original sur les forums Eclipse; celui que j'ai vu a été posté un jour complet après celui-ci.
J'ai résolu ce problème aujourd'hui.
- Changez votre répertoire de sortie dans votre dossier WEB-INF/classes. (Projet/Propriétés/Chemin de construction Java, dossier de sortie par défaut)
- Assigne les dépendances du module. (Projet/Propriétés/Dépendances du module Java EE), ils seront copiés dans le dossier WEB-INF/lib où Eclipse recherche également les définitions de balise lib.
J'espère que ça aide.
Vérifiez les deux bibliothèques dans F:\Apache-Tomcat-7.0.21\webapps\examples\WEB-INF\lib:
- jstl.jar
- standard.jar
J'ai rencontré le même problème. C'est ce que j'ai fait pour résoudre le problème.
- Sélectionnez Projet et faites un clic droit.
- Cliquez sur les propriétés.
- Cliquez sur l'onglet bibliothèques.
- Cliquez sur 'Ajouter des bocaux'.
- Ajoutez un bocal pertinent pour votre erreur.
Si vos tld sont sur le chemin de classe, généralement dans le répertoire WEB-INF, les deux astuces suivantes devraient résoudre le problème (quelle que soit la configuration de votre environnement):
Assurez-vous que le
<uri>dans le TLD et le uri dans la directive taglib de vos pages jsp correspondent. Le<uri>élément du tld est un nom unique pour la bibliothèque de balises.Si le tld n'a pas de
<uri>élément, le conteneur tentera d'utiliser l'attribut uri de la directive taglib comme chemin d'accès au TLD réel. par exemple Je pourrais avoir un fichier tld personnalisé dans mon dossier WEB-INF et utiliser le chemin d'accès à ce tld comme valeur uri dans mon JSP. Cependant, ceci est une mauvaise pratique et doit être évité car les chemins seraient alors codés en dur.
J'utilise le plug-in Spring STS et un projet de modèle Spring webmvc. Je devais d'abord installer le plugin Maven m2e: http://www.Eclipse.org/m2e/
Et puis nettoyez le projet. En dessous de Project -> Clean...
Vous pouvez simplement aller dans Chemin de construction -> Ajouter des bibliothèques et pour le type de bibliothèque à ajouter, sélectionnez "Server Runtime". Cliquez sur Suivant et sélectionnez un serveur d’exécution à ajouter au chemin de classe. Le problème disparaît si jstl.jar et standard.jar se trouvent dans le chemin de classe de votre serveur.
J'ai eu le même problème avec MyEclipse et Eclipse 6.6.0. Il a tapissé en rouge la valeur uri dans chaque
<%@ taglib prefix="s" uri="/struts-tags"%>. Je l'ai corrigé en allant dans "Projet/MyEclipse/Web/Bibliothèques de balises" et en définissant le préfixe TLD par défaut pour les balises de tuiles Struts 1.2 sur "s". Je devais aussi faire la même chose sous 'Projet/MyEclipse/Web/Configurer les paramètres de l'espace de travail .../Bibliothèques de balises'.
Pour moi, cette erreur se produit chaque fois que j'essaie d'utiliser une nouvelle version d'Eclipse. Apparemment, le nouvel Eclipse réinitialise le M2_REPO variable et j'obtiens toutes les erreurs de bibliothèque de balises dans la vue Marker (parfois avec des erreurs de validation ejb).
Après avoir mis à jour M2_REPO variable pour pointer sur l’emplacement réel du référentiel maven, il faut 2-3 projets -> Nettoyer les itérations pour que tout fonctionne.
Et parfois, il y a des erreurs de validation XML (ejb) avec les erreurs de cette bibliothèque de balises. La mise à jour manuelle du fichier XML correspondant déclenche une recherche de fichier * .xsd et les erreurs de validation XML sont résolues. Postez ceci, les erreurs de la bibliothèque de balises disparaissent également.
D'autre part, si vous ne travaillez que sur Java source et obtenez ces erreurs avec des éléments que vous ne touchez pas dans un projet de grande envergure qui fonctionne, vous pouvez simplement désactiver les validations dans Eclipse. Les paramètres se trouvent sous Préférences-> Web-> Fichiers JSP-> Validation.
vous devez bien comprendre qu'il y a toujours deux choses, l'API et l'implémentation (attention au format gradle du code suivant)
compile group:'javax.servlet.jsp.jstl', name:'javax.servlet.jsp.jstl-api', version:'1.2.1'
compile group:'org.glassfish.web', name:'javax.servlet.jsp.jstl',version:'1.2.1'
donc, si vous utilisez un conteneur de servlets sans support jstl, il ne fournira bien sûr pas les deux. Une erreur que j'ai commise est que je ne mets que le premier, mais si vous utilisez un serveur d'application à pile complète, c'est-à-dire glassfish alors Glassfish les aura déjà tous les deux à l'intérieur.
J'avais le même problème avec Tomcat 6.0 et Eclipse et j'ai essayé quelque chose que mon ami m'a suggéré et qui a fonctionné pour moi. Le lien pour la question que j'ai posée et ma réponse commentée peuvent être trouvés ici:
JSTL Tomcat 6.0 ne trouve pas le descripteur de taglib Erreur
Faites-moi savoir si cela résout votre problème "Vous ne trouvez pas le descripteur taglibrary".
Cette erreur peut provenir de plusieurs sources différentes. Un cas (non mentionné dans les autres réponses à cette question) se produit lorsque Eclipse n'implémente pas la version de la spécification JSP définie dans le document TLD. Les versions d'Eclipse ont généralement pris du retard d'un an dans la mise en œuvre de nouvelles spécifications de servlet et JSP. Voir ce bug Eclipse par exemple.
Dans ce cas, votre application Web peut s'exécuter correctement dans la dernière version de Tomcat, mais Eclipse peut toujours se plaindre d'un TLD manquant. La solution à court terme (à part ignorer l'erreur dans Eclipse) consiste à remplacer la version JSP par celle prise en charge par votre version d'Eclipse.
Aussi, gardez à l'esprit la version de TLD que vous implémentez. Les noms de balises ont légèrement changé de v1.1 à v2.0 (c.-à-d., info est maintenant description sur taglib et n'est pas un élément valide sous tag, de nombreux noms d'élément contiennent maintenant un trait d'union). Eclipse n'a aucune tolérance pour les noms de balises TLD mal orthographiés.
J'ai eu le même problème avec STS (suite source springtool).
Sous STS, cliquez avec le bouton droit de la souris sur le projet, puis sur "Propriétés", "Projet de facettes", puis sur le côté droit de la fenêtre, cliquez sur l'onglet "Exécution" et cochez la case "VMware vFabric tc Server (...)", puis cliquez sur OK. "Appliquer" et il devrait être OK après l'actualisation de l'espace de travail.