3. Build automation
• Première étape de l’industrialisation : recréer un artefact de
manière fiable depuis le code source.
• Principe dans le cadre de l’intégration continue: à chaque
changement du code source (commit) on build l’artefact et
on exécute les tests unitaires.
• Ainsi, on s’assure du bon fonctionnement des nouvelles
fonctionnalités et de la non régression
5. Ant
• Ant follows an imperative approach.
Developers have to take care of all build
aspects by themselves. For example, they
have to generate directories for the compiled
code and explicitly handle dependencies
between the individual parts of the build. In
essence, the developers have to implement
the build completely by themselves in a step-
by-step manner.
6. Maven
• uses a declarative approach.
• For many aspects of the build it predefines conventions
that Maven projects have to abide by.
• Examples :
• the locations where source code and tests are stored,
• the directories for the build results,
• the sequence of the build phases.
• This renders the configuration of a build very easy.
• However, wherever a build deviates from the convention
or where configurations have to be changed, the
developer has to specifically declare this.
• In practice Maven builds are often even more complex
than builds with other tools.
• In any case the sequence of phases of a build has to fit to
the life cycle model of Maven, which defines the different
build phases.
7. Gradle
• newest approach with regards to Java build
tools.
• combine the best aspects of the imperative and
the declarative approaches.
• As in the case of Maven, with Gradle many
aspects of a build are defined by conventions.
• However, if the conventions do not fit, Gradle
allows the developer to completely deviate from
them and to implement independent processes
with the help of the Gradle DSL or the
programming language Groovy on which Gradle
is based.
9. Maven
• Basée sur une approche declarative opposée à Ant.
• Les aspects principaux du build sont fixés par des
conventions auxquelles les projets maven doivent se
soumettre.
• Un build standard maven comprend de nombreuses phases.
• Les plugins maven implémentent concrètement les tâches
correspondants à ces phases
10. Project
Object
Model
• La base dans Maven
• Fichier XML contenant les informations et les détails de configuration
utilisés par Maven pour «builder» le projet
• La plupart de ces valeurs sont définies par défaut, exemples
le dossier de build target
le dossier source src/main/java
les sources de test src/test/java
11. Super POM
• La POM par défaut de maven
• Toutes les POM étendent la Super POM
la configuration définie dans la Super POM est héritée par
les POMs de vos projets.
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html
14. minimal POM
• Le minimum à redéfinir pour un projet :
groupId, artifactId et version
• Définissent le nom complet de l’artefact sous la forme
<groupId>:<artifactId>:<version>
• Avec cet exemple: "com.mycompany.app:my-app:1".
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
</project>
15. Exercice
• Faites un fork du projet StringCalc sur github
• Clonez-le sur votre PC et
• faites un checkout de la branche minimalpom
• git checkout minimalpom
• tentez de lancer la suite de tests
• Ajoutez les dépendances manquantes
comment intellij peut-il vous aider?
• Quels problèmes subsitent encore?
16. Maven commentaires
• Très conservateur au niveau des configurations
• P.ex par défaut, java 1.5 alors que 1.8 est la version courante
• nécessité d’écraser un grand nombres des conventions par
défaut.
23. - C. Baudet
Machine avec
Maven
Dépôts de librairies
sur le web
Dépôts de librairies
de votre institution
http://repo1.maven.org/
Votre dépôt
local
Pour les
ressources
institutionnelles
- Archiva
- Nexus
- Artifactory
Maven dépendances