Warum verwendet niemand make für Java?

162

Nahezu jedes Java-Projekt, das ich gesehen habe, verwendet entweder Maven oder Ant. Sie sind gute Werkzeuge und ich denke, fast jedes Projekt kann sie verwenden. Aber was auch immer passiert zu machen ? Es wird für eine Vielzahl von Nicht-Java-Projekten verwendet und kann problemlos mit Java umgehen. Natürlich müssen Sie make.exe herunterladen, wenn Sie Windows verwenden, aber Ant und Maven werden auch nicht mit dem JDK geliefert.

Gibt es einen grundlegenden Fehler bei make, wenn es mit Java verwendet wird? Liegt es nur daran, dass Ant und Maven in Java geschrieben sind?

Benutzer1
quelle
37
Wenn Sie Dinge verschieben und mehr tun, als nur den Compiler aufzurufen (und selbst dann), ist es sehr umständlich, mit den plattformspezifischen Dingen umzugehen make. Und ein Makefile zu haben, das nur auf einem System funktioniert, ist für eine plattformübergreifende Sprache nicht sehr schön.
Joey
Abgesehen davon ist Gradle ein neuer Spieler im Java-Bereich, ebenso wie Gant (in geringerem Maße). Maven oder Ant ist eine falsche Zweiteilung.
Michael Easter
@ Michael Easter, die falsche Zweiteilung wäre Maven / Ant vs. Make. Die wahre Zweiteilung, wenn ich Sie richtig lese, wäre Gradle / Maven / Gant / Ant vs. Make. Aber es ist schwer zu sagen :)
Dan Rosenstark

Antworten:

192

Das grundlegende Problem bei Make und Java besteht darin, dass Make unter der Voraussetzung funktioniert, dass Sie eine Abhängigkeit und anschließend eine Regel zum Auflösen dieser Abhängigkeit angegeben haben.

Führen Sie mit Basic C normalerweise "cc main.c" aus, um "eine main.c-Datei in eine main.o-Datei zu konvertieren".

Sie können das in Java tun, aber Sie lernen schnell etwas.

Meistens startet der Javac-Compiler nur langsam.

Der Unterschied zwischen:

javac Main.java
javac This.java
javac That.java
javac Other.java

und

javac Main.java This.java That.java Other.java

ist Tag und Nacht.

Verschärfen Sie das mit Hunderten von Klassen, und es wird einfach unhaltbar.

Dann kombinieren Sie dies mit der Tatsache, dass Java in der Regel als Dateigruppen in Verzeichnissen organisiert ist, im Vergleich zu C und anderen, die zu einer flacheren Struktur tendieren. Make hat nicht viel direkte Unterstützung für die Arbeit mit Hierarchien von Dateien.

Make ist auch nicht sehr gut darin festzustellen, welche Dateien auf Sammlungsebene veraltet sind.

Mit Ant werden alle veralteten Dateien durchlaufen und zusammengefasst und anschließend auf einmal kompiliert. Make ruft einfach den Java-Compiler für jede einzelne Datei auf. Damit make NOT dies nicht tut, sind genügend externe Tools erforderlich, um wirklich zu zeigen, dass Make der Aufgabe nicht ganz gewachsen ist.

Deshalb sind Alternativen wie Ant und Maven aufgetaucht.

