15 octobre 2009

Une excellente Idea

Eclipse est omniprésent, et tout le monde s’accorde pour dire que c’est devenu une usine à gaz ingérable. Je dois moi-même faire face aux excès d’humeur de mes petits camarades qui pestent sur un Eclipse “préparé” par mes soins et qui malgré ça plante allègrement ou rame tout ce qu’il peut.

La concurrence, c’est NetBeans – qui a vraiment du mal à décoller même si on m’en a dit beaucoup de bien – et Idea, qui a une excellente réputation, mais malheureusement aussi un prix

logo_bw[1]

Ca, c’était la situation hier. Jetbrains vient en effet de passer son IDE en opensource

idea9-community_header[1]

Toutes les fonctionnalités de la version payante ne sont bien sur pas au rendez-vous, mais la liste est déjà bien assez large pour contenter les utilisateurs d’Eclipse lassés du “building workspace

Reste qu’il va falloir franchir le pas de dés-apprendre toute ces (mauvaises ?) habitudes qu’on a si chèrement acquises sous Eclipse, identifier les bons plugins et tout et tout, mais je suis convaincu que ce billet d’entrée sera vite amorti, à commencer par tout ceux qui galèrent avec l’intégration vraiment pourave de Maven dans Eclipse (on attend toujours ce fameux m2e 0.9.9) ...

Pour ma part, je tente l’expérience dès demain :)

Pour plus d’infos, ça se passe ici : http://www.jetbrains.com/idea/nextversion/free_java_ide.html

10 octobre 2009

Encoding Hell

ucs-encoding[1]Je viens de perdre une nouvelle journée de boulot sur des %!@$ problèmes d’encodage. Encore un N-ième fichier XML dont l’entête déclare fièrement un encoding=UTF-8, et qui se retrouve charcuté à la sauce CP-1252 (variante MS de l’ISO-8859-1).

Dire que depuis toutes ces années à inventer des formats interopérables et tout et tout on en est encore là ça fait pitié. J’en suis à me demander s’il n’existerait pas un petit plugin Eclipse bien malin pour convertir à la volée tous nos accents en entités xml ou en échappement Unicode – il y a par exemple le plugin propertiesEditor qui fait ça très bien … pour les fichiers properties.

C’est peut être l’occasion de devenir totalement bilingue et de tout rédiger en anglais, histoire de ne plus sortir du bon vieux ASCII 7 bits qui est finalement le seul moyen de ne pas se prendre la tête.

Le build Maven est un peu (!) plus stable grâce à l’option project.build.sourceEncoding mais ce n’est pas encore la panacée : il semble que le générateur de code de CXF (wsdl2java) produise du code source dans l’encodage “local”… pas gagné cette affaire.

08 octobre 2009

Lecture du soir...


Mon éditrice m'a fait parvenir un petit bouquin bien sympa : un petit guide du développeur JavaScript.

JavaScript est un langage des plus étrange : rendu indispensable par sa présence sur tous les navigateurs web, il est particulièrement obscur pour des développeurs traditionnels et comporte aussi bien des constructions très élégantes et des pièges à c.. dans lesquels on s'embourbe avec bonheur.

Comme beaucoup, j'ai moi aussi essayé de faire du développement JS avant de tomber dans des complications sans fin, malgré l'aide de frameworks en tout genre - c'est, entre autre, ce qui m'a fait aimer GWT ;)

Dans ce petit guide, Douglas CrockFord (YahooUI) prend d'office le parti d'écarter tout ce qui fait de JavaScript un langage tout pourri - sans se voiler la face - et ne présente donc que ce qui fait de JavaScript un langage prodigieux. C'est une des raison de la taille réduite du livre : hors sujet le DOM du navigateur, Ajax et ses implémentations merdiques d'un navigateur à l'autre. Ici on se concentre sur le coeur du langage, son fonctionnement et sur les bonnes façons de faire.

