2016-04-04 7 views
7

Der Versuch, ein alexa (amazon: echo) Skills-Set zu erstellen. Zur gleichen Zeit, versuchen, diese Erfahrung als Lern ​​Testbed 2. für Dependency Injection durch Dolch jedoch zu verwenden, bauen das Paket mit Maven-2 cmd:java.lang.IllegalStateException: endPosTable ist bereits festgelegt

mvn assembly:assembly -DdescriptorId=jar-with-dependencies package'. 

ein Zip-Glas mit den vollständigen Abhängigkeiten zu erzeugen, erzeugt die folgende Ausnahmespur:

[INFO] ------------------------------------------------------------------------ 
[INFO] Building Echo Device Client 1.0 
[INFO] ------------------------------------------------------------------------ 
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ echo-device-client --- 
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent! 
[INFO] skip non existing resourceDirectory /Users/apil.tamang/Dropbox/Git/echo-device-client/src/main/resources 
[INFO] 
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ echo-device-client --- 
[INFO] Changes detected - recompiling the module! 
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent! 
[INFO] Compiling 46 source files to /Users/apil.tamang/Dropbox/Git/echo-device-client/target/classes 
An exception has occurred in the compiler (1.8.0_60). Please file a bug at the Java Bug Database (http://bugreport.java.com/bugreport/) after checking the database for duplicates. Include your program and the following diagnostic in your report. Thank you. 
java.lang.IllegalStateException: endPosTable already set 
     at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136) 
     at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350) 
     at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) 
     at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) 
     at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892) 
     at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921) 
     at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187) 
     at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) 
     at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) 
     at com.sun.tools.javac.main.Main.compile(Main.java:523) 
     at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) 
     at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) 

Die erste Kompilierung funktioniert einwandfrei, und alle Tests werden ausgeführt und erfolgreich ausgeführt. Ich habe das Gefühl, dass es während der "Verknüpfung" der Abhängigkeiten ist, dass die Dinge nach Süden gehen. Bitte sehen Sie sich this file an, um die Konsolenausgabe während des Builds zu sehen.

Meine Frage ist, ob es einen Versuch wert ist, die Abhängigkeiten auf eine andere Weise zu generieren. Ich weiß nicht viel über Maven für diesen Zweck. Gibt es einen Patch oder etwas, das verwendet werden kann? Denkst du, dass es sogar möglich ist, einen Workaround zu finden? Ich würde gerne das dolch 2-Framework weiterhin für den Aufbau dieses Projekts verwenden können.

Antwort

7

Das Problem in dem Fehlerbericht JDK-8067747 beschrieben:

(von Jan Lahoda)

Meines Wissens gibt es zwei Aspekte zu diesem Fehler:

  1. der Javac-Bug, der mit einer Ausnahme abstürzt. Ich arbeite daran, aber bitte beachten Sie, dass Javac die Eingabe nicht kompiliert, wenn dies behoben ist, wird es eine entsprechende Ausnahme vom Filer werfen (siehe unten).

  2. was wie ein Maven-Fehler aussieht: Wenn das Projekt mit "clean install" kompiliert wird, generiert ein Annotationsprozessor eine Quelldatei in "target/generated-sources/annotations". Wenn die inkrementelle Kompilierung abgeschlossen ist, wird diese erzeugte Datei als Eingabe an javac übergeben, und der Annotationsprozessor wird versuchen, sie erneut zu generieren, was nicht erlaubt ist.

Dies bedeutet, dass, wenn der Maven-Fehler behoben ist, javac ‚s Fehler, das Problem mit einer unangemessenen Ausnahme Berichterstattung irrelevant wird. Angesichts des tatsächlichen Ablaufs von Maven 2 am Ende meines Lebens bezweifle ich jedoch, dass Sie eine Reparatur oder einen Patch dafür erwarten können.

+1

Aus der Dokumentation auf Maven: „Die Verwendung der Montage: Montage, Montage: Angebaut, Montage: Verzeichnis, Montage: Verzeichnis-Inline sind veraltet, da sie mit normalen Build-Prozessen Schaden anrichten und nicht standardmäßige Build-Praktiken fördern. " Ich habe das Gefühl, dass ein anderer Dienstprogrammbefehl das Problem lösen könnte, das ich habe. Werde eine Entschließung veröffentlichen, wenn ich jemals darüber hinaus komme. In der Zwischenzeit, was sind deine Gedanken? –

+3

tl; dr - 'mvn sauber' – RobEarl

0

Ich bin mir nicht sicher, ob dies helfen kann. Für meinen Fall hatte ich das gleiche Problem mit open-jdk8u91, ich installierte Oracle-JDK und ich konnte das Projekt nach mvn clean compile ausführen. Das Problem war, dass ich für jeden Lauf zwischen JDKs wechseln und es erneut mit Maven erstellen musste.

EDIT: nach etwa zwei Tagen mit ihm kämpfen, fand ich es ein Ergebnis der Diskrepanz zwischenmaven und jdk ist. Meine IDE verwendet Maven 3.0.5 als gebündelte Maven.

Lösung: In Ihrem IDE sollten Sie Ihr Maven Home-Verzeichnis von bundled maven zu Ihrer aktuellen Version zum Beispiel ändern /usr/share/maven.(für mich aktuelle Version war 3.3.9)

0

Ich habe den gleichen Fehler mit einem Projekt, das von Maven und JDK 1.8.0_121 gebaut und getestet wurde, festgestellt. In der ursprünglichen Konfiguration wurde das Projekt zuerst über mvn clean gereinigt, dann unter Verwendung von mvn install -projectSpecificParameters aufgebaut und schließlich mit einem separaten mvn install -otherProjectSpecificParameters getestet. Diese Konfiguration führte zu dem in der Frage erwähnten Fehler.

Nach dem Ändern der Reihenfolge der Stufen (zuerst testen und dann aufbauen) und Hinzufügen eines clean Ziels zum Build-Befehl, um den eingebauten Zustand nach den Tests zu bereinigen, war der Fehler nicht mehr reproduzierbar.

0

Wie in this issue erläutert, ist eine Abhilfe useIncrementalCompilation zu deaktivieren:

<plugin> 
    <artifactId>maven-compiler-plugin</artifactId> 

    <configuration> 
     <useIncrementalCompilation>false</useIncrementalCompilation> 
    </configuration> 
</plugin>