web-dev-qa-db-fra.com

Le plugin Maven compiler détecte toujours un ensemble de sources comme "obsolète"

FIXED: c'est un bug connu dans maven-compiler-plugin 3.1

Je suis en train de convertir une version de maven d'une version à partir de plus de 1000 sources Java. Jusqu'ici tout va bien, mais à chaque fois lancer mvn compile tout recompile (au lieu de réutiliser les anciennes classes)

Utiliser mvn -X compile signale que

[DEBUG] Stale source detected: /project_path/src/main/Java/package_path/AFile1.Java
[DEBUG] Stale source detected: /project_path/src/main/Java/package_path/AFile2.Java
...

(uniquement pour les fichiers d'un certain paquet, ce qui n'est peut-être pas référencé par le reste du code; pas mes sources, j'essaie simplement de minimiser la construction)

La compilation n'échoue pas et des classes avec des horodatages mis à jour sont générées à

/project_path/target/classes/package_path/AFile1.class
/project_path/target/classes/package_path/AFile2.class
...

Toutefois, lorsqu’on examine les horodatages, les fichiers Java n’ont pas changé depuis hier et les fichiers de classe sont à jour. Pourquoi ces sources sont-elles considérées comme périmées? Comment puis-je déboguer ce problème?.

Il est difficile de recompiler 1k + fichiers même lorsqu'aucune modification n'est survenue ...

Exemple de sortie:

$ mvn clean compile
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building MyProject 1.9.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for net.sourceforge:jffmpeg:jar:1.1.0 is missing, no dependency information available
[INFO] 
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ my-project ---
[INFO] Deleting /project_path/target
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ my-project ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /project_path/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ my-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1162 source files to project_path/target/classes
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.215s
[INFO] Finished at: Tue Jul 30 12:42:25 CEST 2013
[INFO] Final Memory: 25M/429M
[INFO] ------------------------------------------------------------------------



$ mvn compile
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building MyProject 1.9.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for net.sourceforge:jffmpeg:jar:1.1.0 is missing, no dependency information available
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ my-project ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /project_path/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ my-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1162 source files to /project_path/target/classes
... 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12.140s
[INFO] Finished at: Tue Jul 30 12:42:44 CEST 2013
[INFO] Final Memory: 22M/379M
[INFO] ------------------------------------------------------------------------
javamavenbuild
43
tucuxi

C'est un problème connu dans maven-compiler-plugin 3.1. Il est suivi dans https://issues.Apache.org/jira/browse/MCOMPILER-209 (le drapeau useIncrementalCompilation est cassé). 

Le problème n’est pas lié à un autre bogue 3.1, https://issues.Apache.org/jira/browse/MCOMPILER-205 (où les fichiers qui ne produisent pas de sorties .class sont toujours marqués comme «obsolètes»). 

Après des tests plus poussés, revenir à la version 3.0 n’a pas résolu le problème (cela ne fonctionne que jusqu’au prochain mvn clean compile. Cependant, comme Michael Lemke l’a suggéré dans les commentaires, marquer useIncrementalCompilation à false est un substitut pratique; maintenant, seul le paquet incriminé est recompilé chaque fois. temps (au lieu de toute la base de code).

29
tucuxi

Maven peut afficher un message du type:

[INFO] Changements détectés - recompiler le module!

Parce que le projet contient un fichier Java vide (ou tout commentaire) qui ne se compile jamais dans un fichier de classe.

Vous pouvez identifier la raison pour laquelle maven reconstruit en exécutant maven avec -X. Regardez près du message ci-dessus.

11
jm.

Ma situation était légèrement différente et j'ajoute simplement ceci au cas où quelqu'un d'autre aurait le même problème. Mon projet n'a pas de classes générées ni de package-info.Java; uniquement .Java fichiers dans src/main/Java.

tl; dr

Mettez à jour vers maven-compiler-plugin 3.1 ou utilisez maven-compiler-plugin 3.0 et ne définissez pas <overwrite>true</overwrite> dans maven-resources-plugin.

Version longue

Avec zéro changement d'arborescence src, Maven affichait toujours les résultats suivants:

$ mvn -o compile

[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ my-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 134 source files to /home/me/my/project/target/classes

Je pensais que c'était la configuration du maven-resources-plugin dans un POM parent utilisé par mon projet.

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <overwrite>true</overwrite>
    </configuration>
</plugin>

La suppression de ce plugin du POM parent ou la redéfinition de mon projet avec <overwrite>false</overwrite> a résolu le problème de construction incrémentielle.

Je me suis demandé pourquoi je devais faire deux versions après la définition de <overwrite>false</overwrite> pour que Maven puisse effectuer à nouveau des versions incrémentielles. C'est simplement parce que la première compilation génère un fichier (appelé inputFiles.lst) qui est utilisé pour déterminer les fichiers qui ont été modifiés. Ainsi, lors de la prochaine compilation, il peut utiliser ce fichier pour détecter les modifications. Ceci est confirmé par un commentaire sur MCOMPILER-187.

J'ai réalisé que j'utilisais maven-compiler-plugin 3.0 et que je pouvais simplement passer à

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
</plugin>

qui a également résolu le problème. 3.1 utilise maven-shared-incremental 1.1 (au lieu de 1.0 utilisé par maven-compiler-plugin 3.0. Notez que MCOMPILER-187 et MSHARED-264 sont les deux bogues qui couvrent le changement.

De retour avec maven-compiler-plugin 3.0, j’ai observé que le target/maven-status/maven-compiler-plugin/compile/default-compile/inputFiles.lst n’était pas généré avec <overwrite>true</overwrite> set. Donc, ceci pourrait être la raison pour laquelle un projet ne parvient pas à disposer de versions incrémentielles lors de l'utilisation de maven-compiler-plugin 3.0.

Clairement, il n’est généralement pas souhaitable de remplacer toutes les ressources compilées, mais le problème principal est que inputFiles.lst n’est jamais généré et que Maven ne pourra donc jamais créer de construction incrémentielle. Donc, vérifiez l'existence de inputFiles.lst car peut-être qu'un autre plugin l'a empêché de générer.

6
andyb

Je ne comprends pas pourquoi, mais la solution de la réponse de tucuxi ne fonctionne pas dans mon cas. Dans mon projet, il existe des milliers de fichiers générés par un outil spécial et sa recompilation risque de perdre beaucoup de temps.

J'ai essayé la configuration de plugin suivante (avec Java niveau 1.5):

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.1</version>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>
        <useIncrementalCompilation>true</useIncrementalCompilation>
    </configuration>
</plugin>

Lors d'une seconde exécution, aucun fichier périmé n'a été détecté, mais le plug-in a recompilé tout le projet. Il semble que la compilation incrémentielle soit réellement désactivée par défaut et ne fonctionne toujours pas, même si useIncrementalCompilation = true est spécifié.

Après quelques recherches sur Google, j'ai simplement changé la valeur du paramètre useIncrementalCompilation de "true" à "yes", ce qui me permet de résoudre le problème.

@voir également stackoverflow.com/a/19653164/1848640

4
Stanislav Mamontov

Si vous êtes sûr qu'il n'y a pas eu de changement, vous pouvez transmettre -Dmaven.main.skip. J'ai un projet dans lequel je fais cela après avoir exécuté Proguard, car c'est le seul moyen de réutiliser le fichier jar Proguarded à des fins de test. (Remarque: j’effectue les mêmes tests unitaires avant et après Proguard, pour vérifier que Proguard n’a rien cassé. Pour que cela soit aussi proche que possible du flux de travail Maven standard, j’effectue l’analyse pré-Proguard sous Surefire et post-traitement. Proguard exécuté dans Failsafe.)

1
user833771

Cela peut également se produire si votre emplacement de fichier source et votre nom de package ne correspondent pas.

par exemple. si vous avez un fichier source dans src/main/Java/com/example/MyClass.Java mais que la classe est déclarée dans un package com.example.util ne correspondant pas:

package com.example.util;

class MyClass { ... }

Le fichier de classe compilé se retrouvera dans target/classes/com/example/util/MyClass.class et cela confondra la vérification du "fichier périmé".

0
Gary

J'ai annulé le plugin maven compiler vers la version 2.3.2 et il ne compile que des classes modifiées avec Java 8 sans problèmes.

0
Ruslanas