riduidel’s posterous

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érement de faire une nouvelle version de majick-properties avec des mvn release, mais ça chie à chaqie 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.

Loading mentions Retweet

Bon, ça chie un peu tout ça.

ce week-end, je me suis diot 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 doinc 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.

Loading mentions Retweet

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 

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.

Loading mentions Retweet

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éja 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'agaçce avec une force !

Bah ! Je trouverai la solution demain.

Loading mentions Retweet

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".

Loading mentions Retweet

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

Loading mentions Retweet

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éja 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érallement, et que mon fan n'apprécie apparement 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éja 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éja 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éja.
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.

Loading mentions Retweet