Warum nutzt niemand für Java machen?

Question

Fast jedes Java-Projekt, das ich je gesehen habe entweder nutzt Maven oder Ant. Sie sind feine Werkzeuge und ich denke gerade über jedes Projekt sie verwenden können. Aber was auch immer die machen? Es ist für eine Vielzahl von Nicht-Java-Projekte verwendet, und Java leicht umgehen kann. Sicher haben Sie make.exe herunterladen, wenn Sie Windows verwenden, aber Ant und Maven auch mit dem JDK nicht kommen.

Gibt es einen grundlegenden Fehler mit, wenn sie mit Java verwendet? Ist es nur, weil Ant und Maven sind in Java geschrieben?

Answer 1

Das grundlegende Problem mit Make und Java ist, dass auf der Prämisse, Arbeiten, dass Sie eine Abhängigkeit angeben, und dann in der Regel, dass die Abhängigkeit zu lösen.

Mit grundlegenden C, die normalerweise „eine main.c Datei in eine main.o-Datei zu konvertieren, führen Sie "cc main.c".

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

Meist dass die javac Compiler langsam zu starten.

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.

verbittert, dass mit Hunderten von Klassen, und es wird nur nicht haltbar.

Dann kombinieren Sie das mit der Tatsache, dass Java als Gruppen von Dateien in Verzeichnissen organisiert wird dazu tendiert, gegen C und andere, die in Richtung einer flacheren Struktur neigen. Machen Sie hat nicht viel direkte Unterstützung für die Arbeit mit Hierarchien von Dateien.

Machen Sie ist auch nicht sehr gut darin zu bestimmen, welche Dateien nicht mehr aktuell sind, bei einer Sammelstelle Ebene.

Mit Ant, wird es durchlaufen und alle Dateien zusammenfassen, die nicht mehr aktuell sind, und sie dann in einem Rutsch kompilieren. Machen Sie einfach den Java-Compiler auf jede einzelne Datei aufrufen. dies erfordert genug äußerte Werkzeug wirklich, dass Make zeigen machen nicht tun zu müssen, ist nicht ganz bis zur Aufgabe.

Das ist, warum Alternativen wie Ant und Maven erhob sich.

Answer 2

Der ehrwürdige make Programm Griffe separat Sprachen wie C und C ++ kompiliert recht gut. Sie kompilieren ein Modul, verwendet es #include im Text anderen Include-Dateien zu ziehen, und eine einzelne Objekt-Datei als Ausgabe schreibt. Der Compiler ist sehr viel ein one-at-a-time-System, mit einem separaten Verbindungsschritt der Objektdateien in eine ausführbare Binärdatei zu binden.

Doch in Java, hat der Compiler tatsächlich Compile andere Klassen, die Sie mit import importieren. Obwohl es möglich wäre, etwas zu schreiben, das alle notwendigen Abhängigkeiten von Java-Quellcode erzeugt, so dass make Klassen in der richtigen Reihenfolge einer nach dem anderen bauen würde, wäre dies noch nicht Fälle wie zirkuläre Abhängigkeiten behandeln.

Der Java-Compiler kann auch effizienter sein, indem sie die erarbeiteten Ergebnisse anderer Klassen Cachen, während weitere Klassen kompilieren, die bereits kompiliert auf den Ergebnissen von Einsen abhängen. Diese Art der automatischen Abhängigkeits Auswertung ist nicht wirklich möglich, mit make allein.

Answer 3

Die Frage auf einer falschen Annahme beruht: eine nicht-triviale Anzahl von Entwicklern tun Verwendung make. Siehe Java Tools bauen: Ant vs. Maven . Was, warum ein Entwickler würde nicht Verwendung make: viele Entwickler entweder make nie verwendet, oder es verwendet und hasste es, mit einem Feuer, das heißer als tausend Sonnen brennt. Als solche verwenden sie alternative Werkzeuge.

Answer 4

Eigentlich macht die erneute Kompilierung in einem Befehl aller veralteten Java-Dateien verarbeiten. Ändern Sie die erste Zeile, wenn Sie nicht alle Dateien in dem Verzeichnis erstellen möchten oder eine bestimmte Reihenfolge wollen ...

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+=$$<)

Answer 5

Alle anderen Antworten über die technischen Vorzüge der einzelnen wahr sind. Ant und Maven besser geeignet sein, um Java als zu machen, oder wie Hank Homosexuell weist darauf hin, sie dürfen nicht:)