Will Hartung
quelle
6
Um make in einem riesigen Java-Projekt verwenden zu können, müsste eine Liste aller geänderten .java-Dateien geführt und am Ende javac aufgerufen werden. Das klingt für mich weniger als ideal. Das ist die beste Antwort, die ich bisher gesehen habe.
User1
32
Ich liebe es. Sie sagen, dass Ant benötigt wurde, um die Tatsache anzugehen, dass Javac zu langsam ist.
cmcginty
25
Nein. Javac ist nicht langsam, wenn Sie es so verwenden, wie es verwendet werden soll. Es ist nur langsam, wenn Sie damit jeweils eine Datei kompilieren.
Stephen C
7
@Casey Javac ist nicht zu langsam. Die JVM ist zu langsam, um zu starten.
Thorbjørn Ravn Andersen
7
GNU Make hat mindestens die $?automatische Variable, die auf "alle Voraussetzungen, die neuer als das Ziel sind" erweitert wird. Es gibt auch die Funktion von Musterregeln mit mehreren Zielen, bei denen das Rezept nur einmal ausgeführt wird, um alle .classDateien zu aktualisieren . Kombiniert man dies mit einigem geschickten Einsatz von Datei / Text - Funktionen wie $(wildcard), $(shell), $(eval)und Sie können Ihre Make - Datei lehren zu Build - Zielen verstreut in Ihrer Verzeichnisstruktur zu entdecken.
Tanz87
33

Das ehrwürdige makeProgramm verarbeitet separat kompilierte Sprachen wie C und C ++ ziemlich gut. Sie kompilieren ein Modul, das es verwendet#include , um den Text anderer Include-Dateien abzurufen, und schreiben eine einzelne Objektdatei als Ausgabe. Der Compiler ist in hohem Maße ein einzelnes System mit einem separaten Verknüpfungsschritt, um die Objektdateien in eine ausführbare Binärdatei zu binden.

In Java muss der Compiler jedoch tatsächlich andere Klassen kompilieren , mit denen Sie importieren import. Obwohl es möglich wäre, etwas zu schreiben, das alle erforderlichen Abhängigkeiten aus dem Java-Quellcode generiert, sodass makedie Klassen einzeln in der richtigen Reihenfolge erstellt werden, werden Fälle wie zirkuläre Abhängigkeiten immer noch nicht behandelt.

Der Java-Compiler kann auch effizienter sein, indem die kompilierten Ergebnisse anderer Klassen zwischengespeichert werden, während weitere Klassen kompiliert werden, die von den Ergebnissen bereits kompilierter Klassen abhängen. Diese Art der automatischen Abhängigkeitsbewertung ist makeallein nicht wirklich möglich .

Greg Hewgill
quelle
7
Dies scheint eher eine Antwort von make versus javac zu sein als eine Antwort von make versus ant / maven. Warum konnte jemand aufgrund Ihrer Antwort nicht einfach make + javac verwenden (indem Sie javac jeweils ein ganzes Paket oder "Modul" geben, sodass zirkuläre Abhängigkeiten vor make verborgen sind)? Würden Ameisen oder Maven einen Vorteil gegenüber diesem Ansatz bieten?
Laurence Gonsalves
1
@Laurence: Sie könnten javac ein ganzes Paket auf einmal geben, aber dann wird alles in diesem Paket neu kompiliert (da Sie es so angewiesen haben). Es ist wahr, dass der Java-Compiler ziemlich schnell ist, aber es ist noch schneller, wenn Sie bestimmen lassen, welche Klassen das Minimum sind, das nach einer Änderung neu kompiliert werden muss.
Greg Hewgill
Beziehen Sie sich darauf, javac anzuweisen, nur Ihre "Haupt" -Klasse zu kompilieren und sie dann automatisch das Material erstellen zu lassen, von dem es abhängt? Zuletzt habe ich überprüft (zugegebenermaßen wahrscheinlich in 1.4), dass es schrecklich unzuverlässig war. -Xdepend war etwas besser (aber langsamer und immer noch kaputt) und sie haben diese Flagge in 1.3 entfernt.
Laurence Gonsalves
4
Dies erklärt auch immer noch nicht, warum ich Ant oder Maven anstelle von Straight Javac verwenden würde ...
Laurence Gonsalves
28

Die Frage beruht auf einer falschen Annahme: eine nicht-triviale Zahl der Entwickler tun Einsatz make. Siehe Java Build Tools: Ant vs. Maven . Warum ein Entwickler nicht verwenden würde make: Viele Entwickler haben es entweder nie verwendet makeoder es verwendet und hassten es mit einem Feuer, das heißer als tausend Sonnen brennt. Als solche verwenden sie alternative Werkzeuge.

