Affichage des articles dont le libellé est aspectj. Afficher tous les articles
Affichage des articles dont le libellé est aspectj. Afficher tous les articles

30 juillet 2009

maven, eclipse et aspectJ : si si, ça marche

Mon projet préféré du moment est une énorme usine à gaz avec un bon paquet de modules Maven. Sous Eclipse avec m2eclipse, des builds Maven se lancent en pagaille si on active le "build automatically".

Soucis, mon projet dépend énormément d'aspectJ (via mon Fonzie à moi que j'ai) et la compilation maven prend des plombes.

  • option 1 :
décocher le build automatique. Il faut alors lancer des builds à la main et bien sur dans le bon ordre, autant dire que c'est galère aussi et qu'on se retrouve souvent à exécuter du code qui ne colle pas aux sources
  • option 2 :
ne plus gérer les relations inter-projet sous eclipse en tant que tel, mais passer par les JAR. On lance donc explicitement un gros build Maven avant de tester. Plus prédictif mais pas du tout productif
  • option 3 :
Utiliser AJDT 2.0, dont le build incrémental est un régal. Soucis : si l'intégration avec m2eclipse configure tout bien comme il faut AJDT, le plugin Maven est toujours exécuté lors des builds maven et on retrouve le problème initial. D'où ce magnifique hack :

<profiles>
<profile>
<id>m2eclipse</id>
<activation>
<property>
<name>osgi.bundles.defaultStartLevel</name>
</property>
</activation>

<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
</profile>

Avec cette conf magique, AJDT est correctement configuré par m2eclipse et fait parfaitement son boulot (le hotswap permet ainsi d'éditer le code et de constater le résultat à chaud dans Tomcat), ET les build maven sous eclipse sont raisonablement rapides, le plugin aspectj ne faisant plus rien.

C'est un hack bien pourri, mais ça montre que m2eclipse 0.9.9, une fois le "custom lifecycle mapping" en place et supporté par de nombreux plugins, devrait nous faire oublier toutes ces années de cohabitation difficile entre Maven et Eclipse.

30 mars 2009

Fonzie Coding Fryday

Vendredi dernier j'ai voulu sortir un peu de quatre jours à corriger des bugs en série pour réussir à faire passer le projet dans l'intégration continue Hudson. Le temps d'appliquer une correction, deux nouvelles boulettes appraissaient sous Subversion.
Vendredi donc, j'ai voulu faire du codage cool. J'ai donc délaissé mes bugs (ils seront encore là lundi,  d'ailleurs ça c'est confirmé) pour me lancer dans un code expérimental : recoder Grails en pur Java. Pour commencer modestement, je me suis contenté de GORM, la couche d'accès à la base de Grails, et plus précisément à son mécanisme de requête sur les entités "domaine".

Pour faire court, si je déclare une méthode User.findByNameOrderByBirthDate(String) à votre avis  quelle est la requête passée en JPA ? Le concept "Don't Repeat Yourself" (DRY) consiste à s'obliger à chercher des outils et des conventions intelligentes pour ne pas avoir à coder ce genre de méthodes. Si un esprit raisonnablement tortueux arrive à deviner ce qu'elle fait, un soft bien ficellé devrait pourvoir en faire autant.

En Groovy, Guillaume et sa bande nous font ça les doigts dans le nez. Sans Groovy, j'ai fait appel à AspectJ. C'est un peu moins classe qu'avec Groovy, mais on reste en pur Java - ne jamais changer les habitudes des gens sinon ça fini toujours par vous retomber dessus ;)

C'est donc comme ça qu'est né Fonzie (il est comment Fonzie ? Il est cool !)
J'espère bien répéter l'expérience du Fonzie Coding Fryday (TM) vendredi prochain, ça apporte un bon bol d'air et plein de nouvelles idées.