<commit_before> - TODO or not TODO: InstantiationType.SPRING_COMPONENT ?
        Ça hardcode une dépendance avec Spring.
        Ce serait sans doute mieux dans un module à part (qui s'occuperait aussi de générer SpringMapperContext.java).
        corrolaire : l'utilisation d'une enum pour indiquer la manière d'instancier le mapper n'est pas extensible
                     (ie. ajout d'un support Guice, JEE, ...) utiliser plutôt une interface ?
        meilleure idée
           => supprimer le paramètre de @Mapper
           => déduire le cas enum si c'est une enum qui est annotée
               le nom de la valeur de l'enum n'a pas d'importance, on valide juste à la compilation qu'il n'y en a qu'une
           => déduire le cas constructeur que c'est une enum qui est annotée
           => une API permet d'ajouter une annotation en plus de @Mapper qui fera que l'on créera une classe avec un @Component
              et une autre implémentation de factory
 - TODO : ajouter un paramètre à @Mapper pour préciser la visibilité de la classe Mapper générée (public par défaut, sinon protected)
           -> on n'ajoute pas de paramètre, la visibilité de l'interface générée sera la même que celle de la classe annotée avec @Mapper
 - framework d'injection super léger : essayer Dagger


ROADMAP
[X] intégration avec Spring, générer des classes annotées @Component pour les classes @Mapper elles-mêmes annotées avec @Mapper
[X] écriture d'un cas d'intégration avec un Spring contexte
[X] auto discovery de l'annotation processor
[X] séparation en modules spécifiques des annotations et du processor
[X] toute exception doit indiquer la classe @Mapper pour laquelle ça a pété
[ ] supprimer usage de FluentIterable.toImmutableList() et toImmutableSet() ou de toList() et toSet()
[ ] mettre en place un système d'exception internes pour ne pas faire des getMessager().[...] un peu partout, afficher
  ces exceptions avec un getMessager() mais ne pas remonter à javac
[ ] disposer d'une liste de String pour y coller les simples warnings pour ne pas faire de getMessager() un peu partout,
  afficher ces warnings avant de traiter l'exception interne
[ ] tester MapperFactory avec des Objets non java.lang, des génériques, ...
[ ] test U pour les méthodes appendType, appendParams, ... de DAStatementWriter ?
[ ] ajouter un contrôle : les MapperFactoryMethods doivent retourner le type de l'objet annotée avec @Mapper
[ ] ajouter une méthode appendReturn à DAStatementWriter ?
[ ] ajouter un test U pour DAType.superBound
[ ] ajout support de génériques avec bounds multiples : <T extends B1 & B2 & B3>
[ ] remplacer la propriété DAMethod.mapperFactoryMethod par l'ajout de la liste des annotations sur la méhode de sorte
  que la logique de calcul de cette propriété ne soit pas dupliquée dans le parsing Psi ou Javax
[ ] remplacer la propriété instantiationType dans DASourceClass en ajoutant les annotations au modèles
[ ] test U pour DAClassWriter.newClass
[X] reduire duplication dans le calcul des imports (ImportVisitable implemenations)
[ ] déplacer DAFileWriter#PackagePredicate dans une classe DAName predicate et ajouter des tests U
  (en particulier pour le package par défaut, ie. pas de package)
[ ] factoriser la génération des méthodes @MapperMethod (pour l'instant juste apply de Guava.Function) entre
  MapperImplFileGenerator et MapperFactoryImplFileGenerator ?
[X] ajouter les @Override manquant dans les classes générées Mapper*Impl
[ ] traiter les TODO et FIXME qui trainent dans les sources<commit_msg>add TODO optimize anonymous classes (Function, Predicate<commit_after> - TODO or not TODO: InstantiationType.SPRING_COMPONENT ?
        Ça hardcode une dépendance avec Spring.
        Ce serait sans doute mieux dans un module à part (qui s'occuperait aussi de générer SpringMapperContext.java).
        corrolaire : l'utilisation d'une enum pour indiquer la manière d'instancier le mapper n'est pas extensible
                     (ie. ajout d'un support Guice, JEE, ...) utiliser plutôt une interface ?
        meilleure idée
           => supprimer le paramètre de @Mapper
           => déduire le cas enum si c'est une enum qui est annotée
               le nom de la valeur de l'enum n'a pas d'importance, on valide juste à la compilation qu'il n'y en a qu'une
           => déduire le cas constructeur que c'est une enum qui est annotée
           => une API permet d'ajouter une annotation en plus de @Mapper qui fera que l'on créera une classe avec un @Component
              et une autre implémentation de factory
 - TODO : ajouter un paramètre à @Mapper pour préciser la visibilité de la classe Mapper générée (public par défaut, sinon protected)
           -> on n'ajoute pas de paramètre, la visibilité de l'interface générée sera la même que celle de la classe annotée avec @Mapper
 - framework d'injection super léger : essayer Dagger


ROADMAP
[X] intégration avec Spring, générer des classes annotées @Component pour les classes @Mapper elles-mêmes annotées avec @Mapper
[X] écriture d'un cas d'intégration avec un Spring contexte
[X] auto discovery de l'annotation processor
[X] séparation en modules spécifiques des annotations et du processor
[X] toute exception doit indiquer la classe @Mapper pour laquelle ça a pété
[ ] supprimer usage de FluentIterable.toImmutableList() et toImmutableSet() ou de toList() et toSet()
[ ] optimiser les classes annonymes (Function, Predicate, ...)
[ ] mettre en place un système d'exception internes pour ne pas faire des getMessager().[...] un peu partout, afficher
  ces exceptions avec un getMessager() mais ne pas remonter à javac
[ ] disposer d'une liste de String pour y coller les simples warnings pour ne pas faire de getMessager() un peu partout,
  afficher ces warnings avant de traiter l'exception interne
[ ] tester MapperFactory avec des Objets non java.lang, des génériques, ...
[ ] test U pour les méthodes appendType, appendParams, ... de DAStatementWriter ?
[ ] ajouter un contrôle : les MapperFactoryMethods doivent retourner le type de l'objet annotée avec @Mapper
[ ] ajouter une méthode appendReturn à DAStatementWriter ?
[ ] ajouter un test U pour DAType.superBound
[ ] ajout support de génériques avec bounds multiples : <T extends B1 & B2 & B3>
[ ] remplacer la propriété DAMethod.mapperFactoryMethod par l'ajout de la liste des annotations sur la méhode de sorte
  que la logique de calcul de cette propriété ne soit pas dupliquée dans le parsing Psi ou Javax
[ ] remplacer la propriété instantiationType dans DASourceClass en ajoutant les annotations au modèles
[ ] test U pour DAClassWriter.newClass
[X] reduire duplication dans le calcul des imports (ImportVisitable implemenations)
[ ] déplacer DAFileWriter#PackagePredicate dans une classe DAName predicate et ajouter des tests U
  (en particulier pour le package par défaut, ie. pas de package)
[ ] factoriser la génération des méthodes @MapperMethod (pour l'instant juste apply de Guava.Function) entre
  MapperImplFileGenerator et MapperFactoryImplFileGenerator ?
[X] ajouter les @Override manquant dans les classes générées Mapper*Impl
[ ] traiter les TODO et FIXME qui trainent dans les sources
{'fraction_non_alphanumeric': 0.05291817927953086, 'fraction_numerical': 0.0008377548170901983, 'mean_word_length': 4.005590496156534, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1226933', 'n_tokens_mistral': 2077, 'n_tokens_neox': 2046, 'n_words': 957}