new Blog( perso );

Une nouvelle licence vient de voir le jour, la plus restrictive jamais imaginée à ma connaissance (mais je peux me tromper)

Ce n'est pas de la GPL ou d'une de ses variantes, qualifiées de "virales" - terme qui semble taillé pour faire dresser les cheveux des DSI.

Ce n'est pas non plus d'une licence calculée au nombre de coeurs CPU, ce qui est pourtant un concept déjà assez étonnant qui oblige à acheter plusieurs machines là où une seule suffirait.

Non, je parle de la licence qui accompagne le lancement de l'iPhone de 4ème génération, licence qui dicte purement et simplement l'environnement de développement autorisé. Vous devez donc EXCLUSIVEMENT utiliser le SDK Apple et le langage de programmation ObectiveC pour avoir accès à l'AppleStore. Pas de traduction de langage, d'èmulateur ou d'interpréteur JIT, rien que du "made by Apple" et rien d'autre.

A ce rythme, la version 5 imposera de développer sur MacBook Pro 15" ou supérieur exclusivement, ou encore de disposer d'un abonnement internet d'un partenaire Apple pour uploader sur l'AppleStore, ou peut être de boire exclusivement de la Budweiser, qui sait.

Alors, oui, Apple dispose d'ergonomes de génie, d'un marketing à faire pâlir n'importe qui, mais faut pas pousser. Si c'est la seule arme de l'iPhone pour couper l'herbe sous le pied des développements compatibles iPhone + Android via un langage pivot, ça ne va pas dans le sens de belles applications innovantes et universelles à des prix accessibles.

Une grande majorité des projets basés sur Maven suit la convention de décomposer le projet en modules, selon l'architecture ou les domaines fonctionnels de l'application. Assez fréquemment on retrouve donc quelques modules bas niveau sur lesquels sont basés des module plus avancés, services web, batchs ou IHM web.

Un build "classique" enchaîne la construction de ces modules sans tirer parti du parallélisme de l'architecture de la machine. Si les I/O restent un élément important dans la vélocité du build (pour ma part, mon repository local est dans un RamDisk ce qui booste bien les choses), il est dommage de laisser nos quad-core dormir en attendant la prochaine compilation.

Depuis la semaine dernière, le trunk de Maven3 intègre une évolution qui était pour l'instant développée sur GitHub en pure expérimentation : il s'agit de la parallélisation du build. Pour expérimenter cette option, vous pouvez récupérer un nightly-build de maven 3 sur l'intégration continue du projet.

L'option -T permet de définir le nombre de threads qui vont supporter le build. Maven se charge de répartir la construction des modules du projet sur ces différents Threads et de réordonner le log pour qu'il reste lisible selon un ordre "classique".

Pour ma part, je n'ai pas réussi à le faire fonctionner sur des projets significatifs. Avec mon "gros" projet, je tombe sur une ConcurrentModificationException lors de la compilation AspectJ. Sur un build Archiva qui trainait sur mon disque (nostalgie...) c'est l'instrumentation JPox qui échoue.

Il est probable qu'aucun plugin maven ou outil impliqué dans le build n'ai prévu jusqu'ici d'être utilisé dans un cadre multi-threadé de ce type... il va donc y avoir une grosse campagne de test et d'évangélisation à prévoir. En attendant, Maven est à ma connaissance le seul outil de build a expérimenter cette voie, qui devrait prendre tout son sens sur les fermes d'intégration continue disposant de multi-coeurs et qui pourraient ainsi devenir très réactives.

Wait & See...