IntelliJ IDEA Build-Prozess anpassen

franco98

NetBSDler aus Leidenschaft
Hallo,

ich programmiere schon einige Zeit mit IntelliJ IDEA kleinere und größere Java Aufgaben. Das geht unter Windows, Linux oder MacOS X auch unkompliziert. Einfach neues Projekt starten, Code eingeben und dann unter "Build" -> "Build Project" bzw. "Rebuild" das ganze bauen bzw. compilieren. Da ich aber fast alles unter NetBSD erledigen will, habe ich auch hier IntelliJ installiert - zuerst die Version aus den pkgsrc System (ideaIC-2019.1.2-no-jbr.tar.gz) und dann später direkt von Jetbrains diese neuere Linux Variante (ideaIC-2020.3.3-no-jbr.tar.gz).

Sie laufen beide soweit normal, aber ich kann hier keinen Build Prozess starten, nichts kompilieren.

Das Programm zeigt mir zwar dass es etwas tut, aber es passiert nichts. Die entsprechenden Ordner für die *.class Dateien ect. werden auch nicht automatisch angelegt. Der Build Prozess lässt sich auch nicht stoppen, ich muss das Programm schließen.

Nun habe ich das ganze über ein einfaches Ant build.xml Script umgangen, mit "init", "compile", "test", "build" und "clean" Aufgaben und alles läuft wie unter den anderen Installationen unter Windows und Co.

Nun meine Fragen:

Gibt es Unterschiede in den Versionen, so dass der Build Prozess dort automatisch schon funktioniert?
Kann ich im IntelliJ Programm den globalen Build Prozess verändern?

Ich habe als Plugin u.a. "Ant build Generation" installiert, damit kann ich unter "Build" -> "Generate Ant Build" ein build.xml erstellen, das mit dem Projekt verknüpft das gleiche tun soll, wie mein von Hand geschriebenes Script. Macht es aber auch nicht.

Mein Ziel ist es die unter "Build" -> "Build Project" verknüpften Befehle im Programm durch meine zu ersetzen. In den o.g. anderen Versionen geht es ja auch und die Abhängigkeiten zum Laufen des Programms habe ich auch alle.

Kann mir jemand weiterhelfen?


VG aus
 
@Azazyel

Nun die Datei "idea.log" ist etwas zu lang um sie hier zu posten. Ich habe sie mal grob durchgesehen und mir fällt das zuerst auf:

  • WARN - #com.intellij.idea.Main - Unable to load JNA library (OS: NetBSD 9.99.81)
  • Native library (com/sun/jna/netbsd-x86-64/libjnidispatch.so) not found in resource path (/usr/local/idea-IC-203.7717.56/...

Logisch, ist ja die Linux-Version von IntelliJ, für NetBSD gibt es keine. Weiterhin:

* INFO - #com.intellij.util.Restarter - not supported: cannot detect process ID

Ist mir auch schon aufgefallen, ich muss nach einem Pluggin-Update das Programm beenden und neu starten, Restart funktioniert nicht. Aber das ist nicht das Problem. Am Ende kommt der Teil wo mein HelloWorld Projekt übersetzt werden soll.

  • INFO - rationStore.ComponentStoreImpl - Saving appEditorColorsManagerImpl took 14 ms
  • INFO - rationStore.ComponentStoreImpl - Saving appPluginAdvertiserExtensions took 24 ms, XDebuggerSettings took 11 ms
  • INFO - ij.compiler.impl.CompileDriver - COMPILATION STARTED (BUILD PROCESS)
  • INFO - rationStore.ComponentStoreImpl - Saving appFindSettings took 14 ms
  • INFO - rationStore.ComponentStoreImpl - Saving Project(name=HelloWorld, containerState=COMPONENT_CREATED, componentStore=/home/frank/Development/Projekte/IntelliJ/HelloWorld)KotlinCommonCompilerArguments took 31 ms

Ich musste den Build-Prozess wieder abbrechen, da die ca. 5 Zeilen Code nicht übersetzt wurden. Es ist nicht wirklich ein Fehler zu finden.

Naja, es geht ja auch mit dem build.xml Script.

VG aus LE
Franco
 
  • WARN - #com.intellij.idea.Main - Unable to load JNA library (OS: NetBSD 9.99.81)
  • Native library (com/sun/jna/netbsd-x86-64/libjnidispatch.so) not found in resource path (/usr/local/idea-IC-203.7717.56/...

Da haben wir doch schon das Problem. Der Build-Prozess ist - wie der Name sagt - ein eigenständiger Prozess, mit dem IntelliJ via Java Native Access kommuniziert. Ohne JNA geht natürlich die Kommunikation mit dem Build-Prozess nicht.

Wie es aussieht, wird weder der uralte IntelliJ-Port noch sein Ersatz gepflegt.

Mit den aktuellen Linux-Binaries von IntelliJ geht natürlich ohne Linux-Emulation die native Kommunikation nicht.

Naja, es geht ja auch mit dem build.xml Script.

Ist das nicht extrem umständlich? Zumal vermutlich viele weitere essentielle Features (Integration von Maven, Gradle, Unit-Test-Frameworks uvm.) wohl auch nicht gehen.
 
@Azazyel

Ja, es ist umständlich und unvollständig. Aber meine Java Aufgaben kann ich so übersetzen und das reicht i.M. für's Programmieren. Es wird sicher keine NetBSD Unterstützung mehr geben und die Linux-Emu will ich nicht. Zur Not müssen dann die anderen Rechner ran.

Danke für's Helfen!
 
Zurück
Oben