Hank Gay
quelle
10
Wir benutzen es und das Feuer ist heißer als tausendundein Sonnen.
reccles
4
@reccles: Ist es nur Hass gegen Build Engineering oder sich selbst zu machen? Wie wäre Ant, Maven oder etwas anderes besser (dh wäre ein schlechtes Werkzeug für seine Klasse)?
User1
5
@ User1 makehat viele "Funktionen", die beim Schreiben möglicherweise Sinn gemacht haben, aber jetzt eher wie Fehler sind, z. B. müssen Sie an bestimmten Stellen ein TAB-Zeichen und keine Leerzeichen verwenden. So etwas stört wahrscheinlich nicht Leute, die wirklich Erfahrung haben make, aber es macht den Rest von uns verrückt.
Hank Gay
4
@HankGuy: Lassen Sie Ihren Editor sich um dieses Detail kümmern. Wenn Ihr Editor die <-> Speicherplatzeinstellungen auf der Registerkarte nicht korrekt verarbeiten kann, holen Sie sich einen neuen Editor und Sie werden viel glücklicher sein. Aber Sie haben Recht, wenn Sie sagen, dass viele Funktionen veraltet sind, wie die Art und Weise, wie dynamische Abhängigkeiten behandelt werden ( make dependirgendjemand?)
D.Shawley
3
@ User1 Es ist der Umfang des Projekts, das wir erstellen. Wir haben einen Vollzeitmitarbeiter, der die make-Dateien verwaltet und Abhängigkeiten erstellt. Nachdem ich Maven benutzt hatte, fand ich es überschaubarer. Nun, nachdem ich gesagt habe, dass Maven auch nicht perfekt war. Nichts ist ärgerlicher, als herauszufinden, welche XML-Einstellungen für einen Build erforderlich sind, der sich geringfügig vom vorgeschriebenen Setup unterscheidet.
reccles
28

Tatsächlich kann make die Neukompilierung aller veralteten Java-Dateien in einem Befehl durchführen. Ändern Sie die erste Zeile, wenn Sie nicht alle Dateien im Verzeichnis kompilieren möchten oder eine bestimmte Reihenfolge wünschen ...

JAVA_FILES:=$(wildcard *.java)
#
# the rest is independent of the directory
#
JAVA_CLASSES:=$(patsubst %.java,%.class,$(JAVA_FILES))

.PHONY: classes
LIST:=

classes: $(JAVA_CLASSES)
        if [ ! -z "$(LIST)" ] ; then \
                javac $(LIST) ; \
        fi

$(JAVA_CLASSES) : %.class : %.java
        $(eval LIST+=$$<)
user1251840
quelle
4
Nett! Ich habe so etwas gesucht. Sie müssen nicht für jede Sprache ein anderes Build-Tool verwenden, wenn der universelle Klassiker einwandfrei funktioniert. Vielen Dank!
rsp
17

Alle anderen Antworten über die technischen Vorzüge der einzelnen sind wahr. Antund sind Mavenmöglicherweise besser für Java geeignet als make, oder wie Hank Gay betont, möglicherweise nicht :)

Sie haben jedoch gefragt, ob es wichtig ist, dass Ant und Maven in Java geschrieben sind. Obwohl wir bei StackOverflow solche Gedanken nicht berücksichtigen (geschlossen! Nicht programmierbezogen! Usw.), ist das natürlich ein Teil der Sache. Auf Schienen verwenden wir Rake, C-Typen make und in Java Ant und Maven. Es stimmt zwar, dass die Ant- oder Maven-Entwickler den Java-Entwickler vielleicht besser betreuen als andere, aber es gibt noch eine andere Frage: In was schreiben Sie Ant-Aufgaben? Java. Wenn Sie ein Java-Entwickler sind, ist das eine einfache Lösung.

