65 votes

Comment exclure un dossier qui produit des avertissements/erreurs dans un projet Eclipse ?

Ok. J'en ai marre de ce problème. Ce doit ont un correctif facile, j'en suis sûr !! J'espère que SO pourra m'aider à me débarrasser de ce problème une fois pour toutes !

Question

Comment faire pour qu'Eclipse arrête d'essayer de traiter/compiler tous les fichiers d'un répertoire de projet particulier ? L'objectif de objectif est qu'aucune erreur/avis n'existe n'existe dans la vue des problèmes s'ils s'ils concernent un élément de ce dossier ou de ses sous-dossiers.

Contexte

Nous utilisons Eclipse 3.6 et le plugin m2eclipse v0.10.2.20100623 gère notre autobuild. Pour des raisons indépendantes de ma volonté, nous avons toute la distribution de BlazeDS dans notre répertoire de projet SVN sous le nom de src/main/resources/blazeds . Essentiellement, ce répertoire contient une distribution vanille de tomcat exécutant blazeds à laquelle tous nos fichiers de configuration et de projet sont ajoutés lorsque nous déployons sur notre serveur via SCP.

Ainsi, lorsque nous exécutons deploy, cette version de tomcat est copiée sur le serveur et notre projet y est placé. Tomcat et notre application RIA fonctionnent et tout va bien.

Le problème est qu'Eclipse essaye de tout compiler sous src/main/resources/blazeds lors de l'exécution d'AutoBuild et cela génère environ 300 erreurs/alertes dans notre vue des problèmes. Ainsi, lorsqu'une véritable erreur fait surface, elle se perd dans le bruit.

Les erreurs proviennent du code dans /blazeds/tomcat/webapps/samples/testdrive-datapush et aussi le testdrive-httpservice , traderdesktop exemples de webapps. Ils ont un code source dépendant qui ne se trouve pas dans le classpath et des jars qui ne sont pas inclus dans les bibliothèques.

Échec Tentatives de solutions

J'essaie de pousser la bonne solution : supprimer complètement les échantillons et aussi sortir les blazeds de notre contrôle de version. Ce n'est pas près d'arriver.

J'ai suivi le SO réponse ici mais ce n'est qu'une solution très temporaire. J'ai essayé d'ajouter des exclusions partout où je le pouvais et d'autres membres de mon équipe ont fait de même. J'ai supprimé src/main/resources en tant que répertoire source (dans les préférences > Java Build Path > Source Tab), j'ai ajouté des exclusions pour blazeds sous le répertoire des ressources. J'ai essayé toutes les permutations de blazeds y ** dans le cas de *blazeds* , **/blazeds/** etc.

J'ai même essayé d'inclure les bibliothèques et les fichiers sources dont le compilateur se plaint, mais je n'ai pas réussi à le faire sans modifier excessivement la configuration de notre projet.

Résumé

Il faut que ce soit simple. Quelle est la manière conventionnelle d'exclure un dossier qui produit des avertissements/erreurs dans un projet eclipse ?


Mise à jour n° 1 :
La solution de gedim ci-dessous est décente mais elle
1) n'élimine pas les X rouges du projet
2) est un changement que tout le monde dans notre équipe doit faire, manuellement.
(c'est-à-dire qu'il n'est pas dans un fichier de propriété du projet ; par conséquent, il n'est pas enregistré dans subversion).

J'espère qu'il y a un moyen de résoudre le problème de fond en disant à Eclipse que ce répertoire ne contient pas de
des éléments à compiler/valider. Un tel changement apparaîtrait probablement dans l'un des fichiers de configuration du projet.


Mise à jour n°2 :

L'image ci-dessous montre les X rouges que j'essaye d'effacer et le fait que
Build Path > Exclude
n'est pas une option...

Red X's won't go away

1 votes

Build Path > Exclude semble être une bonne solution. Elle fonctionne parfaitement dans Eclipse Juno pour modifier Java Build Path.

61voto

TIER 0011 Points 164

J'ai rencontré un problème similaire et je l'ai résolu en déplaçant le dossier dans mon dossier de projet. Je me suis ensuite rendu dans :

  1. Projet > Propriétés > Ressource > Filtres de ressources > Ajouter...
  2. Définir Type de filtre = Exclure tout .
  3. Définir S'applique à = Dossiers .
  4. Définir Attributs des fichiers et des dossiers = { Nom, correspondances, < votre_nom_de_dossier> }

3 votes

Cela devrait être la réponse acceptée. L'autre approche ne fonctionne pas pour les sous-dossiers à l'intérieur des projets.

0 votes

