grmbl

Ca m'énerve ce merdier, ça m'énerve !

Ca fait maintenant une semaine que je galère sur ce foutu bazar que peut être l'ensemble maven/google code/subversion.

J'essaye désespérément de faire une nouvelle version de majick-properties avec des mvn release, mais ça chie à chaque fois d'une façon tellement lamentable que je sens bien que je vais lâcher l'affaire et trouver une autre solution pour faire de nouvelles versions…

Malheureusement, le problème, c'est que j'ai bien l'intention d'utiliser ma magie pour développer jPhotoOrganizer. Alors si je ne suis même pas capable de faire de versions correctes, je me demande bien comment je vais pouvoir utiliser le code de majik-properties …

Mais bon, pour l'instant, j'arrête de me prendre la tête avec ces histoires de livraisons.

maven, google code, svn, toussa

Bon, ça chie un peu tout ça.

ce week-end, je me suis idiot que j'allais faire une release de majick-properties, parce que le code me paraissait suffisant pour une alpha 0.1.

Donc, n'écoutant que mon mavenisme, j'ai lancé un simple

mvn release:prepare

Et dès le départ, grosse déconvenue.

En standard, j'avais mis mon projet maven en UTF-8, et je demandais à Eclipse d'enregistrer (par défaut) en cp-1252. J'ai donc dû transcoder tous mes fichiers en UTF-8 à grands coups d'édition dans Notepad++. Long, pénible, et surtout, inutile.

Inutile parce que, dans Notepad++, il y a deux UTF-8 :

  • UTF-8 classique
  • UTF-8 sans BOM

Et figurez-vous que le compilateur Java a un bug connu avec l'UTF-8 classique : il lit le BOM comme un octet normal et considère que ce n'est pas un élément valide.

Du coup, j'ai dû reconvertir tous mes fichiers en UTF-8 sans BOM. Temps perdu ? environ 1/2 heure.

Ensuite, j'ai relancé maven, qui m'a dit que je n'avais pas de client svn valide. sans doute parce que pour faire des releases, il faut avoir un client svn en ligne de commande, et non pas celui intégré à Eclipse … Attendez une seconde … Si j'avais fait le mvn release:prepare dans Eclipse, ça aurait pu marcher ? J'essayerais ce soir, tiens.

En attendant, j'ai téléchargé slicksvn, qui semble être devenu le client officiel.

Et maintenant, ça coince juste sur le svn tag, qui semble être lié au fait que je lance mon mvn release:prepare sans donner mon login/pwd …