Ein Teil davon besteht darin, Werkzeuge zu verwenden, die in der Sprache geschrieben sind, in der Sie arbeiten.

Dan Rosenstark
quelle
7
Ant entstand auch zu einer Zeit, als die Java-Community von XML fasziniert war. (Was nicht heißt, dass XML keinen Platz hat.)
Laurence Gonsalves
3
@Laurence Gonsalves, das ist so wahr. Aber bitte, wir reden hier auf SO nicht über Modeerscheinungen :) Ich habe damals Java-Entwickler unterrichtet und ALLES war XML. Jetzt ist es immer noch XML, aber niemand kümmert sich darum.
Dan Rosenstark
1
Der Werkzeugkommentar ist interessant. makestammt aus einem UNIX-Hintergrund, daher werden die Werkzeuge erstellt, indem nützliche kompakte Dienstprogramme geschrieben und zusammengefügt werden. Aus diesem Grund werden die meisten Stiche mit Shell-Befehlen erstellt.
D. Shawley
2
@D. Shawley, alles wahr in Bezug auf makeund kleine Unix-Utils. GIT ist auch ein Kind dieses Prozesses. Persönlich würde ich nicht sagen, dass es nicht besser ist. Aber es ist ein großer Paradigmenwechsel für Java-Programmierer. Ant ist viel konsonanter mit Java-Denkweisen.
Dan Rosenstark
12

Ant und später Maven wurden entwickelt, um einige Kopfschmerzen zu lösen, die durch Make(während des Erstellens neuer Kopfschmerzen) verursacht werden. Es ist nur Evolution.

... Bald darauf erkannten mehrere Open-Source-Java-Projekte, dass Ant die Probleme lösen konnte, die sie mit Makefiles hatten ...

Von http://ant.apache.org/faq.html#history

Ob sie etwas lösen oder nur ein zusätzliches Lernformat erstellen, ist ein subjektives Thema. Die Wahrheit ist, dass dies so ziemlich die Geschichte jeder neuen Erfindung ist: Der Schöpfer sagt, dass sie viele Probleme löst, und die ursprünglichen Benutzer sagen, dass dies Tugenden sind.

Der Hauptvorteil ist die Möglichkeit, sich in Java zu integrieren.

Ich denke, eine ähnliche Geschichte wäre rakezum Beispiel mit.

OscarRyz
quelle
4
Das ist nicht sehr spezifisch. Welche durch make verursachten Kopfschmerzen löst Maven?
Laurence Gonsalves
1
@Gonsalves: Nun, das ist einer der subjektiven Aspekte jeder neuen Technologie. Der Schöpfer der Alternative sagt, dass sie viele Probleme löst, und die Schöpfer der ersetzten Technologie sagen, dass dies keine Mängel, sondern Tugenden und so weiter sind. Ich denke, in dieser besonderen Situation war die Java-Integration und Cross-Compilation
sofort einsatzbereit
2
[Bezieht sich auf Ihre Antwortbearbeitung, nicht auf Ihren letzten Kommentar] Das erklärt immer noch nicht, welche Probleme gelöst wurden, nur dass die Schöpferameise behauptet, dass Probleme gelöst wurden ...: - / Mein Eindruck war, dass Ant ursprünglich erstellt wurde eine einfachere Alternative zu Make sein. Im Laufe der Zeit stellten die Leute fest, dass es Dinge gab, die fehlten, und fügten Funktionen hinzu, bis Ant genauso komplex wurde wie make, aber mit eingebauten Binutils (make stützt sich stark auf externe Tools wie cp, rm usw.) und Natürlich gibt es die XML-Syntax.
Laurence Gonsalves
2
Ja, aber wenn der Schöpfer einer neuen Alternative am besten sagen kann: "Dies löst Probleme, die die alte hatte", ohne tatsächlich zu sagen, was diese Probleme sind, ist dies für diejenigen, die überlegen, welche Option sie verwenden sollen, nicht so nützlich. Löst Ant Probleme, die ich mit make habe, oder löst es Dinge, die ich nicht als Probleme betrachte, während es neue Probleme für mich einführt?
Laurence Gonsalves
9