Pour un développeur débutant c'est clairement le livre idéal : comme on y apprend seulement ce qui marche bien, on est au moins sûr de ne pas prendre un mauvais pli. Pour les personnes plus expérimentées, la piqûre de rappel est salvatrice - j'ai enfin compris pourquoi this change si souvent de nature dans une fonction JS :)

Le livre se termine par plusieurs annexes qui dénoncent les aberrations du langage et ses mauvais éléments. Une bonne façon, une fois les bonnes pratiques acquises, de savoir là où il ne faut pas mettre les pieds et donc savoir les repérer.

Un excellent ouvrage, concis mais dense. Il donne du sens à ce langage méconnu et si loin de nos bon vieux langages objet fortement typés et basés sur des classes. Un indispensable pour toute personne qui compte se lancer dans un développement JavaScript, probablement plus indispensable que les nombreuses "bibles" du JavaScript en 400 pages qui sont bien plus délicates à exploiter. Bien sûr, pour être applicable en développement il faudra lui adjoindre une bonne référence sur l'API DOM et ses variations entre navigateurs.

Seul regret, je n'ai pas retrouvé d'information sur les problèmes de fuites mémoire, si caractéristiques des Closures JavaScript - peut être qu'une seconde lecture plus approfondie s'impose ;)


Disclaimer : bien que lié par contrat à Pearson dans un autre contexte, cette revue ne m'a pas été dictée et je parle donc en toute franchise :D



05 octobre 2009

HTML 5 - il va falloir réapprendre à coder :)

Au moins ceux d'entre vous qui suivent les actualités de Ajaxian.com ont entendu parler des progrèés sur HTML5. En particulier, Chrome 3 - webkit en général - le supporte

NB : je dis "le supporte", bien que ce soit partiel vu que HTML5 n'est pas une norme définitif mais un travail collectif.

Jusqu'ici je restais assez dubitatif, jusqu'à ce que je tombe sur cette démo : http://www.raymondhill.net/puzzle-rhill/jigsawpuzzle-rhill.php

Manipulation d'images à la souris, rotations et autres transformations, des choses dans l'absolu assez simples mais qu'on a pas l'habitude de voir en dehors d'un conteneur Flash. HTML5 promet donc d'ouvrir les portes aux pages riches et animées, sans passer ni par des magouilles de développement, ni par un runtime qui rend le client "léger" semi-lourd.

Faites donc joujou avec la démo, puis faites l'exercice : si un client me demandais un truc de ce genre, qu'est ce que j'aurais à lui proposer comme solution ?

02 octobre 2009

Google Chrome Frame : amusant

Google nous sort un de ces petits ovnis dont il a le secret : Google Chrome Frame.

Il s'agit d'un plugin pour IE qui remplace tout simplement le moteur de rendu du navigateur le plus décrié mais aussi le plus installé par le moteur Chrome. Celui-ci n'est actif que sur les pages qui déclarent une balise magique, autrement dit quelques sites de geek et probablement quelques applications Google, mais pas plus. Un petit Script est proposé par Google pour permettre à ces sites de proposer l'installation de Frame sur postes qui ne l'ont pas encore.

Il est évident que la cible n'est pas l'entreprise, car si on y utilise encore massivement IE6, c'est à cause d'applications utilisant massivement des ActiveX et/ou l'authentification MS Active Directory, ou simplement pour ne pas mettre des sous dans une migration technique risquée (?) et sans R.O.I. facilement chiffrable.

De mon point de vue, la cible c'est les millions de particuliers qui utilisent IE juste parce qu'il est fournit avec l'OS, qui n'ont aucune idée de ce qu'est un navigateur (je pense à ma belle mère qui "clique sur Internet"). Ceux qui ont déjà installé sans trop réfléchir le plugin Flash par ce que le site de la redoute le demandait, et qui installeront donc Frame un site grand public de renom le propose (par exemple ... www.google.com ?)

