31 juillet 2009

35 ans, presque mort...

Amusant de lire ici et ici le même constat que je peux faire :
dans le système français, soit on devient chef, soit on est une moule. Donc quelqu'un qui fait encore du code après 10 ans d'expérience c'est pas logique, il devrait depuis longtemps diriger des juniors qui codent à sa place, voire diriger des chefs qui ont leurs propres sous-fifres.

Il va donc falloir que je revoie un peu mon CV pour me propulser chef de software factory (i.e. le gars qui arrive encore à comprendre comment démerder le build maven), ou chef de la cellule d'innovation et de veille technologique, ou chef de la machine à café, enfin chef d'un truc quelconque.
8 commentaires
Libellés :

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.
0 commentaires
Libellés : , ,

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

0 commentaires
Libellés : ,

28 juillet 2009

Maven et Hudson main dans la main


Mon projet prend 30 minutes pour se construire, tests IT compris. Dans de nombreux cas, les modifications associées à un commit ne concernent qu'un sous ensemble de modules et un échec pourrait être détecté en une dizaine de minutes. Même constat pour le retour au bleu : 30 minutes d'attente pour constater qu'une correction en périphérie du projet est valide, avec une reconstruction de 90% du projet qui n'est pas du tout concerné.

Pour le rendre plus réactif, j'ai du découper "manuellement" le projet selon ses modules maven (principaux) et prévoir les chemins SVN et autres commandes MVN pour que seuls les projets considérés soient construits. Ca va déjà nettement mieux, mais pour pousser la logique jusqu'au bout il faudrait configurer un job Hudson pour chaque module maven, et assurer la mise à jour de ces jobs à chaque modification de la structure des modules.

C'est fastidieux, et source de soucis divers, mais bon ça marche et mon build est devenu nettement plus réactif - effet de bord non négligeable, on est passé au grand bleu après de nombreuses heures de gyrophare rouge allumé dans le couloir...


Je pourrais conclure là dessus, mais Hudson n'en finit plus de métonner :

Vous le savez peut être, Maven 2.1 permet de spécifier une liste de modules à construire, plutôt que de se coltiner tous les modules d'un multiprojet. Maven se comporte alors à la make, c'est à dire qu'il va construire les modules spécifiés + tous les modules nécessaires. On peut aussi lui demander de se comporter à la hudson, c'est à dire de construire tous les modules qui peuvent potentiellement être impactés par les modules construits.

Il ne restait donc qu'un pas à franchir pour que Hudson puisse (enfin) construire intelligement les projects Maven un peu trop volumineux en ne sélectionnant que les modules impactés par un commit.

Avec la révision 138 d'Hudson, prévue en fin de semaine, une nouvelle option avancée dans les options de build Maven devrait apporter cette fonctionnalité tant attendue. Jusqu'ici seul Continuum savait gérer finement les modules Maven, voici donc que son concurrent vient lui couper l'herbe sous le pied.

Elle est pas belle la vie ?
(en fait non, il y a encore Eclispe, JBoss, et ma non-augment' de fin d'année à considérer)
2 commentaires
Libellés : ,
Inscription à : Articles (Atom)