Eines der Hauptprobleme, das von Maven (und Ivy-fähigen Ant-Setups) über make gelöst wurde, ist die automatisierte Auflösung von Abhängigkeiten und das Herunterladen Ihrer Abhängigkeitsgläser.

Ophidian
quelle
6

Ich denke, die wahrscheinlichste Erklärung ist, dass mehrere Faktoren die Verwendung von make in der Java-Community in einem kritischen Zeitraum (Ende der neunziger Jahre) behindert haben:

  1. Da Java mehrere Plattformen umfasst, waren Java-Programmierer im Allgemeinen mit Unix-Tools nicht so vertraut wie Programmierer, die im Allgemeinen auf eine Unix-Umgebung beschränkt waren (z. B. C- und Perl-Programmierer). Beachten Sie, dass dies ALLGEMEIN ist. Ohne Zweifel gibt und gab es begabte Java-Programmierer mit einem tiefen Verständnis von Unix.
  2. Folglich waren sie weniger geschickt in make und wussten nicht, wie man make effektiv einsetzt.
  3. Während es möglich ist, ein kurzes und einfaches Makefile zu schreiben, das Java effizient kompiliert, ist besondere Sorgfalt erforderlich, um dies plattformunabhängig zu tun.
  4. Infolgedessen bestand Appetit auf ein an sich plattformunabhängiges Build-Tool.
  5. In dieser Umgebung wurden Ant und später Maven geschaffen.

Kurz gesagt, während make mit Sicherheit für Java-Projekte verwendet werden kann, gab es einen Moment der Gelegenheit, es zum De-facto-Java-Build-Tool zu machen. Dieser Moment ist vergangen.

David A. Ventimiglia
quelle
5

Make-Skripte sind in der Regel plattformabhängig. Java soll plattformunabhängig sein. Daher ist ein Build-System, das nur auf einer Plattform für eine Quellplattform mit mehreren Plattformen funktioniert, ein Problem.

Brian Fox
quelle
5

Kurze Antwort: Weil makees nicht gut ist. Sogar an der C-Front tauchen viele Alternativen auf.

Lange Antwort: Es makegibt mehrere Fehler, die es kaum zum Kompilieren von C und überhaupt nicht zum Kompilieren von Java geeignet machen. Sie können es erzwingen, Java zu kompilieren, wenn Sie möchten, aber erwarten, dass Probleme auftreten, von denen einige keine geeignete Lösung oder Problemumgehung haben. Hier sind ein paar:

Abhängigkeitsauflösung

makeerwartet von Natur aus, dass Dateien eine baumartige Abhängigkeit voneinander haben, wobei eine Datei die Ausgabe der Erstellung mehrerer anderer Dateien ist. Dies schlägt in C bereits fehl, wenn es sich um Header-Dateien handelt. makeerfordert, dass eine makespezifische Include-Datei generiert wird, um die Abhängigkeit einer C-Datei von ihren Header-Dateien darzustellen, sodass eine Änderung an letzterer dazu führen würde, dass die vorherige Datei neu erstellt wird. Da die C-Datei selbst jedoch nicht neu erstellt (lediglich neu erstellt) wird, muss für make häufig das Ziel als angegeben werden .PHONY. Glücklicherweise unterstützt GCC das automatische Generieren dieser Dateien.

In Java kann die Abhängigkeit zirkulär sein, und es gibt kein Tool zum automatischen Generieren von Klassenabhängigkeiten im makeFormat. antDie DependAufgabe kann stattdessen die Klassendatei direkt lesen, bestimmen, welche Klassen importiert werden, und die Klassendatei löschen, wenn eine davon veraltet ist. Ohne dies kann eine nicht triviale Abhängigkeit dazu führen, dass Sie gezwungen sind, wiederholte saubere Builds zu verwenden, wodurch der Vorteil der Verwendung eines Build-Tools entfällt.