Quel intérêt pour Google ? Faire que le web soit toujours plus consommé par les utilisateurs à la place de l'informatique traditionnelle. Les gMail, gDocs, gCalendar et consorts ne gagneront du terrain que s'ils sont au moins aussi performants que l'équivalent desktop. Ce qui signifie bien sur un moteur rapide - en tout cas plus que celui natif d'IE - et le support du mode déconnecté (google Gears).

Ceci dit, il y a un intérêt pour Frame en entreprisse : sur un SI massivement MS/IE, proposer une installation 'transparente' de la petite extension magique reste acceptable (enfin, pas pour tout le monde), et cela ouvre aux développeur de nouvelles possibilités (HTML5 !) pour les nouvelles applications. Penses-y, amis lecteur, si tu es DSI - vous êtes probablement plus nombreux à être des geeks furieux, mais sait-on ...


21 septembre 2009

AOP et autres instrumentations du bytecode

Quand on découvre l'AOP (programmation orientée aspect) à travers les blogs et autres résultats que nous propose Google, on tombe immanquablement sur un exemple d'instrumentation du code par des logs.

Si d'un point de vue didactique c'est un exemple qui a l'avantage d'être parlant pour tout le monde, d'un point de vue technique c'est une aberration :
  • les outils de logs modernes déterminent le nom de la classe/méthode et numéro de ligne à la volée, il serait donc dommage de perdre cette info dans nos logs. Or, en passant par un aspect, ce mécanisme va pointer dans le greffon de l'aspect, et pas là où on l'a appliqué
  • chaque ligne de log va nécessiter l'invocation du greffon, la copie des arguments, peut être même la construction d'un logger pour la classe considérée. Des millièmes de secondes qu'on va répéter des millions de fois, au final un dégradation mesurable des performances du code (si vous n'y croyez pas, j'ai vu une appli perdre 10% de son temps dans des mécanismes de log mal fichus).
Evidemment, parler de gestion transactionnel pour montrer l'utilisation de l'AOP n'est pas le plus simple...

Je rebondis cependant sur ce problème pédagogique : l'idée de base est bonne

Personne n'apprécie de devoir lire des logs vides, mais n'aime pas pour autant passer du temps à ajouter des logs DEBUT/FIN dans tout le code, et voir une méthode initialement si belle et explicite polluée par des lignes de logger.trace( param = truc ).

J'ai donc créé Logeek, un outil d'instrumentation du bytecode qui ajoute ces fameux logs si indispensables et si disgracieux. Contrairement à un outil d'AOP, Logeek fait de l'instrumentation agressive en ajoutant directement un attribut logger et le traçage des paramètres dans chaque méthode, là où AspectJ déporterait l'appel dans le greffon.

En gros, partant de ce code :

public boolean doSomething( String value, int count )
{
System.out.println( "done" );
return true;
}

Loggek va modifier le bytecode pour qu'il ressemble à ceci (en pseudo-code puisque le source n'est pas modifié, et le bytecode n'a pas exactement cette structure)
private static transient Logger __logger
= LoggerFactory.getLogger( Foo.class );

public boolean doSomething(String value, int count)
{
boolean returnedvalue;
try
{
__logger.debug( "{" );
__logger.trace( " value = {}", value );
__logger.trace( " count = {}", count );

System.out.println( "done" );
returnedvalue = true;
}
catch (Throwable throwable )
{
__logger.trace( " throws {}", throwable );
throw throwable;
}
__logger.trace( " return {}", returnedvalue );
__logger.debug( "}" );
return returnedvalue;
}
Pour comparaison, AspectJ produirait une transformation du bytecode qui ressemblerait plus à ceci :

public boolean doSomething(String value, int count)
{
boolean returnedvalue;
try
{
String arg1 = value.clone();
int arg2 = count.clone();
LoggingAspect.aspectOf().before( this, arg1, arg2 );

System.out.println( "done" );
returnedvalue = true;
}
catch (Throwable throwable )
{
LoggingAspect.aspectOf().afterThrowable( this, t );
throw throwable;
}
LoggingAspect.aspectOf().after( this, returnedvalue );
return returnedvalue;
}
La différence est subtile, mais dans ce second cas la source du log est le greffon de l'aspect, pas le code instrumenté, et au passage on paye même en mode TRACE (généralement désactivé) le prix d'une copie d'arguments et de plusieurs appels de méthodes.

