En essayant de builder une application avec maven, j'ai obtenu cette erreur :

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Traduction : maven a un problème de vérification de certificat SSL pour l'accès à un artifactory (dans mon cas).

Remède proposé (et testé par moi-même) : ajouter des options à la ligne de commande de maven afin de lui faire ignorer ces erreurs SSL :

mvn clean install -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true

Note : maven utilisé en version 3.8.4

Aujourd'hui j'ai vu ça dans un pom.xml maven :

<properties>
        <maven.build.timestamp.format>dd/MM/yyyy HH:mm</maven.build.timestamp.format>
        <project.build.date>${maven.build.timestamp}</project.build.date>
</properties>

Il semble que jusqu'à maven 2.x, il existait un bug faisant échouer le remplacement de la chaîne ${maven.build.timestamp} lors du filtering de ressources. La parade consistait alors à créer une nouvelle property avec cette valeur.

Le problème semble avoir été corrigé depuis maven 3.x . Il faut simplement s'assurer que la version du maven-resources-plugin est en 3.x aussi.

Je remets la réponse ici :

The compilerArgs controls the behaviour of the java compiler. These settings are passed on to the compiler, and not used directly by the maven-compiler-plugin. Using Xlint you can control which warnings the java compiler outputs from the compilation process. You can also add e.g. -Werror to abort compilation upon warnings (which in general is a good practice).

The showWarnings configuration on the other hand, is a setting for the maven-compiler-plugin (not passed on to the java compiler). It controls whether the plugin will output the warnings generated by the java compiler. So if you set it to false (I really don't understand why that is the default), you won't see the warnings generated by the java compiler. Even worse, the build will not fail even if you have set -Werror in the compilerArgs.

Pour mémoire.

Pour afficher l'arbre des dépendances d'un projet maven, il y a le plugin suivant :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>3.1.2</version>
</plugin>

Avec la commande suivante :

mvn dependency:tree

Mais il est aussi possible d'afficher un équivalent pour les plugins (ce n'est pas vraiment un arbre, mais à défaut de mieux ...) :

mvn dependency:resolve-plugins

Edit: le gars dit que it is a bad habit to specify plugin versions. C'est évidemment une bêtise.

Mon problème est le suivant : je veux savoir quels plugins sont utilisés sans déclarer explicitement leur version. Oui, c'est possible, et les devs ne se gènent pas pour le faire.

Du coup, quand je veux réunir la déclaration d'un plugin (et de sa version) dans le pluginManagement du pom parent, le build échoue à répétition car, sans version déclarée explicitement :

• dans la théorie, maven est supposé prendre la toute dernière version disponible d'un plugin;
• dans la pratique, maven prend une version parmi celles disponibles, et parfois des versions très anciennes (de plusieurs années).

Du coup on croit utiliser la dernière version du maven-assembly-plugin (par exemple), et on se retrouve avec une version vieille de 7 ans. Il faut donc dans un premier temps figer les versions utilisées des plugins. Mais pour ça, je ne vois que deux solutions :

• passer en revue à la main tous les POM du projet;
• trouver un moyen d'automatiser la recherche.

J'ai donc trouvé le plugin versions-maven-plugin :

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.8.1</version>
</plugin>

Et je vais utiliser le goal display-plugin-updates ainsi :

mvn versions:display-plugin-updates

Ca va me sortir (entre autres choses) des warnings pour tous les plugins qui ne sont pas déclarés avec une version.

Ajouter dans la balise build le plugin spring-boot-maven-plugin ainsi :

<build>
  ...
  <plugins>
    ...
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <version>2.3.3.RELEASE</version> // or your version
      <executions>
        <execution>
          <goals>
            <goal>repackage</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
  ...
</build>

Pour indiquer une destination dans le descripteur de maven assembly et ne pas avoir le warning suivant :

[INFO] --- maven-assembly-plugin:3.1.1:single (create-archive) @ monArchive ---
[INFO] Reading assembly descriptor: assembly.xml
[WARNING] The assembly descriptor contains a filesystem-root relative reference, which is not cross platform compatible /dir1
[WARNING] The assembly descriptor contains a filesystem-root relative reference, which is not cross platform compatible /dir2

Il faut utiliser la variable de maven ${file.separator} ainsi :

