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.

Pour mémoire.

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.

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

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

#CoucouLaSecurité
#CoucouSonar

@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é.

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.

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.