javac opcja rekurencyjnej kompilacji wszystkich plików java w danym katalogu

Używam kompilatora javac do kompilowania plików Java w moim projekcie. Pliki te są rozłożone na kilka pakietów tak: com.vistas.util, com.vistas.converter, com.vistas.LineHelper, com.current.mdcontect.

Każdy z tych pakietów zawiera kilka plików java. Używam javaca w ten sposób:

javac com/vistas/util/*.java com/vistas/converter/*.java
      com.vistas.LineHelper/*.java com/current/mdcontect/*.java

(w jednej linii)

Zamiast podawać tak wiele ścieżek, jak mogę poprosić kompilator o rekursywną kompilację wszystkich plików java z nadrzędnego katalogu com?

Sugerowałbym również użycie jakiegoś narzędzia do budowania ( Ant lub Maven , Ant jest już sugerowane i jest łatwiejsze do rozpoczęcia) lub IDE, które obsługuje kompilację (Eclipse używa kompilacji przyrostowej ze strategią uzgadniania, a ty nawet nie musisz pamiętaj o naciśnięciu dowolnego „Kompiluj” ).

Korzystanie z Javac

Jeśli chcesz wypróbować coś dla większego projektu i nie masz w pobliżu żadnych odpowiednich narzędzi do kompilacji, zawsze możesz użyć małej sztuczki, która javacoferuje: nazwy klas do kompilacji można określić w pliku. Po prostu musisz przekazać nazwę pliku do javacz @przedrostkiem.

Jeśli możesz utworzyć listę wszystkich *.javaplików w projekcie, jest to łatwe:

# Linux / MacOS
$ find -name "*.java" > sources.txt
$ javac @sources.txt

:: Windows
> dir /s /B *.java > sources.txt
> javac @sources.txt

• Zaletą jest to, że jest to szybkie i łatwe rozwiązanie.
• Wadą jest to, że musisz ponownie sources.txtgenerować plik za każdym razem, gdy tworzysz nowe źródło lub zmieniasz nazwę istniejącego pliku, co jest łatwe do zapomnienia (a więc podatne na błędy) i męczące zadanie.

Korzystanie z narzędzia do budowania

Na dłuższą metę lepiej jest używać narzędzia, które zostało zaprojektowane do tworzenia oprogramowania.

Korzystanie z Ant

Jeśli utworzysz prosty build.xmlplik, który opisuje, jak zbudować oprogramowanie:

<project default="compile">
    <target name="compile">
        <mkdir dir="bin"/>
        <javac srcdir="src" destdir="bin"/>
    </target>
</project>

możesz skompilować całe oprogramowanie, uruchamiając następujące polecenie:

$ ant

• Zaletą jest to, że używasz standardowego narzędzia do budowania, które można łatwo rozszerzyć.
• Wadą jest to, że musisz pobrać, skonfigurować i nauczyć się dodatkowego narzędzia. Zauważ, że większość IDE (takich jak NetBeans i Eclipse) oferuje świetne wsparcie dla pisania plików kompilacji, więc nie musisz niczego pobierać w tym przypadku.

Korzystanie z Maven

Konfiguracja i praca z Maven nie są takie trywialne, ale nauka tego się opłaca. Oto świetny samouczek, aby rozpocząć projekt w ciągu 5 minut .

• Jego główną zaletą (dla mnie) jest to, że obsługuje również zależności, więc nie będziesz musiał pobierać więcej plików Jar i zarządzać nimi ręcznie, a uznałem, że jest to bardziej przydatne do budowania, pakowania i testowania większych projektów.
• Wadą jest to, że ma stromą krzywą uczenia się, a jeśli wtyczki Maven lubią tłumić błędy :-) Inną rzeczą jest to, że całkiem sporo narzędzi działa również z repozytoriami Maven (jak Sbt for Scala, Ivy for Ant, Graddle for Groovy) .

Korzystanie z IDE

Teraz to, co może zwiększyć produktywność rozwoju. Jest kilka alternatyw open source (jak Eclipse i NetBeans , wolę tę pierwszą), a nawet komercyjne (jak IntelliJ ), które są dość popularne i potężne.

Mogą zarządzać budowaniem projektu w tle, więc nie musisz zajmować się wszystkimi sprawami wiersza poleceń. Jednak zawsze przydaje się, jeśli wiesz, co faktycznie dzieje się w tle, dzięki czemu możesz znaleźć sporadyczne błędy, takie jak plik ClassNotFoundException.

Jedna dodatkowa uwaga

W przypadku większych projektów zawsze zaleca się korzystanie ze środowiska IDE i narzędzia do kompilacji. Pierwsza z nich zwiększa produktywność, podczas gdy druga umożliwia korzystanie z różnych IDE w projekcie (np. Maven może generować deskryptory projektów Eclipse za pomocą prostego mvn eclipse:eclipsepolecenia). Co więcej, posiadanie projektu, który można przetestować / zbudować za pomocą polecenia w jednym wierszu, jest łatwe do wprowadzenia dla nowych kolegów i na przykład do serwera ciągłej integracji. Bułka z masłem :-)

find . -name "*.java" -print | xargs javac 

Trochę brutalne, ale działa jak diabli. (Używaj tylko w małych programach, to absolutnie nie jest wydajne)

Jeśli twoja powłoka to obsługuje, czy coś takiego zadziała?

javac com/**/*.java 