Leerzeichen in Dateinamen

Während weder Java noch C die Verwendung von Leerzeichen in Ihren Quellcodedateinamen fördern, makekann dies auch dann problematisch sein, wenn sich die Leerzeichen im Dateipfad befinden. Überlegen Sie beispielsweise, ob Ihr Quellcode in vorhanden ist C:\My Documents\My Code\program\src. Dies würde ausreichen, um zu brechen make. Dies liegt daran, dass makeDateinamen als Zeichenfolgen behandelt werden. antbehandelt Pfade als spezielle Objekte.

Scannen von Dateien zum Erstellen

makeerfordert die explizite Einstellung, welche Dateien für jedes Ziel erstellt werden sollen. antErmöglicht die Angabe eines Ordners, der automatisch nach Quelldateien durchsucht werden soll. Es mag wie eine kleine Annehmlichkeit erscheinen, aber bedenken Sie, dass in Java jede neue Klasse eine neue Datei benötigt. Das Hinzufügen von Dateien zum Projekt kann schnell zu einem großen Problem werden.

Und das größte Problem mit make:

make ist POSIX-abhängig

Javas Motto lautet "Kompilieren, einmal überall ausgeführt". Es ist jedoch nicht beabsichtigt, diese Kompilierung auf POSIX-basierte Systeme zu beschränken, bei denen die Java-Unterstützung tatsächlich am schlechtesten ist.

Build-Regeln makesind im Wesentlichen kleine bashSkripte. Obwohl es einen Port von makeWindows gibt, muss dieser mit einem Port von Windows gebündelt werden bash, der eine POSIX-Emulationsschicht für das Dateisystem enthält , damit er ordnungsgemäß funktioniert.

Dies gibt es in zwei Varianten:

  1. MSYS Dies versucht, die POSIX-Übersetzung auf Dateipfade zu beschränken, und kann daher unangenehme Fallstricke verursachen, wenn externe Tools ausgeführt werden, die nicht speziell dafür entwickelt wurden.

  2. cygwinDies bietet eine vollständige POSIX-Emulation. Die resultierenden Programme neigen jedoch dazu, sich immer noch auf diese Emulationsschicht zu verlassen.

Aus diesem Grund ist das Standard-Build-Tool unter Windows makeüberhaupt nicht vorhanden, sondern MSBuildim Prinzip eher ein XML-basiertes Tool ant.

Im Gegensatz dazu antist es in Java erstellt, kann überall ausgeführt werden und enthält interne Tools, sogenannte "Tasks", mit denen Dateien bearbeitet und Befehle plattformunabhängig ausgeführt werden können. Es ist so vielseitig, dass es für Sie tatsächlich einfacher ist, ein C-Programm unter Windows zu erstellen antals mit make.

Und noch eine letzte Kleinigkeit:

Selbst C-Programme verwenden make nicht nativ

Möglicherweise bemerken Sie dies zunächst nicht, aber C-Programme werden im Allgemeinen nicht mit a ausgeliefert Makefile. Sie werden mit einem CMakeLists.txtoder einem bashKonfigurationsskript geliefert, das das tatsächliche generiert Makefile. Im Gegensatz dazu wird die Quelle eines Java-Programms, das mit erstellt wurde ant, mit einem antvorgefertigten Skript ausgeliefert. A Makefileist ein Produkt anderer Tools - So viel makeist ungeeignet, um ein eigenständiges Build-Tool zu sein. antist eigenständig und behandelt alles, was Sie für Ihren Java-Erstellungsprozess benötigen, ohne zusätzliche Anforderungen oder Abhängigkeiten.

