counter

Visitor Map

mardi 18 mai 2010

Maven 3

Maven 3 est encore dans sa version bêta, mais il promet ! Au Paris JUG, Arnaud Heritier et Nicolas De Loof nous l'ont présenté. Voici mes retours !

Migrons à Maven 3 !

Est-il facile à migrer ?
Il suffit de changer votre version de maven ! Et voilà, c'est fini !

Est-il compatible avec les versions précédentes ?
Oui, la compatibilité est assurée à un 99,99%
Les exceptions qu'on peut trouver sont par rapport aux descripteurs de projet qui sont encore beaucoup plus stricts que dans ses versions précédentes, ainsi que le Maven Site ou la commande eclipse:eclipse qui sont en phase de correction.

Les développements de cette version ont été focalisés pour assurer la compatibilité descendante, affirmation avalisée par les efforts en développement des tests unitaires.

Cette nouvelle version est en effet une refonte complète. Elle se caractérise par les retours d'expérience et l'apprentissage que ses concepteurs et développeurs ont obtenu à partir des versions 1 et 2.
La version 1 de Maven était inmaintenable ; la version 2 était plus maintenable et incluait le support de plugins. L'architecture était améliorée, mais encore pas très extensible et elle manquait de souplesse rendant très compliqué (parfois quasiment impossible) d'entrer dans le code.

Nouveautés :

> Java 5
Et tous les avantages qui vont avec, les generics par exemple. Le code source est plus propre, et la documentation a été nettement améliorée, essentiellement pour bien distinguer les API publics des internes. Grâce à tout cela, le développement des nouveax plugins et fonctionnalités est rendu plus accessible.

> Plugins interactifs
Les plugins restent toujours indépendants, mais ils sont capables de s'adapter au contexte d'exécution, ce qui est traduit par la disparition du plugin Aggregator et la naissance de "Build Plan". On pourra, par exemple, lister les tests à exécuter à l'avance. Cela évitera de les passer plusieurs fois, contrairement à aujourd'hui où les plugins ne savent pas quels sont les tests qui ont été déjà joués.

En conséquence, le plugin Aggregator ne devra plus jamais être utilisé.


> Rencontre OSGi
L'outil Tycho est une sorte de portage de Maven 2 pour les applications basées sur OSGi. Eclipse est basé sur un modèle OSGi. Maven 3 inclut Tycho, ce qui permet leur meilleure intégration. Le plugin M2Eclipse s'appuie sur Tycho.

> L'intégration avec eclipse
Maven 2 permettait seulement de réaliser des builds complets. Maven 3 permettra de laisser à eclipse l'ensemble des étapes qu'il sait faire, la compilation par exemple, et de réaliser en maven ce qui reste. Le plugin d'eclipse retirera les tâches du "build plan" évitant ainsi tout conflit.

> Pom Polyglotte
Maven 3 permettra d'écrire le fichier pom.xml en Groovy ou Python par exemple, en plus de XML.

Prochainement :
  • L'équipe maven vise à remplacer le conteneur Plexus par Google Guice ou Spring. Rien n'a encore été décidé.
  • Éliminer la maintenance du nom de version sur le POM
  • Mixins : Permettront de faire un héritage multiple mais pas forcement hiérarchique
  • Évolution de la syntaxe : permettra, par exemple, de définir des exclusions globales et pas seulement au niveau de chaque dépendance
  • Parallélisation des builds : permettra aux grosses applications multimodule de paralléliser les builds de ses modules indépendants en gagnant du temps de manière significative.
  • Maven Shell
Pourquoi continuer avec Maven, notanment Maven 3 ?
Ce n'est pas pour les nouvelles fonctionnalités que cette version apporte - on constate que n'il y en a pas trop encore - mais plutôt pour les raisons suivantes :
  • Maven 3 est plus performant
  • Les logs, en cas d'erreur, sont plus lisibles
  • Le reporting est amélioré
  • La communauté est mature et expérimentée. Nous comptons sur un grand nombre de développeurs et utilisateurs senior. De plus, la version 3 a attiré l'attention des nouveaux développeurs, ce qui a fait revivre le projet.
Une bonne référence en français :
Apache Maven de Pearson, écrit par les deux speakers !

http://www.pearson.fr/livre/?GCOI=27440100730370


Lancez-vous, migrez !

mercredi 12 mai 2010

Mon premier Paris JUG

Hier soir je suis allée pour la première fois à la réunion mensuelle de Paris JUG. Je suis allée avec le groupe JDuchess. Ceci a été une expérience géniale. Jusqu'à hier, je connaissais les duchesses par la toile, et enfin j'ai pu les rencontrer et leur donner un visage (au moins à la dizaine de participantes)