Jeśli twoja powłoka nie obsługuje **, to może

javac com/*/*/*.java

działa (dla wszystkich pakietów z 3 komponentami - dostosuj dla mniej więcej).

W zwykłym przypadku, gdy chcesz skompilować cały projekt, możesz po prostu dostarczyć javac z główną klasą i pozwolić mu skompilować wszystkie wymagane zależności:

javac -sourcepath . path/to/Main.java

javac -cp "jar_path/*" $(find . -name '*.java')

(Wolę nie używać xargs, ponieważ może je podzielić i uruchomić javac wiele razy, każdy z podzbiorem plików java, z których niektóre mogą importować inne, które nie zostały określone w tym samym wierszu poleceń javac)

Jeśli masz punkt wejścia App.java, najlepszy jest sposób na dziwaka z -sourcepath. Kompiluje każdy inny potrzebny plik java, zgodnie z zależnościami importu. na przykład:

javac -cp "jar_path/*" -sourcepath src/ src/com/companyname/modulename/App.java

Można również określić docelową klasy plików Reż -d target/.

Radziłbym ci nauczyć się posługiwać mrówką , która bardzo dobrze nadaje się do tego zadania, jest bardzo łatwa do uchwycenia i dobrze udokumentowana.

Wystarczyłoby zdefiniować taki cel w pliku build.xml:

<target name="compile">
    <javac srcdir="your/source/directory"
           destdir="your/output/directory"
           classpath="xyz.jar" />
</target>

Po prostu używam make z prostym plikiem makefile, który wygląda następująco:

JAVAC = javac -Xlint:unchecked
sources = $(shell find . -type f -name '*.java')
classes = $(sources:.java=.class)

all : $(classes)

clean :
        rm -f $(classes)

%.class : %.java
        $(JAVAC) $<

Kompiluje źródła pojedynczo i rekompiluje tylko wtedy, gdy jest to konieczne.

Polecenie javac nie podlega rekursywnemu procesowi kompilacji, więc musisz albo określić każdy katalog podczas uruchamiania polecenia, albo podać plik tekstowy z katalogami, które chcesz uwzględnić:

javac -classpath "${CLASSPATH}" @java_sources.txt

Używałem tego w projekcie Xcode JNI do rekurencyjnego tworzenia moich klas testowych:

find ${PROJECT_DIR} -name "*.java" -print | xargs javac -g -classpath ${BUILT_PRODUCTS_DIR} -d ${BUILT_PRODUCTS_DIR}