Accélérer ses recherches sous Eclipse

eclipseChaque jour, un développeur effectue une bonne quantité de recherches dans ses sources et parfois de façon assez poussée. Trouver son information rapidement et avec des résultats pertinents est une nécessité.

Or, les recherches sous Eclipse peuvent parfois être lentes voire décourageantes, surtout si le nombre de projets et donc le nombre de fichiers est très élevé.

Cet article présente les différentes solutions de recherche dont une proposition d’amélioration qui changera certainement votre quotidien…

Il existe plusieurs types de recherche dans Eclipse, nous allons nous concentrer sur deux des plus courants : la recherche Java et la recherche de texte.

La recherche d’éléments Java

Pour une recherche d’éléments Java, qui reste à mon avis celle que l’on réalise le plus, il existe plusieurs possibilités :

  • La recherche de types (Ctrl + Maj + T)
    Utile pour trouver une classe dont on connait (à peu près) le nom, merci les wildcards et le camel case !
  • Le menu référence, accessible avec clic droit sur un élément dans l’éditeur.
    Permet de trouver ses occurrences dans le workspace (Ctrl + Maj + G), dans le projet ou dans la hiérarchie.
  • La déclaration dans le workspace (Ctrl + G)
    Pour trouver toutes les occurrences déclarées d’un élément (et non les appels comme le fait le raccourci précédent)
  • La outline rapide (Ctrl + O)
    Pour afficher tous les membre de la classe Java en cours.
    Note : en appuyant sur ‘O’ une seconde fois, la outline se complète avec tous les membres Java des classes parentes, terrible non ? 😉
  • La hiérarchie de classes (F4 ou Ctrl + T pour la vue rapide)
  • L’appel hiérarchique ascendant et descendant de méthodes (Ctrl + Alt + H)
    Utile pour remonter ou descendre le long de la pile d’appels d’une méthode
  • etc.

Bref, tout un panel de raccourcis et de menus sont là pour nous faciliter la vie.

Il en existe d’autres, on pourra les trouver dans la section Keys des préférences d’Eclipse.

La recherche de texte

Le module de recherche de texte d’Eclipse est accessible via le menu Search ou encore avec la combinaison Ctrl + H.

Nous allons nous intéresser plus précisément à l’onglet File search.

Cet onglet permet de trouver une chaîne de caractères, statique ou en mode expression régulière et dispose même dans le second cas, d’un assistant à la composition d’une expression valide (Ctrl + Space).

file search

Le point clé de l’utilisation de ce module est le périmètre de recherche. En effet, le champ File name patterns permet de définir quels seront les types de fichiers dans lesquels la recherche sera effectuée.

Il est possible de saisir plusieurs types pour élargir ses chances de trouver sa chaîne.

Enfin le champ Scope va permettre de restreindre le périmètre de la recherche (you don’t say ?)

Les items proposés sont les suivants :

  • Workspace va cibler l’ensemble des projets : sera donc plus lent que les autres
  • Selected resources va cibler uniquement la ressource en surbrillance d’une vue active, qui peut être un fichier, un package, un projet, un working set ou simplement le fichier source en cours d’édition
  • Enclosing projet est bien utile lorsqu’on est dans un fichier source, et que l’on ne veut pas rechercher plus loin que le projet conteneur
  • Enfin, Working set permet de sélectionner les éléments qui regroupent des projets de façon logique (par exemple : Front, Back, Database, etc)

Les ressources dérivées

Passons maintenant à la petite subtilité du module : l’exclusion de ressources dérivées.

La notion ‘derived’ est matérialisée par un flag positionné sur un fichier ou un dossier du workspace et qui signifie que l’élément ne fait pas partie des sources et a été généré par un processus (build, compilation, transformation, etc)

On peut retrouver ce flag en accédant aux propriétés de l’élément, section Resource.

derived

La recherche de texte décrite dans le paragraphe précédent permet de tenir compte de cette notion.

Par défaut, tout ce qui est dérivé ne sera pas inclus dans les résultats de recherche, ce qui est plutôt souhaité.

Cependant, on aimerait certainement exclure certains dossiers de type targetbuild ou encore out des recherches.

Lors d’un clean install avec Maven par exemple, ces répertoires sont recréés, sans le flag Derived coché…

Il est évident que le développeur ne va pas cocher chaque flag Derived de chaque répertoire surtout que l’opération devra être répétée à chaque exécution de maven (autrement dit, plusieurs fois par jour)

Je propose donc 2 solutions pour remédier à cela : l’utilisation d’un script python et un plugin déjà tout fait. A vous de choisir !

Solution 1 : le script GroovyMonkey

Cette approche consiste à exécuter un script, qui va repérer un ensemble de ressources et les marquer comme Derived.

Elle a l’avantage de pouvoir définir autant de règles que souhaitées pour cibler cet ensemble.

Premièrement, il est nécessaire d’installer le plugin Eclipse Groovy Monkey avec l’URL

http://groovy-monkey.sourceforge.net/update