Avec ce mécanisme activé on obtient donc, en TRACE, toutes les infos utiles sur le code exécuté. L'utilisation de SLF4J permet de ne pas s'encombrer de if logger.isDebugEnabled(), mais l'outil pourrait tout aussi bien se baser sur l'API log4j et ajouter ces contrôles.

Pour marquer le début/fin des méthodes j'utilise des accolades, car dans un éditeur un peu malin (comme NotePad++) le curseur positionné à côté met immédiatement en évidence sa petite soeur - c'est bien pratique ;)

Tout ça via un plugin Maven, qu'il suffit d'ajouter à son POM.xml (qui sans ça serait bien trop concis)


<plugin>
<groupid>fr.loof.logeek</groupid>
<artifactid>logeek-maven-plugin</artifactid>
<executions>
<execution>
<goals>
<goal>instrument</goal>
</goals>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
<transformer>fr.loof.logeek.Slf4jLogging</transformer>
</configuration>
</execution>
</executions>
</plugin>


Logeek devrait être déployé dans le dépôt Maven central sous peu, en version 0.0.1. Je suis ouvert à toutes vos suggestions pour la 0.0.2 :)

18 septembre 2009

premiers pas avec GWT 2.0

Le plugin gwt-maven-plugin est disponible en version 1.2-SNAPSHOT avec un aperçu du support GWT 2.0. Les fonctionnalités ne sont pas forcément sans bugs et probablement encore incomplètes, mais les nouvelles options du compilateur sont déjà proposées.

La mise en oeuvre nécessite de récupérer le SDK (prendre par exemple les builds proposés par SFEIR). Configurer ensuite le plugin en affectant le paramètre gwtHome, pour le forcer à utiliser cette version, alors que par défaut il s'adapte à vos dépendances.

Vous avez alors accès à tout plein de nouvelles fonctionnalités, comme par exemple le draftCompile pour accélérer votre intégration continue, ou le rapport SOYC pour analyser la traduction de votre code Java en JavaScript et ses points noirs.

Pas de date prévue pour la finalisation de cette version 1.2, mais je vais essayer de coller à l'actualité de GWT 2.0.

14 septembre 2009

Hibernate est un sacré comique

Alerté par Julien, je fais un peu joujou avec les annotations @OneToOne et Hiernate.
Voici grosso modo ce que je manipule :


@OneToOne( fetch = FetchType.LAZY )
private Foo precedent;

@OneToOne( mappedBy = "precedent", fetch = FetchType.LAZY )
private Foo suivant;
Et là, dès que je charge une instance, j'ai autant de select qui partent en base que j'ai d'éléments dans ma chaîne suivant-précédent...

Le piège, c'est que malgré le LAZY, hibernate veut identifier si la relation OneToOne inverse (mappedBy) est renseignée ou non. En fonction de la réponse il colle un proxy ou null.

La solution, bien que pas très esthétique dans le code est simple : utiliser des OneToMany et se baser sur des collections de 1 élément :


@OneToMany( fetch = FetchType.LAZY )
private Set<Foo> suivants = new HashSet<>();

public Foo getSuivant()
{
Iterator<Foo> it = suivants.iterator();
return it.hasNext() ? it.next() : null;
}

public void setSuivant( Foo suivant )
{
for ( Foo item : suivants )
{
item.setPrecedent( null );
}
this.suivants.clear();

suivant.setPrecedent( this );
suivants.add( suivant );
}


Ca sent la grosse magouille, mais au moins ça ne casse pas la logique des get/set. Comme quoi la persistance "transparente" c'est pas encore tout à fait ça ;)