<fileSets>
        <fileSet>
            <directory>${project.basedir}/dir1</directory>
            <outputDirectory>${file.separator}dir1</outputDirectory>
        </fileSet>
        <fileSet>
            <directory>${project.basedir}/dir2</directory>
            <outputDirectory>${file.separator}dir2</outputDirectory>
        </fileSet>
</fileSets>

Ainsi les répertoires dir1 et dir2, situés à la racine du projet, seront placés à la racine du répertoire de destination

La demande du jour : étant donné que le build maven se fait via Jenkins, comment faire en sorte que Jenkins n'exécute pas les tests unitaires ?

Solution 1 : on crée un profil "skipTests" dans le pom.xml, dont le but est de ne jamais exécuter les tests (phase none).

Problème : les devs du projets vont voir ce profil, et risquent d'en profiter pour builder sans les tests en local.

Solution 2: dire à Jenkins de passer les tests. Comment ? Au lieu de faire mvn clean install, qui va exécuter la phase test, on lui ajoute une property spéciale code-de-merde, ce qui donne :

mvn clean install -Dmaven.test.skip=true

Il suffit de placer cette commande dans le Jenkinsfile.

Bon d'accord, le fichier est aussi à la racine du répo git. Mais seul un curieux non allergique au groovy saura le lire.

C'est l'équipe de la qualité qui va être contente :D

Comment configurer le plugin surefire pour faire en sorte que les tests java ne s'exécutent pas.

#CoucouLaSecurité
#CoucouSonar

Thx dude !

@Antichesse : effectivement. Du coup cela simplifie l'installation :

1) Télécharger la dernière version de SonarQube et décompresser l'archive à l'endroit souhaité;

2) Ajouter le plugin suivant dans le POM parent de votre projet maven (en changeant la version si besoin) :

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.sonarsource.scanner.maven</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <version>3.5.0.1254</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

3) Lancer sonar :

$SONAR_HOME/bin/$OS/sonar.sh start

4) Se positionner avec la console à la racine du projet maven, puis :

mvn clean install
mvn sonar:sonar

5) Avec un navigateur, aller à l'adresse par défaut de sonar : myserver:9000. Puis aller dans Projects et sélectionner le projet souhaité.

Je te le pique.

Pour faire fonctionner sonar avec maven :

1) Télécharger la dernière version de SonarQube et décompresser l'archive à l'endroit souhaité;

2) Editer le fichier $MAVEN_HOME/conf/settings.xml pour qu'il contienne la conf suivante (en adaptant la valeur myserver) :

<settings>
    <pluginGroups>
        <pluginGroup>org.sonarsource.scanner.maven</pluginGroup>
    </pluginGroups>
    <profiles>
        <profile>
            <id>sonar</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <!-- Optional URL to server. Default value is http://localhost:9000 -->
                <sonar.host.url>
                  http://myserver:9000
                </sonar.host.url>
            </properties>
        </profile>
     </profiles>
</settings>

3) Ajouter le plugin suivant dans le POM parent de votre projet maven (en changeant la version si besoin) :

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.sonarsource.scanner.maven</groupId>
        <artifactId>sonar-maven-plugin</artifactId>
        <version>3.5.0.1254</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

4) Lancer sonar :

$SONAR_HOME/bin/$OS/sonar.sh start

5) Se positionner avec la console à la racine du projet maven, puis :

mvn clean install
mvn sonar:sonar

6) Avec un navigateur, aller à l'adresse spécifiée dans le settings.xml (ici myserver:9000). Puis aller dans Projects et sélectionner le projet souhaité.

Edit : cette façon de faire n'est pas la meilleure car elle modifie la configuration générale de maven. Pour utiliser sonar au cas par cas selon le projet, il faut plutôt privilégier cette façon de faire.

Merci pour ça.

Contexte : lors d'un build maven, par exemple en faisant mvn clean install, un warning apparait au niveau du plugin maven-compiler-plugin disant :

[WARNING] bootstrap class path not set in conjunction with -source 8

Ce qui fait échouer le build.

Il s'avère que j'essaie de builder une application en java 8 depuis un java 10.

Explications : depuis Java 9, le JDK est composé de modules. Les jars issus de la compilation de ces modules n'ont qu'un accès limité aux classes les uns des autres. D'où le message indiquant un problème de PATH.

Solution : désinstaller java 9/10 et installer java 8.