Schlagwort-Archive: NetBeans

Solarisiere dein Leben!

Nein, ich meine keinen neuen digitalen Filter, der die neuesten Instagram-Hipster for Freude jauchzen lässt. Auch nicht die (nicht minder nerdigen, da retro) echte Solarisation, mit der schöne Effekte erzielt werden können.

The Black Sun (1939)

The Black Sun (1939) von Ansel Adams, aus dem Buch Examples: The Making of 40 Photographs. Original in der Sammlung der Yale Art Gallery.

Weitere schöne Beispiele, für den echten Effekt auch in der Serie 1h von Hans-Christian Schink.

Stattdessen geht es um mein aktuelles Lieblings-Farbschema für Programmierung, Solarized von Ethan Schoonover, das vom deutschen KDE-Team passend übersetzt wird ;)

Solarized für Bash

Für die Nutzung in Vim wird pathogen benötigt. Wenn es noch nicht installiert ist, die Schnellanleitung geht wie folgt:

# Verzeichnisse anlegen
mkdir -p ~/.vim/autoload ~/.vim/bundle
# Herunterladen und installieren
curl -LSso ~/.vim/autoload/pathogen.vim https://tpo.pe/pathogen.vim

Um pathogen nutzen zu können, muss es in der ~/.vimrc aktiviert werden:

" Pathogen
execute pathogen#infect()
syntax on
filetype plugin indent on

Nun können neue vim-Pakete einfach in das Verzeichnis geladen werden. Für Solarized geht das wie folgt:

# Wechseln in das (spätestens soeben erzeugte) Verzeichnis
cd ~/.vim/bundle
# Installieren über git-clone
git clone git://github.com/altercation/vim-colors-solarized.git

Modifikation in der .vimrc:

" Solarized
syntax enable
set background=dark
colorscheme solarized

Solarized für NetBeans
Die benötigten Dateien für NetBeans liegen ebenfalls in einem Git-Repository.

mkdir tmp
cd tmp
curl -sOL https://github.com/fentie/netbeans-colors-solarized/archive/master.zip
unzip master.zip
pushd netbeans-colors-solarized-master/
zip -r ../config-nb.zip config/
popd

Das Farbschema kann nun in NetBeans importiert werden. Dazu muss unter Extras | Optionen die Schaltfläche Import... in der unteren linken Ecke gewählt werden. Nachdem die gerade erstellte Datei config-nb.zip kann importiert werden und NetBeans verlangt von selbst einen Neustart.

Das Profil ist automatisch aktiviert, man kann wechseln unter Extras | Optionen | Schriften und Farben als Profil.

Die heruntergeladenen Dateien und das Verzeichnis kann gelöscht werden.

Netbeans mit Solarized-Farbschema

Netbeans mit Solarized-Farbschema

Geschrieben von Kap. Zuletzt geändert am 10. März 2017.

Der Java user.home-Bug

Ich habe kürzlich mein System neu aufgesetzt und bin dabei auf ein Problem gestoßen, das die Java-Entwickler seit Jahren nicht lösen.

Ich unterteile (unter Windows) mein System in zwei Teile,C: und D:. Auf ersterem Laufwerk installiere ich die Programme und Windows, auf letzterem lagere ich meine Daten. Naheliegend, weil D nach C kommt aber auch für Daten ;) . So kann ich das System neu aufsetzen und die Daten einfach mitnehmen. Nach der Neuinstallation muss ich nur die Ordner von zum Beispiel C:\Users\Benutzername\Desktop wieder auf D:\Desktop umbiegen und alles ist wie gehabt.

Nun wollte ich NetBeans installieren, das schlug aber fehl mit dem Hinweis, dass im Verzeichnis D:\ nicht mehr genug Platz vorhanden sei (etwa 600 MiB waren nötig, meine alte Platte war aber voll) um einen Ordner .nbi anzulegen oO . Nun erinnerte ich mich, dass ich schon immer den Ordner D:\.nbi hatte und den auch durch Löschen nicht dauerhaft entfernen konnte. Eine schnelle Suche ergab folgendes:

Der Ordner .nbi wird von der Installationsroutine angelegt und sollte eigentlich in %USERPROFILE%, also in der Windows-Variante des Home-Verzeichnisses liegen. Im Blog von Tim Ehat fand ich die Lösung: Das Home-Verzeichnis wird von der JVM über eine Systemeigenschaft „user.home“ abgefragt, zum Beispiel so:

public class PropertyTest {
    public static void main(String[] args)
        throws Exception {
			System.out.println( System.getProperty("user.name") );
			System.out.println( System.getProperty("user.home") );
			System.out.println( System.getProperty("user.dir") );
		}
}

In Windows wird jedoch das Elterverzeichnis des Desktops genommen (der bei mir nunmal unter D:\Desktop liegt). Das ist nun auch die Erklärung, warum ich diese Verzeichnisse auf Laufwerk D bekomme.

Man kann das nun ganz einfach Umbiegen: Die JVM fragt eine Umgebungsvariable _JAVA_OPTIONS ab, in der man den Java-Parameter -Duser.home=%USERPROFILE%\AppData\Roaming eingeben kann, oder einen beliebigen anderen Pfad.

