everflux

Seit Netbeans 7.1 ist JSLint als Plugin verfügbar. Mit JSLint wird JavaScript auf (mögliche) Fehler untersucht und diese als Warnungen im Editor angezeigt. (Aufruf mit Rechtsklick innerhalb einer JavaScript Datei und dann “JSLint” klicken)

Jedoch gibt es dabei auch falsche Warnmeldungen wenn JsLint nicht richtig konfiguriert ist. So warnt mich Netbeans 7.1 dann bei einer JavaScript Datei, als externe Ressource zusammen mit jQuery in eine Webseite eingebunden ist:

“$ was used before it was defined”

Dies lässt sich beheben, indem man die JSLint Konfiguration (Tools->Options->Misc->JSLint) aufruft und dort unter “predefined” das “$” deklariert. Leider wurde diese Einstellung bei mir  nicht korrekt gespeichert und hatte auch keine Auswirkungen auf das Verhalten von JSLint. Ich nehme an, dass der Fehler mit einem Update des Plugins behoben wird.

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem “Master Password” gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter “0″. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die “echte” Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern “lediglich” eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Verwendet man Maven für ein Java JSP Projekt und Netbeans als IDE, so koennen erstaunliche Fehler entstehen: Um mit Servlets zu arbeiten, wird man im Maven die Abhängigkeit auf die Servlet API deklarieren. Da der Webcontainer sich später um die Implementierung der Servlets – und auch das Kompilieren von JSP Seiten – kümmert, gibt man als Scope “provided” an.

Beispielsweise so:

<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
   <scope>provided</scope>
</dependency>

Damit funktioniert die Entwicklung dann auch prinzipiell – bis auf rote Hinweise und Fehlermeldungen im Netbeans JSP Editor:

“package javax.servlet.jsp does not exist”
(cannot find symbol)

und so weiter und so fort. Bei allen JSP Direktiven, JSP Deklarationen etc. gibt es einen Hinweis darauf, dass Netbeans da etwas im Classpath fehlt. Und Netbeans hat dabei auch Recht – wenn man die JSP API nicht ebenfalls als Projekt Abhängigkeit deklariert. Hier hilft also ein kleiner Zusatz in der Maven pom.xml, der so aussehen könnte:

<dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>jsp-api</artifactId>
   <version>2.1</version>
   <scope>provided</scope>
</dependency>

Hier ist die JSP Version 2.1 passend zur Servlet API 2.5 gewählt. Anschließend einmal “clean and build” in Netbeans geklickt, und die “package javax.servlet.jsp does not exist” Fehler sind behoben.

Ich wollte eigentlich nur etwas ganz simples: Continuous Deployment. Das ist der neueste Trend nach Continous Integration habe ich mir sagen lassen. Und gerade wenn man in einem Team arbeitet ist es schon vorteilhaft, wenn man einen stabilen Build staendig deployt hat.

Hudson ist mein bevorzugter Buildserver (auch wenn Bamboo wirklich ansprechender ist, aber eben auch eine Ecke teurer und nicht OpenSource) – und es gibt auch ein Plugin fuer Hudson, mit dem man ein Deployment anstarten kann: http://wiki.hudson-ci.org/display/HUDSON/Deploy+Plugin
Leider funktioniert das bei dem Glassfish nicht, wenn Hudson nicht auf dem selben Server läuft, wie der Glassfish. (Das sollte/dürfte der Regelfall sein.)
Weiterlesen »

Netbeans ist nun in der Version 6.9 von Oracle freigegeben worden. Die Entwicklungsumgebung für Java, PHP, JavaScript, Groovy, Scala, … wird von Oracle zusammen mit der OpenSource Community entwickelt. Das nun veröffentlichte Netbeans 6.9 enthält viele Neuerungen. Für PHP Entwickler besonders interessant ist die Unterstützung des Zend Framework in der aktuellen Version. Weiterlesen »

Netbeans hat einen sehr guten Support für Maven, Maven Projekte werden genauso gut behandelt, wie die ant basierten nativen Netbeans Projekte.

Doch an einer Stelle hakt es etwas: Moechte von Maven dependencies auch den Source Code bzw. JavaDoc zur Verfuegung haben, reicht es nicht, wenn man (wie üblich) ueber die Maven Properties
<downloadSources>true</downloadSources> und <downloadJavadocs>true</downloadJavadocs> den Download aktiviert. Weiterlesen »

Netbeans hat – zum Glück – neuerdings Maven Support. Das macht insbesondere die Anpassung des Build Prozesses wesentlich einfacher. Dazu kommt, dass Maven Kenntnisse nicht nur bei Netbeans Usern verbreitet sind, und so bessere Interoperabilität erzielt wird.
Hat man jedoch kein Maven Projekt, sondern das “klassische” ant basierte Chaos Buildsystem, können Anpassungen schonmal komplizierter werden.

In diesem Fall ging es darum, dass mit Netbeans /ant produzierte Artefakte als einzelne JAR Datei verteilbar sein sollten. D.h. alle Bibliotheken bzw. Library JAR Files sollten in einem einzelnen, ausführbaren JAR landen. Weiterlesen »

Netbeans ist eine herausragende IDE – herausragend durch einfache Bedienbarkeit, gleichzeitig gibt es eine Fülle von Features für den gestressten Entwickler. Und der Preis: Kostenlos! Ob für Java oder PHP Entwicklung, ich möchte Netbeans nicht mehr missen. Besonders für PHP – haben mir die kleinen Tipps und Hinweise doch schon einiges an Nerven gespart. Nicht zu vergessen die erstaunlich gut funktionierende Code-Completion. (Hätte ich bei PHP nie für möglich gehalten.)

Doch es gibt eine Sache, die mich unter Ubuntu in den absoluten Wahnsinn getrieben hat: Ich habe zwei Ubuntu Rechner, einen Server und meinen Arbeitsplatz. Auf dem Server läuft Apache und Mysql – auf meiner Arbeitsstation möchte ich keinen Apache laufen lassen, so dass ich alle Dateien auf den Server lade. Weiterlesen »

Welche IDE man bevorzugt, darüber kann man sicherlich vortrefflich streiten. Genauso übrigens auch über Webbrowser. Doch eins ist klar: Bei der Entwicklung zählt jede gesparte Sekunde. Gerade in Webanwendungen wird man nicht um manuelles Testen und Ausprobieren herumkommen. Ich habe gemerkt, dass man mit dem Firefox (Firebug, Webdeveloper Toolbar, etc. pp) wunderbar Debugging betreiben kann. Das Tooling ist in meinen Augen ungeschlagen. Weiterlesen »

Netbeans 6.7 ist als finale Version verfügbar. Auch wenn auf der Netbeans Homepage noch der RC beworben wird, führt der Download schon auf die endgültige Version. (So ganz fertig ist das zwar noch nicht, der Rest soll dann aber über das Update Center nachgereicht werden.)

Die Neuerungen sind vor allem “Cloud” (Kenai) Integration, bessere CI Integration (Hudson z.B.) und Integration mit Issuetrackern. (Bei einem Commit können dann direkt Issues geschlossen werden.) Aber auch die Unterstützung für verschiedene Sprachen und Frameworks (PHP, Rails, Groovy, Grails, …) wurde stark verbessert. Details finden sich auf der Übersichtsseite zum Netbeans 6.7 Release und in den Release Notes zu Netbeans 6.7, wer Netbeans noch garnicht kennt kann einen Blick auf die Features werfen.

Und meine Liebslingsneuerung: Dateien können nun inklsusive Dateiendung umbenannt werden….