Allerdings gefragt, ob es darauf ankommt, dass Ant und Maven in Java geschrieben werden. Obwohl auf Stackoverflow halten wir nicht solche Gedanken (geschlossen! Nicht-Programmierung bezogenen! Usw.), natürlich, DIE ZUM SACHE. Auf Schienen verwenden wir Rechen, C Kunden machen verwenden, und in Java verwenden wir Ant und Maven. Es stimmt zwar, dass die Ant oder Maven Entwickler vielleicht nach dem Java-Entwickler aussehen wird besser als andere, gibt es auch eine andere Frage: Was Sie Ant Aufgaben schreiben Sie? Java. Wenn Sie ein Java-Entwickler sind, das ist eine einfache Passform.

Also ja, ein Teil davon ist Werkzeuge in der Sprache geschrieben verwenden Sie Werkzeuge.

Answer 6

Ant und später wurde Maven entworfen einige Kopfschmerzen durch Make verursacht zu lösen (während neue in dem Prozess) Es ist nur Evolution.

  

... Bald danach mehr Open-Source-Java-Projekte realisiert, dass Ant die Probleme lösen kann sie mit Makefiles hatten ....

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

Ob sie etwas lösen oder einfach nur ein zusätzliches Format erstellen zu lernen, ist ein subjektives Thema. Die Wahrheit ist, das ist so ziemlich die Geschichte jeder neuen Erfindung: Der Schöpfer sagt, es löst eine Menge Probleme und die ursprünglichen Nutzer sagen jene Tugenden sind.

Der Hauptvorteil hat, ist die Möglichkeit, mit Java zu integrieren.

Ich denke, eine ähnliche Geschichte mit rake zum Beispiel sein würde.

Answer 7

Einer der wichtigsten von Maven gelöst Probleme (und Ivy-fähige Ant-Setups) über make automatisiert Auflösung von Abhängigkeiten und das Herunterladen von Ihrer Abhängigkeit Gläsern.

Answer 8

ich glaube, die wahrscheinlichste Erklärung ist, dass mehrere Faktoren, die die Verwendung von Make innerhalb der Java-Community in einer kritischen Zeit (Ende der 1990er Jahre) entmutigt:

1. Da Java mehrere Plattformen umfasst, Java-Programmierer in der Regel bei Unix-Tool nicht so geschickt war wie Programmierer zu einer Unix-Umgebung beschränkten im Allgemeinen waren (zum Beispiel C und Perl-Programmierer). Beachten Sie, dass diese im Allgemeinen. Ohne Zweifel gibt es und wurden begabt Java-Programmierer mit einem tiefen Verständnis von Unix.
2. Folglich waren sie weniger geschickt darin machen und wussten nicht, wie effektiv nutzen machen.
3. Während es möglich ist, eine kurze und einfache Makefile zu schreiben, die Java kompiliert effizient, ist zusätzliche Pflege erforderlich, um in einer plattformunabhängigen Art und Weise zu tun.
4. Folglich gibt es einen Appetit auf ein eigenplattformunabhängige Build-Tool.
5. Es war in dieser Umgebung, die Ant und Maven später erstellt wurden.

Kurz gesagt, während machen die meisten sicherlich verwendet für Java-Projekte werden kann, gab es einen Moment der Gelegenheit es de facto Java Build-Tool zu machen. Dieser Moment vergangen ist.

Answer 9

Erstellen Sie Skripte neigen von Natur aus plattformabhängig zu sein. Java soll plattformunabhängig sein. Daher ein Build-System, das nur für eine Multi-Plattform Sourcebase auf eine Plattform funktioniert, ist kindof ein Problem.

Answer 10

Wenn ich niemand bin die Annahme, niemand ist (mis) für Java machen mit, ist falsch.

"Verwalten von Projekten mit GNU Make" (erhältlich unter GFDL) enthält ein komplettes Kapitel widmet sich mit make mit Java-Projekten.

