Discussion :

[isabelle_dba]

Bonjour,

Je suis nouvelle dans l'utilisation de Maven. Ce produit nous a été conseillé et je dois vérifier si nous pouvons utiliser ce produit pour nos builds. J'ai lu beaucoup sur le sujet et j'ai plusieurs interrogations. Si quelqu'un pourrait m'aider, cela serait vraiment apprécié. Merci à l'avance.

Voici mes interrogations:

Dans notre cas, Maven ne servirait pas à compiler des applications Java, mais plutôt à rouler des scripts SQL, à copier des modules (forms/reports), à déployer des ear files déjà construits sur un serveur Weblogic 10.3, à charger des fichiers xml dans une base de données et à rendre non disponible l'application. Je ne sais pas si tout cela est possible avec Maven ? Avec l'information que j'ai soutiré de plusieurs guides et forums, il semble que cela soit possible, mais je voulais valider avec l'expérience que vous avez.

Si cela est possible, est-ce que vous avez des conseils sur comment structurer le repository ? Par exemple, mettre tous les scripts sql ensemble dans un répertoire.

Pour la gestion des différents builds, je n'ai pas vu dans les documents comment conserver toutes les versions des builds. Par exemple, si nous voulons rouler le build 1.2, mais que la version du build en cours est 1.6. Est-ce que nous avons à conserver tous les fichiers pom.xml qui sont les fichiers où résident ce qui est fait dans le build pour pouvoir rerouler le build 1.2 ?


Merci.

[romaintaz]

Bonjour,

Bonjour, et bienvenue ici !

Dans notre cas, Maven ne servirait pas à compiler des applications Java

Pourquoi pas ? Maven reste avant tout un outil de build. Pourquoi ne pas l'utiliser ?
Qu'est-ce que vous utilisez pour builder vos applications ?

, mais plutôt à rouler des scripts SQL, à copier des modules (forms/reports), à déployer des ear files déjà construits sur un serveur Weblogic 10.3, à charger des fichiers xml dans une base de données et à rendre non disponible l'application. (...) Si cela est possible, est-ce que vous avez des conseils sur comment structurer le repository ? Par exemple, mettre tous les scripts sql ensemble dans un répertoire.

En fait, Maven peut presque tout faire mais ça risque d'être parfois compliqué et hors cadre.
Par exemple, il est possible d'ouvrir une boite de conserve avec une perceuse, mais il faut admettre que ce n'est pas l'outil le plus adapté

Nativement, Maven va suivre un cycle de vie assez strict. Les étapes principales sont les suivantes :

• Compilation du code
• Compilation + exécution des tests
• Packaging

Après, rien ne t'empêche de faire des choses au delà de ces actions. Par exemple déployer un WAR sur un serveur d'applications, ou autre.

Quand on sort de ce cadre, il faut trouver et utiliser le plugin qui va bien. Quand il n'existe pas ou qu'il ne répond pas à nos attentes, on peut écrire son propre plugin, ce qui n'est pas très compliqué. Il reste aussi une dernière solution : utiliser le plugin ant-run, qui permet d'exécuter des tâches Ant à un moment donné dans le cycle de vie de Maven. C'est très pratique quand on souhaite exécuter des tâches un peu complexes, comme par exemple lancer l'exécution de scripts SQL sur une base de données.

Pour la gestion des différents builds, je n'ai pas vu dans les documents comment conserver toutes les versions des builds. Par exemple, si nous voulons rouler le build 1.2, mais que la version du build en cours est 1.6. Est-ce que nous avons à conserver tous les fichiers pom.xml qui sont les fichiers où résident ce qui est fait dans le build pour pouvoir rerouler le build 1.2 ?

Là, ce n'est pas du tout à Maven (ou un autre outil de build) de se charger de cela. Les gestionnaires de sources (CVS, Subversion, Git, etc.) sont avant tout destinés à cela.
A chaque release importante, il suffit de tagguer les sources, et de cette façon, il est possible de revenir à une version donnée dans le temps.
L'intérêt d'avoir un process de build propre est qu'il est reproductible. Donc normalement, en lançant un build sur une ancienne version, ça devrait être possible.
A titre d'exemple, on me demande actuellement de remettre une version d'une application qui était en production en 2009. Il me suffit de récupérer les sources taggées à la bonne version, et de relancer un build Maven, et zou, c'est fait (hormis la base de données qui a évolué depuis, mais c'est un autre sujet).


Pour résumer, Maven est un très bon outil, mais sans doute faudrait-il se poser la question de savoir s'il est vraiment le plus adapté à tes besoins. J'ai un peu l'impression comme ça que tu souhaites prendre une voiture de courses* pour faire du tout-terrain...

Peut-être que Gradle sera plus adapté car il est plus ouvert d'esprit que Maven dès que l'on souhaite faire des choses exotiques **


* note pour Grégory s'il passe sur ce sujet : oui, je compare Maven à une voiture de courses si je veux
** note pour Grégory s'il passe sur ce sujet : oui, je dit que Gradle est exotique si je veux

[isabelle_dba]

Merci beaucoup pour les informations.

Nos applications sont des applications Forms Web, des applications Apex ou des services Web. Tous les produits utilisés sont des produits Oracle. Les services Web sont construits par un développeur utilisant JDeveloper d'Oracle. Nous ne voulons pas compiler les sources avec Maven, mais continuer à utiliser JDeveloper pour générer le fichier à installer. Nous n'avons pas d'applications Java à l'exception des services Web.

Pour déployer nos builds, nous utilisons des scripts maison en linux et une partie est faite manuellement par une administrateur. Par exemple, un build normal pour une applications Forms Web comprend en général des scripts sql, des reports, des forms et des fichiers xml. Pour une application Apex, un build ne comprend que des scripts sql. Pour une service Web, un build comprend des scripts sql et un ear file à déployer.

C'est un peu ce que je craignais avec Maven, d'être hors cadre. Mais comme vous dîtes, cela est tout de même possible, mais il va y avoir du travail à faire.

Dans notre cas, Maven n'aurait pas à compiler du code, ni à exécuter des tests et ni à packager le tout à moins que je ne me trompe. Comme Maven a un cycle de vie assez strict, est-ce que celui-ci pourrait rencontrer un problème à ne pas suivre un cycle normal ?

Au niveau du repository, j'ai lu qu'il ne fallait pas mettre de fichiers n'ayant pas de lien avec l'application Java dans le répertoire /src du projet. Est-ce que vous avez une convention pour l'emplacement des fichiers comme des scripts sql ou autres dans le projet ?

Pour revenir à la gestion des versions, cela signifie que le projet Maven fait pour l'application est une structure pour tous nos builds. Nous avons seulement à mettre les fichiers d'un build X dans les bons répertoires du build pour que Maven puisse déployer le tout. Tous les fichiers doivent donc être gérés à l'extérieur de Maven.

Ce produit a été déterminé par les architectes et je fais en quelques sortes la preuve de concept pour voir s'il répond à nos besoins.

Je prends note pour Gradle.

Merci beaucoup !
Isabelle