Une fois l’installation et le redémarrage effectués, un menu est apparu : Groovy Monkey.

Créer un nouveau script nommé MakeTargetDerived_Script.gm et y coller le code suivant :

/*
* Menu: New Groovy Monkey Script
* Script-Path: /TestGroovyMonkey/MakeTargetDerived_Script.gm
* Kudos: aga
* License: EPL 1.0
* LANG: Python
*/
# Install GroovyMonkey from :
# http://groovy-monkey.sourceforge.net/update

files = resources.filesMatching(".*/pom\\.xml")

for file in files:

targetFolder = file.eclipseObject.parent.findMember("target")
outFolder = file.eclipseObject.parent.findMember("out")

if targetFolder != None:
    targetFolder.setDerived(True)
if outFolder != None:
    outFolder.setDerived(True)

Dans cet exemple, on va sélectionner tous les fichiers pom.xml et trouver toutes les ressources nommées “target” et “out”. Ensuite chaque item sera flaggé Derived.

Pour l’exécuter, clic droit puis Run Script. That’s it !

Ma préférence va à cette solution, pour sa plus grande flexibilité offerte par le scripting.

Solution 2 : le plugin Eclipse Target Derivator

Télécharger et installer le plugin depuis cet emplacement.

Redémarrer Eclipse, un nouveau bouton est apparu.

markasderived

Un simple clic sur dernier et tous les dossiers générés par maven seront marqués Derived.

En fouillant un peu dans le source du plugin, on peut voir que la liste exhaustive des répertoires marqués est la suivante :

  • target
  • tmp
  • temp
  • bin
  • bin-test
  • test-output
  • precompiled

Après utilisation d’une de ces 2 solutions, les recherches sont quasi instantanées !

Conclusion

Nous venons de voir qu’il est possible de bien travailler ses recherches avec Eclipse, que ce soit par des raccourcis, des menus, des options ou encore des plugins. L’important est d’utiliser le bon outil pour trouver les bonnes ressources.

Connaître ses raccourcis peut également s’avérer très utile et permettra d’accroître sa productivité.

Bonnes recherches !

Nombre de vue : 484

COMMENTAIRES 7 commentaires

  1. Est il possible avec les deux solutions proposées pour les ressources dérivées, de définir des exceptions dans les exclusions : par exemple dire tout le répertoire “target” sauf “target/generated-sources” ?

  2. Aurélien Garnier dit :

    A priori, je dirais non. En effet, en inspectant les propriétés des éléments sous les dossiers marqués “Derived”, on peut voir qu’ils héritent des attributs de leurs parents.
    La mention “(has derived ancestor)” est d’ailleurs présente.
    Une solution serait d’itérer récursivement sur chaque ressource présente sous le dossier parent et de définir les exclusions au cas par cas, en laissant le parent marqué comme non dérivé.
    Ceci est du coup plus facilement faisable en scriptant avec Groovy Monkey.

  3. Mika dit :

    Merci pour le rappel. Pour info, appuyer deux fois sur Ctrl + T montre la hiérarchie ascendante des classes, bien pratique aussi.

  4. Monsieur Max dit :

    Bien joué monsieur grabidé !

    A noter aussi qu’il est possible de filtrer la recherche des occurences ( Ctrl+Maj+G) par working set. Rarement utile mais salutaire dans les énormes projets.

    Bisous.

  5. Maxime Lenglet dit :

    Bonjour,

    Personnellement, ma préférence va à la définition de Working Sets adéquats, de deux types :
    – les premiers de type Java pour regrouper un ensemble de projets, qui permettent de faciliter la recherche Java (en particulier la Ctrl + Maj + T)
    – les seconds de type Resource pour regrouper l’ensemble du code “utile” des projets (à savoir si l’on est dans un contexte Maven, le répertoire src/ et les pom.xml) pour la recherche plein texte.
    Et je suis pleinement satisfait de cette configuration.

  6. Merci pour de post que j’aurais dû faire depuis des lustres. J’ajouterais simplement que les fonctions de recherche de l’IDE doivent être accompagnées d’une bonne règle de nommage au sein des projets, notamment en terme de préfixes et suffixes. Des projets propres, bien organisés avec des ressources, des classes, des méthodes et des attributs bien nommés et c’est le bonheur assuré.

  7. johan duparc dit :

    Merci pour ce post !
    J’ai eu un peu de mal avec groovyMonkey, je crains que ce ne soit un peu abandonné non?
    En tout cas, je me suis arraché les cheveux sur ces ressources dérivées qu’Eclipse ne mémorise pas après une suppression.
    Au final j’ai écrit un plugin, AutoDeriv, qui fonctionne grâce a un fichier texte décrivant les ressource à marquer ‘dérivée’.
    C’est simple et efficace, jetez un œil ici : http://nodj.github.io/AutoDeriv/
    Un truc cool, les souhaits de Fabien Baligand sont exaucés. On peut tout a fait marquer un dossier, et avoir des sous-dossier en exceptions, non marqués.

AJOUTER UN COMMENTAIRE