Da es eine lange (und hoffentlich fair) Liste der Vor-und Nachteile der Verwendung enthält anstelle von anderen Tools machen Sie dort einen Blick nehmen möchten. (Siehe: http://oreilly.com/catalog/make3/book/ )

Answer 11

Short answer: Because make isn't good. Even on the C front you see many alternatives popping up.

Long answer: make has several flaws that make it barely suitable for compiling C, and unsuitable at all for compiling Java. You can force it to compile Java, if you want, but expect running into issues, some of which do not have a suitable solution or workaround. Here are a few:

Dependency resolution

make inherently expects files to have a tree-like dependency on each other, in which one file is the output of building several others. This already backfires in C when dealing with header files. make requires a make-specific include file to be generated to represent the dependency of a C file on its header files, so a change to the latter would cause the prior to be rebuilt. However, since the C file itself isn't recreated (merely rebuilt), make often requires specifying the target as .PHONY. Fortunately, GCC supports generating those files automatically.

In Java, dependency can be circular, and there's no tool for auto-generating class dependencies in make format. ant's Depend task can, instead, read the class file directly, determine which classes it imports, and delete the class file if any of them are out of date. Without this, any non-trivial dependency may result in you being forced to use repeated clean builds, removing any advantage of using a build tool.

Spaces in filenames

While neither Java nor C encourage using spaces in your source code filenames, in make this can be problem even if the spaces are in the file path. Consider, for example, if your source code exists in C:\My Documents\My Code\program\src. This would be enough to break make. This is because make treats filenames as strings. ant treats paths as special objects.

Scanning files for build

make requires explicitly setting which files are to be built for each target. ant allows specifying a folder which is to be auto-scanned for source files. It may seem like a minor convenience, but consider that in Java each new class requires a new file. Adding files to the project can become a big hassle fast.

And the biggest problem with make:

make is POSIX-dependent

Java's motto is "compile once run everywhere". But restricting that compilation to POSIX-based systems, in which Java support is actually the worst, is not the intention.

Build rules in make are essentially small bash scripts. Even though there is a port of make to Windows, for it to work properly, it has to be bundled with a port of bash, which includes a POSIX emulation layer for the file system.

This comes in two varieties:

1. MSYS which tries to limit the POSIX translation to file paths, and can therefore have unpleasant gotchas when running external tools not made especially for it.

2. cygwin which provides a complete POSIX emulation. The resulting programs, however, tend to still rely on that emulation layer.

For that reason, on Windows, the standard build tool isn't even make at all, but rather MSBuild, which is also an XML-based tool, closer in principle to ant.

By contrast, ant is built in Java, can run everywhere, and contains internal tools, called "tasks", for manipulating files and executing commands in a platform-independent way. It's sufficiently versatile that you can actually have an easier time building a C program in Windows using ant than using make.

And one last minor one:

Even C programs don't use make natively

You may not initially notice this, but C programs generally aren't shipped with a Makefile. They are shipped with a CMakeLists.txt, or a bash configuration script, which generates the actual Makefile. By contrast, the source of a Java program built using ant is shipped with an ant script pre-built. A Makefile is a product of other tools - That's how much make is unsuitable to be a build tool on its own. ant is standalone, and deals with everything you need for your Java build process, without any additional requirements or dependencies.

When you run ant on any platform, it Just Works(tm). You can't get that with make. It's incredibly platform and configuration dependent.

Answer 12

Ant is an XML configuration oriented improvement over Makefiles and Maven is a dependency build tool improvement over Ant. Some projects use all three. I think the JDK projects used to use a mix of makefiles and ant.

Answer 13

One big reason is that both Ant and Maven (and most java targeted SCM, CI and IDE tools) are written in java by/for java developers. This makes it simpler to integrate into your development environment and allows other tools such as the IDE and CI servers to integrate portions of the ant/maven libraries within the build/deployment infrastructure.

Answer 14

Once upon a time I worked on a Java project that used gmake. My recollection is hazy but IIRC we had a hard time dealing with the package directory structure that javac expects. I also remember that building JAR files was a hassle unless you had something trivial.

Answer 15

ApacheAnt isn't anything like Make. Make is about describing dependencies between files, and how to build files. Ant is about dependencies between "tasks", and is really more of a way of gluing build scripts together.

it may helps you AntVsMake

Answer 16

Ant and Maven approach the build dependency graph and the management of it from a more 'modern' view... But as Oscar says, they created their own problems while attempting to address the old problems with make.

Answer 17

I've never used GNU Make for Java projects, but I used to use jmk. Sadly it hasn't been updated since 2002.

It had some Java-specific functionality but was small enough to include in your source tarball without significantly increasing its size.

Nowadays I just assume any Java developer I share code with has Ant installed.