Wenn Sie antauf einer beliebigen Plattform ausgeführt werden, funktioniert dies nur (tm). Das kann man nicht bekommen make. Es ist unglaublich plattform- und konfigurationsabhängig.

SlugFiller
quelle
4

Wenn ich niemand bin, ist die Annahme, dass niemand make for java (falsch) benutzt, falsch.

"Verwalten von Projekten mit GNU Make" (verfügbar unter GFDL) enthält ein vollständiges Kapitel zur Verwendung makemit Java-Projekten.

Da es eine lange (und hoffentlich faire) Liste der Vor- und Nachteile der Verwendung von make anstelle anderer Tools enthält, sollten Sie dort einen Blick darauf werfen. (siehe: http://oreilly.com/catalog/make3/book/ )

Mikyra
quelle
Ist das eine genaue Zusammenfassung? make (in verschiedenen Geschmacksrichtungen) ist für Java verwendbar, jedoch mit einigen Schmerzen. Ant und Maven (und jmake ?) Tun einige spezielle Dinge, die Java benötigt / mag, um Java-Projekte schneller und einfacher zu erstellen. Sie können auch für einen plattformunabhängigeren Erstellungsprozess für Nicht-Java-Projekte verwendet werden, sind jedoch besser auf Java abgestimmt.
Phil Perry
3

Ant ist eine auf die XML-Konfiguration ausgerichtete Verbesserung gegenüber Makefiles und Maven ist eine Verbesserung des Abhängigkeitserstellungstools gegenüber Ant. Einige Projekte verwenden alle drei. Ich denke, die JDK-Projekte verwendeten früher eine Mischung aus Makefiles und Ant.

Berlin Brown
quelle
1

Ein wichtiger Grund ist, dass sowohl Ant als auch Maven (und die meisten auf Java ausgerichteten SCM-, CI- und IDE-Tools) von / für Java-Entwickler in Java geschrieben wurden. Dies vereinfacht die Integration in Ihre Entwicklungsumgebung und ermöglicht anderen Tools wie den IDE- und CI-Servern, Teile der Ant / Maven-Bibliotheken in die Build- / Bereitstellungsinfrastruktur zu integrieren.

Chris Nava
quelle
1

Es war einmal ein Java-Projekt, das gmake verwendete. Meine Erinnerung ist verschwommen, aber beim IIRC fiel es uns schwer, mit der Paketverzeichnisstruktur umzugehen, die javac erwartet. Ich erinnere mich auch, dass das Erstellen von JAR-Dateien ein Problem war, es sei denn, Sie hatten etwas Triviales.


quelle
1

ApacheAnt ist nichts wie Make. Bei Make geht es darum, Abhängigkeiten zwischen Dateien zu beschreiben und wie Dateien erstellt werden. Ant handelt von Abhängigkeiten zwischen "Aufgaben" und ist eher eine Möglichkeit, Build-Skripte zusammenzukleben.

es kann Ihnen helfen, AntVsMake

Venky Vungarala
quelle
Ich würde wirklich gerne die Gründe für die Abstimmungen erfahren.
Hagello
0

Ant und Maven nähern sich dem Build-Abhängigkeitsgraphen und dessen Verwaltung aus einer "moderneren" Sicht ... Aber wie Oscar sagt, haben sie ihre eigenen Probleme erstellt, während sie versucht haben, die alten Probleme mit make anzugehen.

John Weldon
quelle
0

Ich habe GNU Make nie für Java-Projekte verwendet, aber ich habe jmk verwendet . Leider wurde es seit 2002 nicht mehr aktualisiert.

Es hatte einige Java-spezifische Funktionen, war aber klein genug, um in Ihren Quell-Tarball aufgenommen zu werden, ohne seine Größe wesentlich zu erhöhen.

Heutzutage gehe ich einfach davon aus, dass jeder Java-Entwickler, mit dem ich Code teile, Ant installiert hat.

finnw
quelle