Ich habe etwa 1500 Dateien zu kompilieren, in denen 15-20 Dateien Kompilierungsfehler haben. Diese Dateien stehen nicht unter meiner Kontrolle, daher konnte ich keine Änderungen / Aktualisierungen / Löschungen vornehmen. Also, ich habe zwei Fragen hier.
1) Wie ignoriere ich die Kompilierungsfehler dieser 15-20 Dateien und führe die .class Datei für den Rest von ihnen weiter aus. Gibt es eine javac-Befehlszeilenoption oder irgendetwas, das die Kompliationsfehler ignoriert und die .class-Dateien für alle anderen Nicht-Fehlerdateien erzeugt.
2) bricht der Java-Compiler die Kompilierung ab, sobald er diese Fehler sieht oder wird er mit dem Kompilieren fortfahren (das Erzeugen von .class-Dateien) alles andere und dann am Ende über diese Dateien mit Fehlern klagen.
Sie können Eclipse verwenden. Der interne Compiler ist - zumindest in einigen Fällen - in der Lage, mit dem Rest des Builds weiterzumachen, selbst wenn einige Klassen nicht vollständig kompiliert werden. Es wird, wenn möglich, sogar Klassen-Dateien für die defekten Klassen erzeugen, die Methoden erzeugen, die eine Ausnahme auslösen, sobald sie aufgerufen werden.
Ich würde stark empfehlen, dass Sie einfach eine Kopie aller Quellen machen und die Fehler zumindest in Ihrer eigenen Kopie so früh wie möglich beheben, aber Eclipses partielle Kompilierung kann Ihnen helfen.
Sie können Kompilierungsfehler nicht ignorieren. Sie werden immer den Build fehlschlagen.
Sie können nur mit jemandem sprechen, der die Dateien kontrolliert, um sie zu reparieren, oder einen Weg finden, sie anderweitig zu ersetzen.
Wenn Sie versuchen, sie aus dem Build zu entfernen, müssen Sie auch alle Dateien entfernen, die diese Dateien verwenden. Zum Beispiel
%Vor%Wenn B einen Kompilierfehler hat, kann Ihr Buildskript B.java überspringen, aber wenn Sie A.java schlagen, wird es versuchen, B trotzdem zu kompilieren, also muss A entfernt werden. Dies kann sich als eine nicht-triviale Aufgabe erweisen.
Sie könnten sich ein Skript schreiben, das Ihren Quellbaum durchläuft und javac für jede Java-Datei einzeln aufruft. Auf diese Weise erhalten Sie alle korrekt kompilierten Dateien, die nicht von den Dateien mit Fehlern abhängig sind. Dies wäre jedoch eine schrecklich langsame Operation. Ich würde erwarten, dass es mehrere hundert Mal länger dauert als ein einzelner Aufruf von javac (wenn man bedenkt, dass Sie etwa 1500 Anrufe haben würden).
Sie können bestimmte Quelldateien vom Kompilieren mit einem auszuschließenden Tag in der ant-Task ausschließen.
%Vor%BEARBEITEN: Aber natürlich können alle Java-Dateien, die von den ausgeschlossenen Klassen abhängig sind, auch nicht kompiliert werden, es sei denn, Sie haben bereits eine vorkompilierte Version der ausgeschlossenen Dateien im Klassenpfad.
Erstellen Sie Modelle der fehlerhaften Dateien. Im Grunde die gleiche Idee wie eine C-Header-Datei, enthalten die Funktion Signaturen und vernünftige Standard-Rückgabewerte ( null , false , 0 ). Dadurch kann javac alles kompilieren, stellen Sie nur sicher, dass die Scheinklassen nicht in die endgültige Verteilung aufgenommen werden, oder Sie haben seltsame Fehler, wenn sie zuerst im Klassenpfad landen. Dies funktioniert, um kaputte Interfaces zu implementieren und von defekten Klassen zu erben.
Was meinst du
?, das die Kompliationsfehler ignoriert und die .class-Dateien für alle anderen Nicht-Fehlerdateien erzeugt
Ist Ihnen klar, dass, wenn diese Dateien verwandt sind (wie in einem einzelnen Projekt), die abhängigen Quelldateien auch nicht kompiliert werden ..? Es gibt keine Möglichkeit, das zu umgehen, außer die Kompilierungsfehler zu korrigieren und es erneut zu versuchen!
Sie sollten nicht mit nicht kompilierendem Code arbeiten müssen, sondern mit demjenigen, der sie begangen hat. Wenn mehr Personen an diesem Projekt arbeiten, muss sich jeder auf seinem lokalen Rechner mit dem gleichen Problem befassen (herausfinden, warum es nicht kompiliert hat, die fehlerhaften Klassen ausfindig machen, diese Klassen ausschließen / kommentieren) wenn Ihr Code nicht von ihnen abhängt, Neuerstellung usw.) Es ist viel effizienter, nur eine Person zu haben, um das Problem zu beheben, und alle anderen aktualisieren nur sein lokales Repository.