04 septembre 2014

Pas de javax.enterprise.configuration

Anatole Tresch a annoncé que la société qui l'emploie et soutien son activité au sein du JSR, Crédit Suisse, ne désire pas soutenir le développer du TCK et de l'implémentation de référence de la spec "java configuration", coupant l'herbe sous le pied à cette proposition.

Faut il pleurer ? Je ne pense pas. Cette spec vise à formaliser une API d'accès à des données de configuration des applications JavaEE, avec évidemment de nombreuses interrogations sur l'impact avec CDI et les diverses specs/frameworks qui proposent déjà ce genre de choses.

Pour ce qui me concerne, une spec limitée à Java EE sur un thème aussi fondamental n'a aucun intérêt. Par ailleurs, comme je l'ai déjà indiqué sur ce blog, la spec se concentre sur l'interaction du code de l'application avec la configuration, et non sur la gestion de la configuration des applications. Choisir de standardiser apache commons-configuration ou spring-truc n'a pas un grand intérêt amha, par contre définir comment déclarer de manière standard la conf de mon appli sur mes instances de production, là j'y vois une valeur ajoutée.

A ce jour, j'utilise tout simplement des System properties, qui suffisent très largement à tout ce dont j'ai besoin. Une petite couche utilitaire pour convertir ou injecter ces données ne serait pas de refus, mais pas indispensable. Les plateformes Cloud fournissent toutes un moyen de définir ces propriétés système pour une application, permettant à l'application d'être vierge au moment de son packaging, et non de se coltiner un N-ième deployment descriptor.

Bref, bye bye Java EE Configuration, tu ne me manquera pas.

02 septembre 2014

Construction d'un tourniquet (1/?)

C'est la rentrée des classes, et donc le jour où je pense très fort à mes gamins, à tel point que j'ai eu l'idée de leur construire un tourniquet (oui je sais, ça aurait été plus utile AVANT l'été).

En fait je vais bientôt avoir un voisin (sic) dans ma campagne profonde, car la ferme en ruine un peu plus bas est en rénovation. En déblayant le "jardin", le futur propriétaire a trouvé sous les ronces une vielle remorque pourrie, dont il m'a offert l'essieu à moitié carbonisé.

Après démontage, l'un des moyeux s'avère bien grippé, mais l'autre encore en bon état. Planté verticalement il servira d'axe de rotation au tourniquet. Un petit passage par 123roulements.com pour commander de nouveaux joints et ça devrait faire l'affaire.


Prochaine étape : le socle - mais en attendant, fin de la pause, j'ai aussi un "vrai" boulot dans la vie...


La question qui tue : vais-je exploser le record de fréquentation de ce blog, jusqu'ici détenu par mon article "comment creuser un puit", loin devant les sujets Docker, Maven et compagnie ? 

31 août 2014

Maven release hell

As my daily work I contribute few bug fixes to jenkins plugins and officially maintain some of them, so have to run the release process so a new version is available in Jenkins update-center and my customer can get the fix.

maven-release-plugin rely on maven scm adaptor fir git command line client, and there's some odd incompatibility with recent git releases, so if you don't run "latest" you end up with some broken release. What I used to see is release tag created and pushed to origin, but no release commit.



The option I used to apply to fix this with the plugins I maintain was to force the release plugin version in pom.xml. Anyway this doesn't make much sense imho to pollute the pom with such a local issue.

Took me a while, but I re-discovered I can just force the plugin version to be used by passing the full GAV to maven command line :

mvn org.apache.maven.plugins:maven-release-plugin:2.5:release:prepare
mvn org.apache.maven.plugins:maven-release-plugin:2.5:release:perform

This is a tip I should include in my book ...