Soupir... J'ai un problème similaire. Mon projet a des dossiers (virtuels) avec des sources, c'est-à-dire que les sources sont situées ailleurs. J'ai besoin d'exclure certains de ces dossiers de la construction. J'ai utilisé la commande ci-dessus filtre de ressources y J'ai aussi mis " exclure de la construction "pour le même dossier. Le dossier apparaît maintenant estompé mais toutes les sources qu'il contient sont toujours en cours de construction.

0 votes

Cela fonctionne maintenant. Le problème était que le projet était configuré comme un projet C alors que certaines des sources liées étaient C++. Après avoir changé le projet en C++, l'activation et la désactivation des dossiers liés semblent fonctionner correctement.

31voto

Giorgos Dimtsas Points 2846

Vous pouvez utiliser le Configure Contents... sur le menu de Problems panneau. Vous pouvez y créer une nouvelle configuration et définir le champ d'application comme suit On Working Set: . Cliquez sur Select... et créez un nouvel ensemble de travail qui exclut les dossiers que vous ne voulez pas.

4 votes

Merci pour votre réponse ! Cette solution fonctionne mieux que ce que nous faisions auparavant, mais elle souffre de deux problèmes. Le plus important, c'est que ce n'est pas une modification qui est enregistrée dans le contrôle de version. Je dois donc aller voir mes autres collègues pour leur demander de le faire. Deuxièmement, il essaie toujours de compiler les classes. Ainsi, sur le côté gauche, je vois toujours des X rouges sur mes dossiers de projet de premier niveau au-dessus du répertoire src/main/resource/blazeds. En dehors de ces problèmes, c'est fantastique ! Les problèmes n'apparaissent plus dans la vue des problèmes ! !! Je ne connaissais pas du tout cette fonctionnalité d'Eclipse.

4 votes

7 ans plus tard, je ne sais toujours pas comment supprimer le x rouge :/

8voto

Rhett Hudson Points 39

Il existe une demande de fonctionnalité Eclipse pour ignorer les avertissements des dossiers sources spécifiés. Plusieurs correctifs ont été postés dans le fil de commentaires qui fournissent des implémentations de la fonctionnalité. Il semble qu'un patch final soit sur le point d'être révisé pour être inclus dans une prochaine version.

Mise à jour du 19 juin 2012 : Eclipse Juno 4.2M6 permet d'ignorer les problèmes pour un dossier source particulier. Cette fonctionnalité est disponible dans la boîte de dialogue Java Build Path. Voir le note de mise à jour .

3voto

nanda Points 12764

Si vous voulez vraiment exclure certaines classes ou certains paquets de la construction automatique, vous pouvez simplement faire un clic droit dessus et sélectionner Build Path -> Exclude.

alt text

0 votes

Malheureusement, ça n'a pas marché. Mais merci pour votre réponse ! J'étais impatient de l'essayer. Cependant, "Exclure" n'est pas une option ici sous src/main/resources . J'ai mis à jour ma question avec une photo. Exclure est une option sous mes dossiers sources. Je ne comprends pas pourquoi ce truc stupide essaie de compiler ! !!

0 votes

Il n'y a pas d'exclusion parce que vous l'avez exclu :). Pouvez-vous essayer de copier une erreur que vous obtenez du dossier ici ? Et puis-je avoir une vue plus claire de ce qui se cache derrière ce menu popup ?

0 votes

Exactement, il n'y a pas d'excuse ! Je commence à me demander si ce n'est pas un bug car ce n'était pas un problème l'année dernière. Toutes les erreurs sont des erreurs légitimes liées à des pots manquants, etc. comme dans Feed cannot be resolved to a type . Stupide Eclipse : puisque ce code source n'est pas utilisé, bien sûr les jars ne sont pas là ! Je peux supprimer les erreurs en ajoutant toutes sortes de références aux dossiers lib et aux dossiers sources dans les paramètres de mon projet, mais ce n'est pas la solution souhaitée. Cela perturbe les autres et complique excessivement les paramètres du projet :(

-1voto

Aaron Digulla Points 143830

Comme les fichiers du dossier de ressources changent rarement, je suggère de les placer dans un second projet (où vous pouvez définir différentes options d'avertissement) et d'y accéder via un chemin relatif (comme ${basedir}/../special-tomcat ).

0 votes

Merci pour votre suggestion, comme je l'ai dit : I'm trying to push the proper solution: to remove the samples completely and also to get blazeds out of our version control. That's not happening anytime soon. Pour des raisons indépendantes de ma volonté, je ne peux pas mettre en œuvre votre solution, mais j'aime l'idée d'utiliser d'autres projets pour ce genre de choses.

0 votes

Vous pouvez utiliser ma réponse pour soutenir votre argument pour changer cet aspect du projet (comme "une exportation externe a suggéré ceci comme la meilleure solution").

0 votes

C'est tout. Je vais faire irruption à la réunion de lundi et demander : "Si c'est bon pour Digulla, c'est assez bon pour nous !". :)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X