Maven/Gradle Lista skompilowanych klas

Question

Maven i Gradle oba używają domyślnie kompilacji przyrostowej, jeśli się nie mylę.

• Dla nowej/pierwszej kompilacji tworzyłaby wszystkie pliki klas.
• Przy następnej kompilacji bez żadnych zmian nie tworzy żadnych plików klas.
• Jeśli zmodyfikuję A.java, to ponownie skompiluje moduł.

Czy istnieje opcja pobrania listy plików klas skompilowanych w tej kompilacji?

Answer 1

Co powiecie na: maven.compiler.verbose?

Jeżeli ustawić go na true uzyskać albo

% mvn compile -Dmaven.compiler.verbose=true 2>&1 | grep class 
[INFO] Nothing to compile - all classes are up to date 

lub zmodyfikować plik

% mvn compile -Dmaven.compiler.verbose=true 2>&1 | grep class | grep wrote 
[wrote RegularFileObject[/tmp/mvn-compile/target/classes/A.class]] 
[wrote RegularFileObject[/tmp/mvn-compile/target/classes/B.class]] 

... and other similar output 

A.java Można również uzyskać trochę głębiej do systemu operacyjnego i śladu (np strace na niektórych dystrybucjach Linuksa) write syscalls (platformy zgodne z Posix) i grep zapisywanych plików .class.

Można również użyć opcji -Dmaven.compiler.fork=true, która widnieje javac (która była domyślna, ale już nie jest widoczna). Możesz śledzić argumenty javac, które są przekazywane przez plik tymczasowy (który istnieje tylko podczas wykonywania javac, na przykład jest to /tmp/org.codehaus.plexus.compiler.javac.JavacCompiler2179201625419771061arguments). Możesz także cat ten plik i zobaczyć, które pliki są przekazywane do javac do ponownego kompilowania. W moim przypadku (Mac OS X), ten plik jest przechowywany w /tmp i do wyjścia, ja naiwnie uruchomić

% cd /tmp; while true; do ls org.codehaus.plexus.compiler.javac.JavacCompiler* | xargs cat; sleep 1; done 
zsh: no matches found: org.codehaus.plexus.compiler.javac.JavacCompiler* 
zsh: no matches found: org.codehaus.plexus.compiler.javac.JavacCompiler* 
zsh: no matches found: org.codehaus.plexus.compiler.javac.JavacCompiler* 
"-d" 
"/tmp/mvn-compile/target/classes" 
"-classpath" 
"/Users/stepan/.m2/repository/com/typesafe/config/1.3.0/config-1.3.0.jar:/Users/stepan/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.6.4/jackson-core-2.6.4.jar:" 
"-sourcepath" 
"/tmp/mvn-compile/src/main/java/A.java" 
"/tmp/mvn-compile/src/main/java/B.java" 
"-s" 
"/tmp/mvn-compile/target/generated-sources/annotations" 
"-g" 
"-verbose" 
"-nowarn" 
"-target" 
"1.8" 
"-source" 
"1.8" 
"-encoding" 
"UTF-8" 

Inną kwestią jest to, jak Maven decyduje, która klasa rekompilacji. Jeśli dobrze pamiętam, to było oparte na porównaniu znaczników czasowych plików .java w porównaniu z ich plikami dopasowującymi .class. Jeśli plik .java był nowszy, to został dodany do javac do ponownej kompilacji. Teraz jednak widzę, że jest to o wiele bardziej skomplikowane i aby zrozumieć powody, poleciłbym wykonanie polecenia debugowania i przyjrzeć się metodzie AbstractCompilerMojo.java i jej .
Na przykład, jeśli w moim katalogu źródłowym znajduje się plik package-info.java, wszystkie klasy są zawsze rekompilowane, nawet jeśli nie zostały zmienione.