Fazit: endlich ist mein System sauber und die Datenplatte von unnötigem Müll befreit. Was die Entwickler dazu getrieben hat, einen selten dämlichen Algorithmus zur Bestimmung des Home-Verzeichnisses zu wählen und das nicht zu fixen, weiß ich leider auch nicht. Im Kommentarbereich von Tims Blog wird angedeutet, dass es an Abwärtskompatibilität liegt. Aber mal ehrlich: Wenn man den Pfad zumindest auf %USERPROFILE% setzt bekommen das normale Anwender nicht mit. Und Nutzer, die ihren Desktop umlegen sollten in der Lage sein, eventuell auftretende Probleme zu Fixen.

Geschrieben von Kap. Zuletzt geändert am 4. Januar 2014.

SVN-Revisionen mit NetBeans automatisch einfügen

Insbesondere in OpenSource-Projekten, bei denen Benutzer verschiedene Versionen der Software haben können, kann es zu Debugging-Zwecken sehr interessant sein, die SVN-Version einfach lesbasr zu machen.

Ich beschreibe hier eine Variante unter Windows mit TortoiseSVN und NetBeans.

SVN bietet die Möglichkeit, bestimmte Strings durch die Versionsnummer einer einzelnen Datei ersetzen zu lassen. Schreibt man in eine Datei den String $Rev:$, wird von SVN der Text automatisch durch die aktuelle Revision der Datei ersetzt, also zum Beispiel zu $Rev: 2658 $. Man muss dazu für die ausgewählte Datei ein Schlüsselwort aktualisieren. Bei Tortoise muss im Kontextmenü der Datei der Menüeintrag „TortoiseSVN | Properties“ ausgewählt werden und im sich öffnenden Fenster „New | Keywords“. Von den möglichen Keywords muss „Revision“ ausgewählt werden.

Durch diese Einstellung kann für jede Datei die Version der Datei gespeichert werden. Nun mag es aber auch interessant sein, die aktuellste Version zu haben. Tortoise bietet dazu das Tool subwcrev an. Es kann eine Template-Datei lesen und in dieser Datei sämtliche Vorkommen von $WCREV$ durch die maximale SVN-Revision aller Dateien im Repository zu ersetzen. Bei einer standardmäßigen Installation ist das Tool im Windows-Pfad enthalten und kann direkt aufgerufen werden. Ansonsten ist es unter /bin im Tortoise-Verzeichnis zu finden.

Wir gehen davon aus, dass wir eine Datei version.tmpl haben, in der nur $WCREV$ steht. Wir wollen eine Datei version.txt erstellen, in der die Versionsnummer steht. Der der Aufruf auf Befehlszeile lautet subwcrev . version.tmpl version.txt. Die Ausgabe enthält noch weitere Informationen und sieht zum Beispiel so aus
SubWCRev: 'D:DokumenteProgrammeTool'
Last committed at revision 2657
Mixed revision range 2655:2657
Local modifications found

Damit dieser Befehl nicht jedes mal manuell aufgerufen werden muss, kann man ihn in das NetBeans-Build-Script eingefügt werden. Dazu wird die Datei build.xml bearbeitet. Direkt nach <import file="nbproject/build-impl.xml"/>

fügen wir das Folgende hinzu:

<target name="-pre-compile">
<exec executable="subwcrev" output="svn-revision.log">
<arg line=" . version.tmpl version.txt">
<exec>
<target>

Damit teilen wir der Entwicklungsumgebung mit, dass vor dem Kompilieren das subwcrev-Tool ausgeführt werden soll, welche Parameter übergeben werden wollen und dass die Ausgabe in der datei svn-revision.log gespeichert werden soll. Falls etwas falsch angegeben worden ist, werden die Fehlermeldungen ebenfalls in diese Datei geschrieben.

Nun noch ein Beispiel, wie im Programm auf die Versionsinfos zugegriffen werden kann. Ich habe einen doppelten Ansatz gewählt: es wird versucht, den Text der Datei version.txt einzulesen. Falls dabei etwas schiefgeht, wird die lokale SVN-Revsionsnummer genommen.

/** SVN version */
public final static String revision = getVersion();
 
/**
* Reads the svn revision from a file with name 'version.txt'. If an exception
* occurs, the revision of this source code file is returned. WARNING: no error
* checks are performed!
*/
private static String getVersion() {
  try {
    return new String( Files.readAllBytes( Paths.get( "./version.txt" ) ) );
  } catch( IOException ex ) {
    return "> $Rev: 2658 $"; // return emergency value
  }
}

Das war’s auch schon. Nun kann man im Programm auf die aktuelle Revisionsnummer zugreifen. Die Textdatei wird bei jeder Ausführung von Clean & Build ausgefüht.

Alternativ kann man natürlich auch eine Java-Klasse als Template erzeugen und somit auf das Einlesen verzichten. In dem Fall bietet es sich an, eine eigene Klasse nur für den Versionstext zu entwickeln, da sonst immer das Template verändert werden muss, nicht die „richtige“ Quelldatei.

Geschrieben von Kap. Zuletzt geändert am 18. März 2013.