BreizhJUG - saison 2

Après deux mois de repos (?) pendant l'été, le BreizhJug repart sur les chapeaux de roue avec trois speackers pour une session spéciale "Spring ecosystem".

Comme toujours, je prépare la session au dernier moment. Je n'échapperais donc pas au gros coup de stress en me rendant compte que j'ai une fois de plus oublié un truc.

Histoire de se détendre, aujourd'hui c'est livraison au boulot, avec toute la ruche (pardon, l'openspace) attentive au moindre bug qui trainerait sous un tapis - disons que si on arrive au moins à faire passer tous nos tests jUnit ce serait un bon début.

Rendez-vous ce soir :)

04 septembre 2009

Bye bye XP, welcome 7

Hier soir, bonne surprise, mon processeur a cramé (sur le coup ça ne m'a pas vraiment fait rire).

Comme j'avais prévu de renouveler ce "bon vieux" PC j'avais déjà sous le coude les composants de remplacement, j'ai donc juste du accélérer un peu les choses... En tant que committer Apache, j'ai droit à un abonnement MSDN et donc j'ai déjà Windows 7 FR alors que vous autres pauvres mortels devrez attendre le 22 octobre ;)

Première bonne surprise, contrairement au 2h nécessaires pour installer XP, Seven s'installe "à la Linux" en une seule passe : pas de reboot en série et installation directe depuis le DVD - manque plus qu'à en faire un Live DVD ;)

Seconde bonne surprise : tout mon matos est reconnu. Heureusement vu que Micro$oft a une fois de plus revu son API de drivers (elle doit être encore mieux que celle de Vista qui était déjà bien meilleure que celle de XP qui corrigeait les défauts de celle de 2000 qui remplaçait les défaillances de NT). Donc tous mes CD d'accompagnement conservés soigneusement s'avèrent inutiles.

Je n'ai pas encore utilisé suffisamment le système pour me faire une opinion, et comme je ne suis pas passé par la case "vista" c'est assez déconcertant au début. J'ai a peu près trouvé mes marques pour l'instant.

Reste à installer la panoplie des petits softs qu'on accumule au fil du temps et qui deviennent indispensables mais dont on ne sait même plus le nom ;)

31 août 2009

les cochons dans l' (open-)space

Je découvre avec joie les plaisirs de l'openspace. Je m'en sort bien vu que le maxi-bureau est immense et réserve de grands espaces à chacun. Cependant il reste un bruit ambiant assez bas mais malgré tout omniprésent. J'ai horreur de bosser "dans une bulle" avec un casque sur les oreilles donc il va falloir que je m'y fasse, mais la concentration en souffre...
Par ailleurs, on perd en convivialité puisqu'on a plus vraiment un ou deux collègues de bureau mais un "groupe local" pas vraiment proche.
La cerise sur le gâteau c'est que le café du distributeur est infect.

Youpi youpi

11 août 2009

la bonne gestion des versions

Je me suis pris la tête avec une incompatibilité entre deux versions de bibliothèque.

J'utilise mx4j, et pour faire de l'admin à distance sans RMI (pour diverses raison que je ne vais pas développer) j'utilise un connecteur HTTP. Mx4j utilise pour ça Jetty en mode embarqué.

J'utilise aussi SoapUI, pour produire des mock des services que j'invoque. Lui aussi utilise Jetty.

Là où le bât blesse c'est que SoapUI utilise Jetty6, dont le code est complètement revu par rapport aux versions précédentes. L'API totalement incompatible rend mx4j inutilisable. Du coup je regrette presque de ne pas faire de l'OSGi - presque, je n'ai pas encore mis un orteil dans ce truc mais ça à l'air assez casse-gueule ;)

Je m'en suis sorti pour pas cher en faisant un bout de code pour adapter mx4j à Jetty6, mais j'en retiens une règle de développement : un changement d'API devrait TOUJOURS s'accompagner d'un changement de nom de package. JAXB2 utilise par exemple com.sun.xml.bind.v2. C'est peut être pas très joli, mais au moins on s'évite de nombreux conflits.