Du coup, je suis un peu blasé. Mais je vais y arriver quand même (de toute façon, je n'ai pas trop le choix, si je veux pouvoir utiliser majick-properties partout dans le monde, je dois passer par les releases.

Tester l’utilisation de la mémoire

Dans majick-properties, je suspecte le code que j'ai écrit d'être potentiellement à l'origine de fuites de mémoire. Et ça, c'est plus qu'embêtant quand on fait une bibliothèque dont le but est de faciliter la vie.

Surtout que, traditionnellement, la chasse aux fuites mémoires en Java est compliquée : il faut un profiler (en Java, le meilleur rapport qualité/prix est obtenu avec le profiler de NetBeans), trouver le truc qui foire, le corriger, et espérer que ça tienne 

360

Heureusement, la communauté Java dispose maintenant de méthodes permettant de vérifier que ces fuites de mémoire ne reviennent pas. La première que j'ai trouvé utilise une librairie dont le nom seul est un hommage au bont goût : insane. Et la deuxième utilise jUnit pour parvenir au même résultat, ce qui fait que je vais pouvoir utiliser les concepts dans mes tests. Je me demande quand même s'il ne va pas falloir que je regarde insane de prés pour améliorer ça, parce qu'en fait, cette deuxième solution ne semble pratique que quand on sait précisément ce qu'on cherche, alors que la première est plus efficace en terme d'exploration.

Tiens, au fait puisqu'on parle de mémoire en Java, il semble que cet article : understanding weak references, soit une mine d'infos sur les distinctions subtiles entre weak, soft et phantom references.

sacrénom d’un bug !

C’est le genre de trucs qui m’énervent, ça.

J’ai voulu être sérieux, j’ai fait une tonne de tests unitaires, et sans même avoir de rapports de couverture de test dans maven, je suis déjà certain d’avoir au moins 75 % du code testé.

Enfin, testé … dans Eclipse.

Parce que dans Maven, c’est une autre histoire. J’ai une espèce de sale foutu bug qui fait que mon premier test unitaire Swing (qui utilise bien sûr FEST-Swing) ne s’arrête pas.

Ah, si mon fan était là ! Il me dirait bien sûr que c’est un sale problème d’utilisation de l’EDT. Ouais, enfin bon, quand je regarde le code de mon test, il n’y a pas grand chose qui me choque.

Et encore moins quand j’utilise les méthodes de FEST-Swing pour m’assurer que je fais tout dans l’EDT.

Bref, je vais être bon pour fouiller.

Ce que ça a de particulièrement agaçant, c’est que comme le test ne se termine pas, je n’arrive pas à faire de

mvn deploy

Et ça, ça m’agace avec une force !

Bah ! Je trouverai la solution demain.

Un peu d’avancement, et pas mal d’eclipse

Les vacances n’ont pas été si infructueuses que ça …

J’en ai profité pour écrire pas mal du code de majick-properties, et j’essaye maintenant de l’envoyer chez google. Hélas, hélas, l’intégration de subversion dans Eclipse ganymede est plutôt pourrie. On se demande bien pourquoi …

Bref. Je suis du coup en train de réinstaller mon Eclipse pour pouvoir faire marcher au moins un plugin Subversion, et pour pouvoir donc balancer une version compilée de mon code dans le grand bain de l’open-source.

La galère, quoi.

Néanmoins, je vais rajouter un peu de doc et faire deux ou trois trucs pour que ce soit « présentable ».

Des nouvelles des properties

Bon, vous le savez, j'ai entamé un projet de propriétés améliorées en Java. Voici donc quelques nouvelles en vrac.

  • J'ai amélioré la page d'accueil Google Code, histoire que ça ait l'air moins vide.
  • J'ai voulu faire des tests unitaires avec FEST-mock, mais c'est juste une surcouche à EasyMock, du coup j'en suis vite revenu à jMock, que je connais un tout petit peu mieux.
  • En revanche, dans le même projet, FEST-Swing est une tuerie. Beaucoup plus agréable à utiliser qu'Abbott, avec juste un petit problème de dispose des ressources à la fin des test.
  • En termes d'avancement, j'ai fini la partie "modèle", c'est-à-dire définir des propriétés et faire en sorte que ça colle bien, et j'ai entamé la phase "génération d'interface graphique". Pour l'instant, je génère des éditeurs pour les textes.

Il me reste quand même pas mal de questions.

  • Est-ce que je dois rendre mes propriétés sérialisables quand c'est utile ?
  • Comment faire pour utiliser au mieux les noms des propriétés ? ce qui en soi est un problème assez pointu. En effet, je peux utiliser des noms distinct du nom de la propriété en java, mais je trouve que c'est mieux d'avoir un nom bien ancré dans le code. Dans ce cas, comment faire pour récupérer une info sur un champ dont je ne connais pas la valeur, ni le nom, et peut-être même pas le type ?
  • Est-ce que je dois rendre mes propriétés sérializables ? Ou externalizables ? A mon avis, oui, mais faut voir …

majick-properties

La semaine dernière, j'ai eu une super idée.

Tellement super, même, que je me suis dit que j'allais en faire quelque chose …

Et donc nous y voilà.

Bien évidement, je devrais plutôt vous expliquer pourquoi je ne me fatigue même pas à réutiliser bean-properties, mais je n'en ai pas vraiment envie.

En fait, je vais plutôt vous parler des décisions que j'ai déjà prises.

Contrôle de source

J'aurais pu utiliser Git, et donc GitHub, pour me la péter, avoir du style, tout ça. La raison en est bien simple : les plugins git pour Eclipse et NetBeans sont pour l'instant expérimentaux, alors que subversion est une solution beaucoup plus largement éprouvée.

Par voie de conséquence, si je peux dire, ça me conduit tout droit à la solution que j'utilise généralement, et que mon fan n'apprécie apparemment pas trop (mais s'il se contente de dire "c'est nul", autant qu'il se taise, hein) : Google code. Ils offrent une gestion de projet simple, un svn, un wiki, des listes de diffusion, tout ça pour pas bien cher, quand même. Du coup, pouf, voilà : majick-properties.

Tests divers

Bon, je ne sais pas encore si je vais choisir jUnit ou TestNG comme base de tests, mais je sais en tout cas que je vais utiliser Fest.

Parce que bon, j'ai déjà fait des tests avec des outils comme jMock et Abbott. Mais le problème des dépendances de tests, c'est qu'elles risquent parfois d'être incompatibles entre elles, comme précisément les deux du dessus.

Et comme Fest fait au moins le même boulot que ces deux-là, ça vaut largement le coup.

Et si mon fan se pose encore la question, j'ai déjà créé mon projet Maven. Mais comme je suis un dingue, et grâce à maven, je vais essayer de tout faire sans Eclipse, mais avec Netbeans.

Le sens de la manoeuvre

A partir de maintenant, ça n'est plus bien compliqué :

  1. Ecrire le code de l'interface.
  2. Ecrire les implémentations nécessaires pour les cas que je connais déjà.
  3. Faire les tests unitaires qui vont bien.
  4. Générer les composants graphiques à partir de ces propriétés.

Et faire un truc qui déchire, surtout.