everflux

I you are using Netbeans to develop a maven based (multi-module) (web) application you may have encountered this problem: The resources are not copied when re-running the application. The easy option: Build the project always before running it.

This is slow and just feels wrong. Netbeans lets you customize the life-cycle of your project, so you can hook all maven executions you like, especially the ‚resources‘ build step.

Open project properties, select ‚Actions‘ and add ‚resources:resources‘ to the front of the ‚execute Goals‘ field:

You can add your own custom action as well, in case you want to trigger a specific step independently of the overall project lifecycle, for example the ‚resources:resources‘ goal:

As I regularly test different versions of Netbeans as part of the community acceptance program (NetCAT) and for my own fun and benefit I sometimes struggle to start of the right version: Usually the release version is the right one to go. During NetCAT the beta version needs to be tested and when new features are so promising that you want to run the nightly, you go with that.

I came up with a simple solution to never  launch the wrong edition: Differently colored Netbeans icons. This is how my Gnome launcher looks:

Easy to tell that red is the nightly, without looking at the icon text! If you want that for yourself, you can get the icons here:

The icons are created using Gimp and just rotating the colors, so it’s a little hacky but does the trick.

In Gnome you can use the application ‚alacarte‘ (or ‚main menu‘ if you run the english locale) to customize your launchers. Just change the icon:

Vielleicht hilft dieser Tipp dem einen oder anderen weiter, der gerne die Netbeans IDE zur PHP Entwicklung verwendet und auch Vagrant nutzt: Wenn man mit Vagrant arbeitet, so werden die lokalen Dateien in der virtuellen Maschine gemounted. Für Netbeans konfiguriert man daher „lokalen Webserver“ als Umgebung.
Die Konfiguration von xdebug sieht dann am einfachsten so aus:

[xdebug]
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
;xdebug.remote_autostart = 1
xdebug.remote_handler=dbgp

Hier wird xdebug angewiesen, sich zum Aufrufer zurück zu verbinden – die IP wird aus dem Request genommen. Das passt in der Regel, wenn man innerhalb von Vagrant nicht noch wilde Sachen (Proxy) macht.
Was leider nicht passt: Die Pfade. Netbeans weißt xdebug für Breakpoints an, welche Datei – inkl. Pfad – an welcher Stelle einen Breakpoint erhalten soll. Die Ordnerstruktur ist innerhalb der virtuellen Maschine höchstwahrscheinlich anders, als auf dem Host-System.
Hierzu gibt man innerhalb von Netbeans noch ein Pfad-Mapping an: Projekt Konfiguration, „Run Configuration“, „Advanced“.
Nun waehlt man aus, wo man innerhalb der Vagrant bzw. VirtualBox Umbebung den Projekt Ordner eingebunden hat. In meinem Beispiel ist das /var/www/localhost

Anschließend kann man den Netbeans Debugger verwenden.
Möchte man spezielle Requests, wie z.B. PUT, mittels curl aufrufen kann man dies auch ganz einfach machen, in dem man den Xdebug Trigger als Parameter anhängt:

curl -X PUT -d '{}' http://localhost:8080/rest/endpoint.php/duplicates\?XDEBUG_SESSION_START\=netbeans-xdebug


Ein Screenshot der Netbeans Konfiguration als Referenz:

Test driven development ist inzwischen schon fast ein alter Hut. Um so mehr ist es wichtig, dass die Produktivität stimmt. Hält man sich an bestimmte Namenskonventionen, so unterstützen alle modernen IDEs schnelles Umschalten zwischen Test-Code und Produktionscode.

Dazu nennt man seine Testklasse genauso wie die Class-under-test, beispielsweise „FibonacciTest“ falls die eigentliche Klasse „Fibonacci“ heißt. Mittels Control-Shift-T kann man in Netbeans dann zwischen den beiden Klassen umschalten. Heute habe ich noch was gelernt: Control-F6 startet den Unit test – und zwar auch dann, wenn man ihn nicht fokussiert hat, also in der eigentlichen Klasse im Editor ist. („Fibonacci“ in diesem Beispiel)

Das spart unnötige Kontext-Switche, macht einfach Spaß und bringt Produktivität. Mein Tipp: Ausprobieren!

Mit Alt-F6 startet man übrigens alle Tests zu einem Projekt. (Falls einem nicht komische Ubuntu Tastenkürzel dazwischenfunken.)

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 »