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 !