Java Cloud computing - an 1

Vous faites peut être partie de ceux qui ont reçu un "ID" pour jouer avec Google App Engine for Java.

Vous avez peut être testé le support "EC2" de Hudson pour bénéficier d'une réserve de puissance lors des piques de charge de votre intégration continue.

Dans tous les cas vous êtes convaincu que le cloud computing n'est plus une vue de l'esprit mais bien une solution concrète et disponible aujourd'hui ?

Et bien réjouissez-vous : VMWare vient de se payer SpringSource, dont l'engagement en faveur d'OSGi est bien connu. Imaginez donc une ferme de Spring DM Servers, supervisée par un monitoring Hyperic (racheté par SpringSource), et accessibles en mode cloud via des machines virtuelles sur laquelle vous déployez depuis Eclipse vos bundles OSGi métier ...

Moi, dans ma vraie vie je fais encore du JEE, et encore je viens juste de migrer en Java5, mais on peut tout de même rêver un peu ;) Quoi qu'il en soit, raisonner en "cloud" va devenir une facette importante du métier, alors préparer vous !

Besoin de pistes ? Allez lire le blog du touilleur qui vous expliquera tout sur le sujet !

10 août 2009

m2eclipse - pas encore près pour la prod !

Après des mois à essayer de configurer au mieux m2eclipse, d'alléger le workspace au maximum et de trouver des astuces pour que le "build automatically" soit exploitable sous Eclipse la conclusion s'impose : m2eclipse n'est pas prêt !

m2eclipse prend comme parti de laisser Maven gérer les "ressources" (fichiers de conf, XML...) à la place d'Eclipse. Vu que l'utilisation du filtering Maven reste marginale ça ne concerne que peu de personnes. Cependant, cela signifie pour les autres un cycle mvn process-resource à chaque build incrémental d'Eclipse.

... et il y en a un paquet des builds incrémentaux, sans parler des multi-modules ou chaque projet déclenche un build des autres. On termine donc avec des builds maven en pagaille, à reconstruire 10 fois le même module :'(

Alors, oui, m2eclipse permet à notre générateur de code de prendre en compte la moindre modification de WSDL. Mais qui modifie son WSDL chaque minute ? Le prix à payer est délirant, à moins d'avoir un PC octo-processeur à quatre coeurs (et encore ?).

Moralité : le bon vieux mvn eclispe:eclipse, bien qu'il soit parfois un peu compliqué à configurer au petits oignons (je pense à AJDT) a de beaux jours devant lui !

03 août 2009

Rumeur ...


J'apprends avec surprise par Messenger interposé que ma collègue du bureau d'à côté est enceinte de 8 mois. Il faut dire qu'avec 40KTM elle cache bien son jeu.

L'info semble malgré tout se confirmer via une autre personne (désirant rester anonyme) ayant eu une information non-confirmée concernant des triplets à venir...

L'intéressée refuse tout commentaire (c'est donc très louche), cependant le planning du projet encourage un sérieux doute avec 10 mystérieux jours de congés prévus à la fin du mois.

Reste à savoir qui est le père ...

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.

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.

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

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)

23 juillet 2009

spam attack

L'instance Jira qui héberge les rapports d'anomalies et d'évolution des projects Apache et Codehaus subit une attaque en règle de la part d'un spammeur.

De nombreux tickets sont créés avec des titres à la "Angélina Jolie Nue" et un lien vers une vidéo. Du pur spam pourri, mais l'attaque est sérieuse car le spammer semble disposer d'un grand nombre de compte, ou d'un bon script pour en créer à la demande. Le Jira comporte désormais quelques centaines de références à des stars du showbiz, ce qui change un peu des NullPointers, mais n'est pas vraiment très utile aux projets considérés.

Comme quoi le contrôler par eMail de confirmation et autre Captcha n'empèche pas ce genre de choses.