Voici mes retours de la soirée

DVCS par Sebastien Douche
Git
par David Gageot

Conférences très bien animées, avec beaucoup d'humour et très intéressantes. DCVS, Distributed Control Version System, est la version distribuée des systèmes comme CVS et SVN.
Sebastien et David, avec leurs nombreuses années d'expérience, ont constaté que :

- Chaque développeur a "sa façon de faire" : petits commits fréquents, gros commit à la fin, commiter toujours à la fin de la journée etc.
- Face à un développement assez important :
  • Le développeur passe beaucoup de temps à "merger" les changements pour pourvoir après commiter
  • Beaucoup de micro-merges sont effectués pendant la journée car la quantité de fichiers à merger est proportionnelle au temps passé sans commiter.
  • Le développeur se dépêche de commiter principalement pour laisser la fastidieuse tâche de merger à son voisin.
  • Commits fréquents, non testés, non finis, non validés
Toutes ces problématiques, encore plus aggravées dans un projet qui commence "from scratch", sont la cause directe de :
  • Trop de temps perdu
  • Un projet moins stable
  • L'impossibilité de montrer le produit au client au fil de l'eau
  • Un impact négatif sur la gestion du projet
Si on utilise des branches pour paralléliser les développements, les conséquences seront encore pires : personne n'aime les fusionner ; il est connu que cette tâche est un véritable cauchemar et que leur gestion amène beaucoup de problèmes.

La solution :
Oublier
l'utilisation des gestionnaires de versions comme CVS ou SVN et utiliser DVCS, notamment Git.

Principes : le workflow et l'orientation au contenu.

Workflow: Un développeur est confronté à plusieurs workflows.
  • workflow organisationnel : Il s'agit de la organisation qu'il faut mettre en place pour le développement d'un produit.
  • workflow personnel : Il s'agit de la façon de travailler de chaque développeur
  • workflow inter-personnel : Il s'agit de la façon dont chaque développeur travaille avec l'équipe autour de lui
Orientation au contenu :
Contrairement au CVS ou SVN (outils VCS) qui sont orientés au ChangeSet, les noms des fichiers sont dissociés aux contenus.

Chaque acteur compte avec son repository en local et peut s'organiser comme il veut. On fait tous les commits qu'on souhaite.
Une fois la fonctionnalité est finie, on "push" l'ensemble fonctionnel sur le repository central.

Ainsi :

- Nous nous focalisons sur notre code
- Nous avons tout l'historique en local
- La résolution de conflits est plus intelligent
- Nous pouvons travailler en mode déconnecté
- Il nous permet d'automatiser l'intégration continue en local et de pusher automatiquement au dépôt central si le build est stable.
- Il est capable de détecter les renommages des fichiers rendant faciles et rapides les refactoring du code.
- Non seulement toutes les utilités de SVN sont disponibles mais plus encore ; par exemple, "git bisect" nous aide à savoir quel commit a cassé notre build en l'absence d'erreur de la part du serveur d'intégration continue.
- Vitesse, souplesse et cherry picking entre autres caractéristiques.


Plus de .svn et .cvs partout ! Plus de regrets lors de la copie d'un répertoire !

Et pour commencer en douceur et convaincre le client ?
Binding ! On peut garder notre serveur SVN et travailler avec Git :o)

La meilleure façon de commencer est la pratique : GitHub !

J'ai déjà utilisé GitHub pour "Tapestwitter" http://github.com/lguerin/tapestwitter et je suis encore plus convaincue qu'hier matin !

Plus d'information sur le site : GIT - Fast Version Control System

ParisJUG : Paris JUG

Pourquoi ce blog ?

Salut !

Je suis développeur java/j2EE et je voudrais partager et écrire sur des sujets dont je travaille.

Étant l'espagnol et le basque mes langues maternelles, quelqu'un pouvait se demander (ou pas) : pourquoi en français!?!? :D En fait, la réponse est très égoïste : j'ai besoin de rédiger en français pour améliorer cette facette! Effectivement, je commence à me débrouiller à l'oral; par contre le français écrit je ne le pratique pas aussi souvent! Comme on dit en espagnol "matamos dos pajaros de un tiro!" : J'améliore mon français et je partage certains expériences avec les personnes intéressés !

Les textes, je vais les corriger petit à petit ; je vous encourage à me faire des remarques !

Je ne corrige pas ce post, je reviendra sur lui d'ici à quelques semaines, ou mois, pour constater mes progresses! (ou pas :( mais soyons optimistes!! :o) )

Ya esta !

como me han dicho que el primer mensaje tiene que ser un asco, ahi va ! :D
yupi! ya tengo un blog! yujuuu