Soirée Maven 3 à Grenoble

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
7
25
mar.
2010
Java
L'AlpesJug (le Java User Group grenoblois) organise une soirée spéciale Apache Maven.
Arnaud Héritier, membre des communautés Apache Maven et Codehaus Mojo et auteur du célèbre Apache Maven, vient à Grenoble nous parler de l’utilisation de Maven en entreprise et des nouveautés de la version 3.x.
L'entrée est libre et gratuite, cependant le nombre de place est limité.

La conférence aura lieu à 19h00 le 29 mars, à l'amphithéâtre E de l'ENSIMAG (Plan d'accès) Software Factory Manager pour eXo Platform, Arnaud nous présentera son retour d’expérience de l’utilisation d'Apache Maven dans une forge logicielle professionnelle : ce que Maven apporte à chaque étape de la construction d’un logiciel.
Nous aborderons ainsi successivement comment Apache Maven intervient pour chacune de ces étapes :
  • Le build du projet sur le poste du développeur ;
  • La gestion des dépendances et des dépôts ;
  • La mise en place de l’intégration continue ;
  • L’utilisation des métriques et des rapports de qualité ;
  • Le déploiement continu.
Enfin il nous présentera les nouveautés que la version 3 va apporter.

Apache Maven est un outil de build logiciel en Java (équivalent à Make). S'il nécessite Java pour s'exécuter, il est utilisé pour construire des logiciels dans d'autres langages ou d'autres plate-formes (C/C++, Flex, Androïd, C#, Scala, Groovy...).

Aller plus loin

  • # Un manque pour le C

    Posté par  . Évalué à 1.

    J'ai pas regardé depuis longtemps mais maven n'était pas très fort pour le C et les autres langages compilés.
    C'est d'ailleurs un manque, à mon avis, quand on code en C: un waf/scons avec un système de plugin et une gestion des dépendances (par les sources :) à la maven. On a bien jhbuild de gnome mais c'est pas encore la panacée ( même si le sujet reviens souvent:
    http://mail.gnome.org/archives/vala-list/2010-March/msg00049(...)
  • # Nuance...

    Posté par  . Évalué à 3.

    Maven est bien un outil de build logiciel en Java, mais il n'est pas vraiment équivalent à Make.

    Alors que Make ou Ant (équivalent de make en Java) se base sur un script qui décrit, en détail, chaque étapes du process, Maven se base sur une modélisation haut niveau du projet. Ainsi, il est inutile de décrire toujours le même process de build. Maven, par le biais de ses plugins sait faire par défaut. Les cas particulier demanderont de configurer les plugins voulu.

    Néanmoins, il n'y a pas de miracle, les processus de builds les plus tordus passent mal sur une approche Maven. Il faut pour cela, développer des plugins spécifiques, ou remettre en cause le process.

    • [^] # Re: Nuance...f

      Posté par  . Évalué à 3.

      Il a une approche différente mais il reste un outil de gestion de compilation de projet.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Nuance...

      Posté par  (site web personnel) . Évalué à 1.

      et le problème est là, à part pour faire des jar/war en java, maven est vraiment compliqué / inutilisable malheureusement
      l'approche descriptive est également trop souvent limitante.
      (à mon boulot, on utilise maven pour faire du "build" java, javascript et flex, le temps passé pour faire un truc maven correct est ... impressionnant au regard de la même chose en ant)

      une petite lecture sympa, repiquée je ne sais plus trop où : http://kent.spillner.org/blog/work/2009/11/14/java-build-too(...)
      • [^] # Re: Nuance...

        Posté par  . Évalué à 2.

        L'approche descriptive est surtout intéressante pour les IDE.

        Un même projet Maven peut être utilisé dans Netbeans ou dans Eclipse alors qu'avec des outils orientés scripts comme make on est souvent obligé de maintenir un script de compilation et un fichier de projet.
        • [^] # Re: Nuance...

          Posté par  . Évalué à 1.

          Ca fait longtemps que je n'ai pas utilisé Netbeans, mais de mémoire l'intégration des ANT se faisait assez bien ?
          J'avais essayé Ant+Apache Ivy qui a l'air assez sympa ; et il ya un plugins Eclipse. Pour des builds tordus, je me demande si ce n'est pas plus maintenable que du Maven. Quelqu'un l'utilise en vrai ?
          • [^] # Re: Nuance...

            Posté par  . Évalué à 2.

            Ant+Ivy sont utilisés dans mon entreprise, et je sais que ceux qui l'utilisent en sont très content. Ils prétendent que c'est le Nirvana, mais c'est même pas vrai, c'est juste pour embêter ceux qui ont des problèmes avec Maven.

            J'avais trouvé ceci pour conjuguer le meilleur (ou le pire) de Ant at Maven:
            - Maven Ant Tasks qui permet d'utiliser certaines capacités de Maven depuis Ant.
            - Mercury Ant Tasks, pareil, mais en plus puissant , plus testé (et moins documenté?). "It supports both new and a subset of the old maven-ant-tasks syntax."
            - Il y aussi le plugin ant pour Maven qui permet d'executer des taches Ant depuis Maven. On l'a utilisé et ca marche vraiment bien pour peu qu'on peut le faire rentrer dans la philosophie de Maven.

            Si quelqu'un a des retours d'expérience sur les deux premiers (Maven et Mercury Ant Tasks), je suis preneur.

            Et voici aussi 2 petits liens en plus (en anglais):
            http://ptrthomas.wordpress.com/2009/03/08/why-you-should-use(...)
            http://stackoverflow.com/questions/702535/using-maven-from-a(...)
            • [^] # Re: Nuance...

              Posté par  (site web personnel) . Évalué à 1.

              Maven Ant task ca marche mais c'est parfois assez chaud. Surtout dans les projets multi-modules.
              Mercury c'est le nouveau truc de Jason (si je ne m'abuse) mais je ne connais pas bien, une bonne question à poser à Arnaud ;o)
          • [^] # Re: Nuance...

            Posté par  . Évalué à 2.

            Pour des builds tordus, je me demande si ce n'est pas plus maintenable que du Maven.

            Clairement. Dans ma boite on utilise les deux :

            - Maven pour les projets Java classique : c'est simple, bien structuré et ça ne demande pas trop de boulot.
            - Ant & Ivy pour qui mixent plusieurs langages : c'est compliqué, il faut un temps fou pour maintenir le système de construction à jour, mais les projets "tordus" c'est le seul moyen.
      • [^] # Re: Nuance...

        Posté par  . Évalué à 1.

  • # Pas là...

    Posté par  . Évalué à 1.

    ... et c'est bien dommage car j'aurais bien assisté à cette conférence.

    Est-ce qu'il y a aura un enregistrement réalisé, ou une possibilité de récupérer le support de présentation, ou bien une retranscription de la conf?

    Merci!
    • [^] # Re: Pas là...

      Posté par  . Évalué à 2.

      J'y serais mais je n'ai pas les moyens techniques de l'enregistrer. S'il n'y a pas de réponse d'ici là plus probante j'essaierais de leur demander si les transparents peuvent être diffusés et je tenterais un enregistrement vocal (s'ils le veulent bien) sur mon ordinateur dans le cas où il n'y aurait pas de caméra.

      Par contre je doute d'avoir le temps de fusionner les deux…

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Pas là...

        Posté par  . Évalué à 1.

        Ce serait vraiment super! Ne te fatigue pas à fusionner les deux, j'écouterais et ferais défiler les transparents à la mimine.

        Merci beaucoup!
      • [^] # Re: Pas là...

        Posté par  (site web personnel) . Évalué à 1.

        Les slides seront diffusés librement (je ne sais pas exactement sous quelle creative commons).
        Nous allons essayer l'enregistrement (son/video) mais n'étant pas un pro de ce genre de techniques ..... on verra ce qu'on arrive à en faire.

        La fusion basique slides/son se fait bien avec slideshare (on pourra se synchroniser).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.