Wenn man schon eine OpenSource Platform verwendet, will man den Quelltext auch gerne zum Debuggen verwenden. In Maven gestützten Projekten gibt es den Kontextmenü Befehl "Download Sources" im Libraries Ordner des Maven-Projektes.

Allerdings funktioniert es bei mir nicht 100%. Aus irgend einem Grund bricht der Download dabei ständig ab. Außerdem ist der Kontextmenü Befehl nur lokal für das Projekt, in dem die Libraries sichtbar sind.

Es gibt aber eine andere - m.E. elegantere - Lösung die Quelltexte komplett für ein Projekt zu laden.

Dafür geht man im Platform Projekt in die Project Properties -> Actions -> Add Custom und benennt die neue Action z.B. Download sources. Im Feld "Execute Goals" trägt man dann dependency:sources ein.

Nach dem man die Projekteigenschaften geschlossen hat, ist nun im Kontextmenü unter dem Eintrag "Custom" die neue Action aufgetaucht: "Download sources". Führt man diese aus, werden alle abhängigen (und existierenden) Source-Code JARs in das lokale Repository geladen. Ggf. muss man noch ein "Reload project" durchführen und sieht dann unter Libraries alle Bibliotheken mit Quelltext anhand ihres neuen Icons (mit einem kleinen Paket).

Die Quelltexte im lokalen Maven Repository sind auch automatisch im Debugger-Source Fenster aktiviert und können somit sofort verwendet werden.

Beste Grüße,
  Josch.

Statt etwas von meinem Wissen preis zu geben stelle ich hier einfach mal eine Frage an alle: Wie übersetzt ihr eure NetBeans Plattform Anwendungen? Mir ist klar, wie ResourceBundles funktionieren. Mir ist klar, dass man Module erzeugen kann, die nur die übersetzten Texte enthalten und per Updatecenter verteilt werden. Mich interessiert: Welche Tools verwendet ihr. [...]

Moin!

Um den Inhalt eines InstanceContent komplett zu löschen, ohne die beinhalteten Objekte zu kennen, gibt es folgenden Befehl:

content.set (Arrays.asList (Object.class), null);

Das erspart in einigen Szenarien unnötige Klimmzüge. Mit dem Befehl werden alle Dictonary-Objekte vom Typ Object.class mit dem Wert null besetzt. Da alle Java-Objekte immer vom Typ Object sind, ist die Registry in dem InstanceContent zurückgesetzt. Im Ergebnis gibt das Lookup (das den Content besitzt) nichts mehr zurück, ist also leer.

Beste Grüße,
  Josch.

Es gibt eine sehr gute FAQ die zu meinem alten Blog Eintrag zum AutoUpdate Center passt: FaqPluginManagerCustomization.

In der FAQ wird beschrieben, wie man die Darstellung und das Verhalten des Plugin Managers modifizieren kann. Hier mal ein paar Auszüge:

Alle Module anzeigen

Setzt man das System property plugin.manager.modules.only auf true (z.B. in der etc-Datei per -J-Dplugin.manager.modules.only=true), werden alle Module angezeigt. Egal, ob diese als unsichtbar gekennzeichnet wurden. Das ist zum Testen in der Entwicklung sehr hilfreich, weil man ja doch ab und zu ein paar Abhängigkeiten vergisst.

Code Name Base der Module anzeigen

Auch das ist für die RCP Entwicklung sehr praktisch:

-J-Dplugin.manager.extended.description=true

Plugin Manager geschwätziger machen

Wenn man mehr Infos braucht, was der Plugin Manager gerade so tut, helfen einem diese Optionen weiter:

-J-Dorg.netbeans.modules.autoupdate.ui.actions.AutoupdateSettings.level=FINE
-J-Dnetbeans.logger.console=true

Es lohnt sich die FAQ mal anzuschauen, da dort noch weitere Einstellungen zum Installations- und Updateverhalten beschrieben werden.

Beste Grüße,
  Josch.

Moin!

Eine sehr schöne kleine Zusammenfassung, wie man (auch vorzeitig zu beendende) Hintergrundprozesse in der NetBeans Plattform programmiert findet man hier.

In dem Blog wird beschrieben, wie man sauber Hintergrundtasks implementiert, wie sie im Fortschritt in der Statuszeile angezeigt und abgebrochen werden können.

Meines Erachtens ist die Verwendung des RequestProcessor immer dem SwingWorker vorzuziehen. SwingWorker ist zwar einfacher zu verwenden, RequestProcessor ist aber erheblich mächtiger. Die done-Methode des SwingWorker realisiert man über einen TaskListener. In der taskFinished kann man dann per SwingUtilities.invoke* GUI Updates durchführen. Bei häufiger Verwendung macht es bestimmt Sinn eine Hilfsklasse namens NbSwingWorker auf Basis des RequestProcessor zu implementieren ;-)

Beste Grüße,
  Josch.

Wie Ihr wisst, gibt es ja schon schon ziemlich viele NetBeans-Bücher auf Englisch und anderen Sprachen. Und wie steht es mit deutschsprachiger Literatur? Hier ein kleiner Überblick:

• NetBeans 6 - Rich-Client-Entwicklung mit Java (Download: Beispielkapitel)

• Java EE 5 Architekturen. Java Patterns und Idiome (Download: Beispielkapitel kommen noch)

• Datenbankentwicklung mit db4o (Download: PDF und Beispielprogramme)

• Prüfungsvorbereitung für den Sun Certified Java Programmer (SCJP) (Download)

• NetBeans RCP - Das Entwicklerheft - dieses ist allerdings noch nicht veröffentlicht.

Die Frage kommt häufiger in den Schulungen und auch die Foren sind voll davon: Hat NetBeans eine FileChooser Komponente? 

Die Antwort ist einfach: Nein ;-) - Der Grund auch: Swing hat einen sehr guten JFileChooser, der genutzt werden kann.

Aber da muss man sich immer noch viel Arbeit machen, um einen (für den Anwender) praktisch bedienbaren Datei-Dialog zu basteln.

Die FileSystem-API hat dafür aber auch eine Lösung: Der FileChooserBuilder.

Der lässt sich sehr einfach über Method-Chaining konfigurieren und merkt sich auch das zuletzt gewählte Verzeichnis.

Hier ein Beispiel, für die Auswahl einer Datenbank-Datei:

    File basePath = new File (System.getProperty("netbeans.user"));

    File db = new FileChooserBuilder("database-dir")
            .setTitle("Choose a database")
            .setDefaultWorkingDirectory(basePath).addFileFilter(new FileFilter() {
              @Override
              public boolean accept(File f) {
                String name = f.getName().toLowerCase();
                return name.endsWith(".fdb") || name.endsWith(".gdb");
              }

              @Override
              public String getDescription() {
                return "Firebird Database (*.fdb | *.gdb)";
              }
            })            
            .setApproveText("Choose").showOpenDialog();

    if ( db != null ) {
      tfDatabase.setText(db.getAbsolutePath());
    }

Spannend in dem Zusammenhang ist der BadgeProvider. Mit Ihm kann man Dateien mit kleinen zusätzlichen Icons versehen (wie man es in der IDE auch gewohnt ist).

Beste Grüße,
  Josch.

Wenn man mit Annotationen in der NetBeans Platform arbeitet bekommt man eine deutliche Erleichterung, da man weniger in den layer.xml Dateien arbeiten muss. Trotzdem gibt es noch kleinere Fallstricke.

Möchte man dem Optionen-Dialog eine eigene Haupt-Kategorie zuordnen, in der Unterkategorien registriert werden dürfen (wie es die Verschiedenes-Kategorie zeigt), muss man eine besondere Form der Annotation verwenden: Die package-level Annotation @OptionsPanelController.ContainerRegistration.

Diese Annotation muss vor der package Deklaration angegeben werden:

@OptionsPanelController.ContainerRegistration(
  id="SepixBaseOptions",
  categoryName = "#OptionsCategory_Name_SepixBase",
  iconBase = "de/sepix/core/options/base/s-logo_32.png",
  keywords = "#OptionsCategory_Keywords_SepixBase",
  keywordsCategory = "SepixBase", position=10)
package de.sepix.core.options.base;

import org.netbeans.spi.options.OptionsPanelController;

Alte Java-Hasen werden sagen, dass das niemals eine vollständige Java-Datei sein kann, die compilierbar wäre. Das ist auch tatsächlich so. Es fehlt nämlich eine Klasse in dem Quelltext. Damit der Compiler nicht mit Fehler aussteigt, muss diese Datei eine ganz bestimmte Namenskonvention haben: sie muss package-info.java heißen.

Damit kommen wir zum nächsten Fallstrick. Der New File... Assistent für Java-Klassen erlaubt es nicht, einen solchen Namen zu verwenden. Man muss also das Empty File Template nehmen, als Namen package-info.java eintragen und die Datei mit der ContainerRegistration-Annotation bestücken. 

Hat man ein passendes Icon und die Bundle.properties Datei im selben Package, erscheint tatsächlich eine leere Kategorie im Optionen-Dialog.

Jetzt kann man mit dem Assistenten weitere Sub-Kategorien erzeugen. Diese Sub-Kategorien erhalten als Primärpanel die ID des obigen Beispiels (man wählt also nichts aus der Combobox aus, sondern gibt die ID von Hand ein).

Man erhält damit den Panel-Controller und das GUI als Panel. Die Annotation zum Controller sieht dann so aus:

package de.sepix.core.options.base.db;

import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import javax.swing.JComponent;
import org.netbeans.spi.options.OptionsPanelController;
import org.openide.util.HelpCtx;
import org.openide.util.Lookup;

@OptionsPanelController.SubRegistration(location = "SepixBaseOptions",
  displayName = "#AdvancedOption_DisplayName_Database",
  keywords = "#AdvancedOption_Keywords_Database",
  keywordsCategory = "SepixBase/Database")
public final class DatabaseOptionsPanelController extends OptionsPanelController {

Wichtig ist, dass location der id des Containers entspricht.

Die Bundle-Datei wurde schon vom Assistenten angelegt. Hier mal ein Screenshot, wie die Optionen nun aussehen (könnten):

Beste Grüße,
  Josch.

Es gibt ein paar Einstellungen die seit den 6'er Versionen neu in die manifest.mf hinzugekommen sind, die sich direkt auf die Ansicht des AutoUpdate-Center auswirken. Da man bei Maven Builds keine Einstellungen durch Assistenten hat, sollte man sich die Optionen mal wieder gedanklich abrufen:

Module unsichtbar schalten

Soll ein Modul nicht sichtbar für den Anwender sein, fügt man folgenden Eintrag hinzu:

AutoUpdate-Show-In-Client: false

Standard ist true (Modul wird im Plugin-Dialog angezeigt.).

Module durch Anwender nicht zu deinstallieren

Darf der Anwender ein Modul nicht deinstallieren, muss es als Essential gekennzeichnet werden:

AutoUpdate-Essential-Module: true

Beste Grüße,
  Josch.

In einer meiner letzten Schlungen kam die Frage auf, wie man Unit-Tests für RCP Module durchführen kann, wenn man abhängige Module der Platform benötigt.

Die Antwort ist NbModuleSuite.

Diese Hilfsklasse erlaubt es vor einem Test abhängige Module zu laden, damit der Test durchlaufen kann:

 public class YourTest extends NbTestCase {
   public YourTest(String s) { super(s); }
 
   public static Test suite() {
     return NbModuleSuite.create(YourTest.class);
   }
 
   public void testXYZ() { ... }
   public void testABC() { ... }
 }

Die Aktivieren der abhängigen Module erfolgt über die Configuration der NbModuleSuite:

 public static Test suite() {
   return NbModuleSuite.create(
     NbModuleSuite.createConfiguration(YourTest.class)
       .addTest(YourTest.class, new String[] { "testXYZ"})
       .enableModules(".*").clusters(".*")
   );
 }

Beste Grüße,
  Josch.

Mit NetBeans 6.9 wurde die Lookup API in ein extra Modul ausgelagert. Will man nun seine Projekte (RCP, Plugins) auf die neue API verlinken müssen die Abhängigkeiten neu aufgelöst werden.

Ant basierte Projekte

Für Ant-Projekte gibt es ein sehr einfaches target, um die Abhängigkeiten generell zu korrigieren:

ant fix-dependencies

Das dauert eine Weile, bietet aber einen sicheren Schutz vor Buildfehlern. In der IDE kann man das über "Important files" -> rechter Mausklick auf "Build scripts" -> "Run target" -> "fix-dependendies" aufrufen.

Maven basierte Projekte

Da muss man alles zu Fuß machen. Das Lookup-Artifakt wird so eingebunden:

<dependency>
    <groupId>org.netbeans.api</groupId>
    <artifactId>org-openide-util-lookup</artifactId>
    <version>${netbeans.version}</version>
</dependency>

Und die Platform hat seit 6.9 keine Versionskennung mehr. Es darf also nicht mehr platform11 heißen, sondern nur noch platform. Also im Application pom:

<dependency>
    <groupId>org.netbeans.cluster</groupId>
    <artifactId>platform</artifactId>
    <version>${netbeans.version}</version>
    <type>pom</type>
</dependency>

Das war es schon. Nun sollte man die Projekte mal unter der neuen Platform testen.

Beste Grüße,
  Josch.

Nachdem NetBeans 6.9 jetzt offiziell draußen ist, habe ich auch mal das “Organize Imports” Plugin für diese Version zurecht gemacht. Download ist über die Kenai Projektseite möglich: http://kenai.com/projects/organizeimports/downloads/directory/NBMs

NetBeans speichert nahezu alle seine Einstellungsdateien im so genannten “userdir” ab. In diesem Verzeichnis werden auch der Cache und die Protokolldatei abgelegt. Sollten keine Schreibrechte im Programmverzeichnis vorhanden sein (oder der Benutzer es gar nicht dort speichern wollen) werden auch alle Updates über das Autoupdate in diesem Benutzerverzeichnis abgelegt. Eine Menge Daten. Die Standardeinstellung von [...]

Moin!

Die neuen Java Trends sind raus und zeigen, dass die NetBeans IDE stark in der Nutzung zunimmt. In den letzten Java-Trends war die NetBeans IDE noch bei 30%, inzwischen nutzen knapp 50% aller Entwickler NetBeans.

Der Anstieg der Nutzung der der NetBeans IDE ist damit bemerkenswert. Wir werden weiter daran arbeiten, dass das so bleibt!

Beste Grüße,
  Josch.

Wenn man bei bisherigen Ant-Projekten sehr große NetBeans RCP Applikationen entwickelte, konnte man dies durch Suites recht gut organisieren.

Eine Suite sind eine Organisationseinheit, die Module zusammenfasst und im Build-Prozess auch, mit einer XML-Datei, für alle Module der Suite gemeinsames Updatecenter erzeugt.

Die Suites, die per Maven Projekt erzeugt werden, sind allerdings sehr auf IDE Plug-ins eingeschossen. D.h. ihr primärer Einsatzzweck orientiert sich an die Erweiterung der NetBeans IDE.

Nur ist die IDE ja auch eine Plattform Applikation, warum sollte man Suites nicht auch für die eigene Plattform verwenden?

Als grundlegende Ordnerstruktur habe ich folgendes vorbereitet:

├───platforms
│   └───sXbase
├───suites

Das Projekt sXbase ist die RCP Anwendung, für die ich eine Suite anlegen möchte.

Unter dem Ordner suites wird nun per Assistent ein Maven NetBeans Module Suite angelegt. In diesem Fall suite-demo. Artifact ID ist de.sepix.demos, Paket wird zu de.sepix.demos.suitedemo.

Im weiteren Schritt des Assistenten lass ich mir gleich ein Modul mit dem Namen module-sample erzeugen.

Das Ergebnis ist überschaubar:

suites
├───suite-demo
│   └───module-sample
│       └───src
│           ├───main
│           │   ├───java
│           │   │   └───de
│           │   │       └───sepix
│           │   │           └───demos
│           │   │               └───suitedemo
│           │   ├───nbm
│           │   └───resources
│           │       └───de
│           │           └───sepix
│           │               └───demos
│           │                   └───suitedemo
│           └───test
│               └───java
│                   └───de
│                       └───sepix
│                           └───demos
│                               └───suitedemo

Spannender ist, wie die pom.xml erzeugt wurde. Es gibt zum Beispiel kein <parent>-Eintrag für eine übergeordnete Projektdatei. Woher soll auch diese kommen? Der Assistent hat diese nicht abgefragt. Damit tauchen auch Repositories, Dependencies und Properties auf, die für die Zukunft hier nichts mehr zu suchen haben. 

Die pom.xml der Suite hat aber noch einen zusätzlichen <profiles> Abschnitt erhalten:

    <profiles>
        <profile>
            <id>updatesite</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>nbm-maven-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>site</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>autoupdate</goal>
                                </goals>
                                <configuration>
                                    <!-- <distBase>url where your nbm files are located, if not defined within the nbm files</distBase>
                                     -->
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Das Profile mit der Id "updatesite" ist für die Erzeugung der XML-Updatecenter Datei zuständig. 

Wenn man so ein erzeugte Projekt startet, hat man recht schnell die Ernüchterung:

Es startet nichts und im Ausgabefenster findet man folgende Zeilen (Windows):

[nbm:run]
Additional arguments=null
      --userdir
      C:\Entw\Work\svn\4.2\suites\suite-demo\target\userdir
      -J-Dnetbeans.logger.console=true
      -J-ea
Executing: cmd.exe /X /C "C:\Entw\Work\svn\4.2\suites\suite-demo\path-to-associated-netbeans-install\bin\netbeans.exe --userdir C:\Entw\Work\svn\4.2\suites\suite-demo\target\userdir -J-Dnetbeans.logger.console=true -J-ea"
Das System kann den angegebenen Pfad nicht finden.

Nun ja, path-to-associated-netbeans-install sieht nicht wirklich vernünftig aus.

Neben der pom.xml Datei gibt es noch eine profiles.xml Datei, in der sich genau diese Zeichenkette wiederfindet. Das dortige Profil "netbeans-ide" definiert die Eigenschaft <netbeans.installation> mit dem Platzhalter. Das Profil wird in der selben Datei aktiviert.

Mit der Änderung auf die IDE, bekommt man das Projekt zum laufen. Als userdir wird ein Ordner im target der Suite verwendet: ...\suites\suite-demo\target\userdir.

Schaut man in der gestarteten IDE unter Plugins nach, findet man unter "Installiert" auch das "modules-sample NetBeans Module".

Wie sich die Anwendung zusammensetzt findet man im IDE Protokoll heraus:

  Current Directory       = C:\Entw\Work\svn\4.2\suites\suite-demo
  User Directory          = C:\Entw\Work\svn\4.2\suites\suite-demo\target\userdir
  Installation            = C:\Entw\NetBeans69beta\nb
                            C:\Entw\NetBeans69beta\ide
                            C:\Entw\NetBeans69beta\java
                            C:\Entw\NetBeans69beta\apisupport
                            C:\Entw\NetBeans69beta\websvccommon
                            C:\Entw\NetBeans69beta\profiler
                            C:\Entw\NetBeans69beta\harness
                            C:\Entw\Work\svn\4.2\suites\suite-demo\target\netbeans_clusters\foobar
                            C:\Entw\NetBeans69beta\platform

Die neue Suite tanzt mit seinem Ordner deutlich aus der Reihe.

Aber nun muss die Suite endlich mit der echten RCP-Anwendung verknüpft werden. Ausgehend von der vorgegebenen Ordnerstruktur:

├───platforms
│   └───sXbase
├───suites

wird der Pfad relativ auf die RCP Plattform sXbase verbogen (Ausschnitt in der profiles.xml):

           <properties>
               <netbeans.installation>../../platforms/sXbase/application/target/s3</netbeans.installation>
           </properties>

Dabei ist application das Application-Projekt.Der Ordner target ist das erzeugte Build. Und "s3" der brandingToken der Applikation.

Damit ist die Verknüpfung erfolgreich. Mit dem Run der Suite wird nun endlich die passende RCP Applikation gestartet.

Das Protokoll gibt wieder die gewünschten Informationen:

  Current Directory       = C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3
  User Directory          = C:\Entw\Work\svn\4.2\suites\suite-demo\target\userdir
  Installation            = C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3\bin
                            C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3\etc
                            C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3\platform
                            C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3\sxbase
                            C:\Entw\Work\svn\4.2\suites\suite-demo\target\netbeans_clusters\foobar
                            C:\Entw\Work\svn\4.2\platforms\sXbase\application\target\s3\platform

Man müsste nur noch den cluster in der pom.xml der Suite anpassen, damit man foobar los wird.

Außerdem würde ich den <profile> Namen in der profiles.xml der Suite von "netbeans-ide" ändern (auch <activeProfile> anpassen!).

Die pom.xml der Suite muss auch geändert werden. Da die Suite direkt abhängig von der Applikation ist, sollte man auch eine <parent> Verknüpfung durchführen.

Die Mavenkoordinate der Applikation findet sich in seinem pom.xml:

    <groupId>de.sepix</groupId>
    <artifactId>sXbase</artifactId>
    <version>4.2-SNAPSHOT</version>

Diese Koordinate kommt in <parent> Tags eingeschlossen in die pom.xml Datei der Suite:

    <parent>
        <groupId>de.sepix</groupId>
        <artifactId>sXbase</artifactId>
        <version>4.2-SNAPSHOT</version>
    </parent>

Jetzt kann man gefahrlos erst mal <repositories>...</repositories>, <dependencies>...</dependencies> und <properties>...</properties> entfernen.

Sollte das jetzt auszuführende Build nicht klappen, muss man zunächst die RCP Applikation erstellen, weil das lokale Repository kein installiertes pom zur Parent-Koordinate enthält. Ansonsten gibt es keine Schwierigkeiten und Run sollte weiterhin klappen. 

Mit diesen wenigen Handgriffen hat man eine neue Suite der Applikation hinzugefügt. Weitere Schritte wären Lokalisierungen, Updatecenter-URL eintragen (<distBase> in der pom.xml der Suite) und mit dem Update-Center Assistenten im Sample-Modul die URL registrieren.

Beste Grüße,
  Josch.

NetBeans eignet sich als hervorragender Zuspieler des Continous Integration Server Hudson. Insbesondere mit Maven hat man ein kleines nettes Feature mit dem ciManagement Tag in Projektdateien.

  <ciManagement>
    <url>http://companyserver:8080/hudson</url>
  </ciManagement>

Dort kann man nämlich den CI-Server festlegen den NetBeans auswertet und unter der Dienste Ansicht zur Verfügung stellt:

Über die Kontextmenüs  lassen sich einige Dinge abrufen. Über den Serverknoten kann man z.B. die auf den Hudson Server eingerichteten Ansichten auswählen oder auch Builds neu erstellen.

Auf Job-Ebene kann man diesen unmittelbar manuell starten.

Für den individuellen Build erhält man die Konsolenausgabe und auch die Änderungen, die aus der Versionierung ermittelt wurden.

Zu den Modulen kann man sich die Artefakte anschauen und herunterladen.

Mit den zahlreichen Features, kann man Hudson schon recht gut steuern, ohne auf die Weboberfläche wechseln zu müssen.

Beste Grüße,
  Josch.

Schon länger hatte ich mich gefragt, welche Möglichkeiten man bei einem methodvalue Attribut in der layer.xml hat. Ziel ist es ja, dass man einem <attr> Eintrag ein bestimmtes Objekt zuweisen kann und dieses Objekt durch einen Methodenaufruf erzeugt. Man hat also in dieser Methode alle Möglichkeiten das gewünschte Objekt zu beeinflussen. Aber wie muss die [...]

Gegenüber meines alten Blogeintrages zur Lokalisierung von NetBeans RCP Projekten ist es mit Maven sogar einfacher geworden ein Build einzurichten.

Wie auch damals, stehen zur Zeit keine deutschsprachigen Übersetzungen für NetBeans 6.9 RCP Projekte zur Verfügung. Kein Wunder, wir sind auch noch mitten im Development. Gerade mal eine Beta steht zur Zeit zur Verfügung. Übersetzungs-Projekte laufen erst gerade an.

Vorbereitungen

Wer ein Lokalisierungsmodul jetzt nachbauen will, sollte zwei Dinge sofort tun. Erstens die aktuelle Mercurial Version installieren und zweitens die Sprachdateien von hg.netbeans.org herunterladen. Der Mercurial-Download findet sich hier. NetBeans 6.9 dev nach der Installation von hg neu starten, damit der Installations-Pfad von hg gefunden wird. In NetBeans nun ein "Clone other" im Team-Menü/Mercurial ausführen. Das Repository ist hg.netbeans.org/release68/l10n/. User/Password bleibt leer, pull und push Path auf der nächsten Seite bleibt wie vorgeschlagen. Auf der letzten Seite einen passenden Pfad festlegen und den Haken Scan for NetBeans Projects entfernen. [Finish] anklicken und hier weiter lesen, das wird nämlich dauern (ein bis zwei Stunden).

Modul erstellen

Es wird zunächst ein ganz normales Maven based NetBeans RCP Module mit dem New Project Assistenten erzeugt. Da ich in diesem Fall ein Multimodule Projekt einrichte, wo das Sprachmodul direkt in der Platform zur Verfügung stehen soll, ist der beste Ort direkt unter dem Ordner des Maven Platform Projektes.

├───42
│   └───sxbase
│       ├───application
│       ├───branding

In meinem Fall ist sxbase das POM-Projekt (Maven Hauptprojekt für die Platform Applikation). Application ist die Platform-Suite und Branding übernimmt grundlegende Einrichtungen für Splash-Screen, Name der Anwendung, kleinere Lokalisierungen. Aber Branding eignet sich nicht generell für Sprach-Plugins. Besonders wenn man mehrere Sprachen in getrennten Plugins haben will.

Also wird das neue Modul unter sxbase angelegt.

Ich hatte mein deutschsprachiges Übersetzungsplugin i18n-de genannt, sinnvoller wäre vielleicht l10n-de. Aber letztendlich ist das egal, so lange es verstanden wird - und das wird sowieso über die Bundle.properties als Sprachtexte gesteuert.

nbm-branding Plugin

Das neue Modul kann aber so noch keine Bundle-Dateien verarbeiten, wie man es schon vom branding-Modul gewohnt ist. Zunächst muss man ein NetBeans Plugin für den Branding-Build-Prozess in der pom.xml hinterlegen:

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>nbm-maven-plugin</artifactId>
                <extensions>true</extensions>
                <executions>
                    <execution>
                        <id>branding</id>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>branding</goal>
                        </goals>
                        <configuration>
                            <brandingToken>s3</brandingToken>
                        </configuration>
                    </execution>

                </executions>
            </plugin>

Der Branding Token kann ggf. weggelassen werden. Wichtig ist die Angabe der phase und das goal.

Resource Ordner einrichten

Nun braucht man zwingend unter dem src/main Ordner das Verzeichnis nbm-branding. Das macht man in der Files Ansicht (nicht im Project Explorer), öffnet dort den Ordner src/main und legt dort den Folder nbm-branding an.

Darunter benötigt man nun zwei Unterordner core und modules. Im core-Ordner wird das Branding für den Boot-Prozess (Splash usw) angelegt, in modules die Brandings für die Platform-Module.

Die Ordnerstruktur ist dann folgende:

src
├───main
│   └───nbm-branding
│       ├───core
│       ├───modules

Branding-Archive für Bundle-Dateien

Jetzt kommt ein recht ungewöhnlicher Aufbau der Unterordner für das Build der Spracharchive.

Alle Unterordner müssen exakt so heißen, wie die Original-Module, deren Ressourcen wir überschreiben wollen. Der Classloader von NetBeans überdeckt letztendlich die Bundle.properties der Original-Module mit den neuen Sparcharchiven gleichen Namens.

Zwei Beispiele: Im core-Ordner wird ein Unterordner angelegt, der core.jar heißt (mit der Endung .jar!). Im modules-Ordner benötigen wir z.B. org-netbeans-core-windows.jar als Unterordner. In diesen Ordnern müssen aber wieder alle package-Ebenen der Original-Module nachvollzogen werden.

Für core.jar:

core.jar
├───org
│   └───netbeans
│       └───core
│           └───startup

Und beispielsweise für org-netbeans-core-windows.jar:

org-netbeans-core-windows.jar
├───org
│   └───netbeans
│       └───core
│           └───windows
│               ├───actions
│               ├───options
│               ├───persistence
...

Bundles aus dem hg-Clone kopieren

Aber woher bekommt man a) die Namen der Module und b) die Strukturen der Unterordner?

Punkt a durch Raten und Vergleich, Punkt b durch kopieren. Es gibt zwar Java-Ant-Tasks, die aus den XML-Dateien der Platform-Module die Original Ordnerstrukturen ermitteln und damit die Original hg-Sprachdateien zu den Ziel-Archivnamen konvertieren, aber für dieses eine Sprachplugin habe ich die Methode "zu Fuß" durchgeführt. Zum einem, weil bei Maven-Platform Builds die Struktur der Mavenartifakte (und der Nutzung eines Firmenrepository für Platforms) eine direkte Umsetzung der Ant-Tasks nicht erlaubt und zum anderen, weil ich noch kein passendes Mojo fertig habe, dass die hg-Sprachbundles automatisiert kopiert.

Die Namen der platform Module (bitte beachten, NetBeans 6.9 hat keine Nummerierung der Cluster mehr. In NetBeans 6.8 war es noch platform11) finden sich im Installationsverzeichnis von NetBeans /platform/core und /platform/modules. Alle JAR-Dateien darin sind die englischen Versionen (d.h. nicht lokalisierten) Module einer RCP Basis Anwendung. Nun wirft man einen Blick in den hg-Ordner, in dem die Multilanguage Sprachprojekte geclont wurden:

local
├───l10n
│   ├───.hg
│   ├───antsrc
│   ├───l10n_uc_kits
│   └───src
│       └───de
│           └───platform11

Da ich ja ein clone von NetBeans 6.8 vorgenommen habe, heißt es hier platform11.

Einige Unterordner habe schon eine passende tld-package-package-module Bezeichnung ohne die Endung .jar. Andere Ordner heißen nur print oder javahelp. Hier hilft nur "Educated Guess". Die Namen der Ordner aus den hg-Verzeichnissen müssen in die Modulordnernamen mit der Endung .jar umgesetzt werden. Das nächste Problem ist, dass teilweise in den Ordnern der Name des Spracharchiv wiederholt wird oder direkt mit der Packagestruktur begonnen wird. Das ist alles historisches Chaos von falscher Strukturierung.

Was muss also gemacht werden? Nehmen wir ein einfaches Beispiel mit org-netbeans-core-windows.

Struktur in hg:

org-netbeans-core-windows
├───org-netbeans-core-windows
│   └───org
│       └───netbeans
│           └───core
│               └───windows
...

Wir legen in unserem Maven-Projekt den Ordner org-netbeans-core-windows.jar an und kopieren alles ab dem org-Ordner dort hinein. damit haben wir folgende neue Ordnerstruktur:

org-netbeans-core-windows.jar
├───org
│   └───netbeans
│       └───core
│           └───windows
...

Das machen wir mit allen Ordnern, die wir so einfach erkennen können.

Jetzt zu den komplizierteren Fällen. Ein Beispiel im hg:

javahelp
├───javahelp
│   └───org
│       └───netbeans
│           └───modules
│               └───javahelp
...

Wir schauen in das NetBeans69/platform/modules Verzeichnis und finden das JAR org-netbeans-modules-javahelp.jar. Also haben wir den neuen Namen im Projekt:

org-netbeans-modules-javahelp.jar
├───org
│   └───netbeans
│       └───modules
│           └───javahelp
...

Na ja, ich habe für die ganzen Umstellungen 30 Minuten gebraucht. Langweilige Fleißarbeit und fast schlimmer als HTML coden, aber für das erste Beispiel machbar. So weiß man auch, wie man mal ein zukünftiges Mojo schreiben muss.

Folgende Mappings müssen berücksichtigt werden:

Hat man diese gesamten Kopieraktionen erfolgreich durchgeführt, ist das Projekt vollständig, d.h. alle Plattform Übersetzungen wurden so in das Deutschsprachige übersetzt. Die Bundle-Dateien, die aus dem hg-Ordnern kopiert wurden, tragen alle schon das Kennzeichen _de im Namen. Das ist wichtig, damit die Bundles zu den passenden Sprachen geladen werden.

Nun kann man im eigenen Projekt noch Applikationsnamen anpassen, ein paar Rechtschreibfehler korrigieren oder komplett Wörter ändern, um diese einer unternehmensweiten Sprachregelung anzupassen.

Für alle, die sich nicht dir Mühe machen wollen, die Ordner für die Spracharchive aufzubauen, habe ich hier eine kleine ZIP-Datei. Kleinere Teile müssten angepasst werden. Die splash-Grafik fehlt und ###APPLICATION NAME### steht überall dort, wo der Applikationsname eingesetzt werden muss. Außerdem sollte man nach www.example.com suchen und ersetzen (wird im About-Dialog verwendet). Das ZIP-Archiv wird direkt in das src/main Verzeichnis extrahiert. Wer es nutzt kann ja mal ein Kommentar hier hinterlassen, an sonsten ist die Lizenz CDDL und GPL v2 mit Classpath Exception. So wie die Originaldateien.

Beste Grüße,
  Josch.

Ich gebe zu, ich habe nicht damit gerechnet, dass mein “Organize Imports” Plugin so interessant sein könnte, dass man es sogar auf der Startseite von NetBeans als “Featured Plugin” packen könnte. Ok, es ist brauchbar, aber schließlich habe ich nur eine Idee aus einer anderen IDE kopiert. Sei’s drum. Ich freue mich, dass ich auch [...]

Quellcode neigt eigentlich immer dazu mit der Zeit unübersichtlich zu werden. Neue Methoden werden hinzugefügt. Mit viel Glück sogar “sortiert” eingefügt oder zumindest an eine mehr oder minder “sinnvolle” Stelle in der Quelltextdatei. Die meisten IDEs bekommen dies allerdings selten hin. Was aber auch nicht weiter verwundert, da das Programm selten weiß, welche Methoden “logisch” [...]

Dieser erste Teil meiner kleinen Matisse Serie soll sich einfach nur damit beschäftigen, wie man den GUI Builder aufruft und welchen Quellcode wir von dem Tool generiert bekommen. Aber zunächst einmal die Frage nach dem “Warum”. Warum soll ich einem Tool meinen Sourcecode erzeugen lassen – der wenig übersichtlich ist – wenn ich doch selber [...]

Ich werde immer mehr abhängig von dem kleinen Suchfeld oben rechts in meinem Firefox. Kleine so genannte “Search Plugins” die mir direkt die Suche einer bestimmten Website aufruft mit den Begriffen, die ich im Browser eingegeben habe. Eine Suche ohne vorher die Site selbst aufzurufen. Ein wichtiges Werkzeug der letzten Zeit ist die Suche auf [...]

Ich habe ein kleines Update von meinem Organize Import Modul in das NetBeans Plugin Portal hochgeladen. Es sind nur kleine Änderungen passiert. Eine NPE, wenn man eine leere Liste in den Optionen zurück läßt wurde beseitigt und ich hatte vergessen ein paar Texte ins Englische zu übersetzen. Die größte Änderung ist, dass das Modul jetzt [...]

Die NetBeans IDE hat ein nettes und äußerst Hilfreiches Feature um eigene Benutzeroberflächen zu gestalten. Fast ohne sich um irgendwelche LayoutManager und deren sinnvolle Verschachtelung zu kümmern lassen sich mit dem “Matisse GUI Builder” auch komplexe Eingabemasken erstellen und bearbeiten. Aber so schön sich das im ersten Moment anhört, so kompliziert wird es, wenn man [...]

Geertjan hat in seinem Blog einem kurzen Artikel darüber geschrieben, wie man eine sogenannte “Capability” dynamisch in ein eigenes Node einbaut. Er nutzt dazu die Klasse InstanceContent über die dynamisch ein Lookup verändert werden kann. Bisher haben wir das bei uns immer über das CookieSet des DataObjects gemacht. Die “Cookies” (welches eine frühe Implementierung von [...]

Es gibt im aktuellem Dev-Build einige kleinere Probleme mit der Artifact-Beschreibung, die in den Modul-Properties eingestellt werden können.

Zeilenumbrüche in Artifact Beschreibungen

Der erste (und massivere) Fehler ist, dass bei Eingaben mit Zeilenumbrüchen, die man per [Enter] eingegeben hat, es zu einem Build Fehler kommt. Der Text der Artifact-Beschreibung geht nämlich unmittelbar in die manifest.mf Datei des NBM ein. Und durch einen Fehler wird der Zeilenumbruch mit übertragen. Der Fehlerreport wurde hier unter Issue 184137 angelegt. 

Wenn man also so einen (oder ähnlichen) Fehler bekommt:

[ERROR]Manifest is invalid: Manifest line "Line 2" is not valid as it does not
contain a name and a value separated by ': ' 
------------------------------------------------------------------------
[ERROR]BUILD ERROR
------------------------------------------------------------------------

Dann hat man mit hoher Wahrscheinlichkeit das beschriebene Problem (wobei "Line 2" natürlich ein Fragment der Beschreibungseingabe ist).

Man sollte z.Z. also keine Zeilenumbrüche verwenden.

Sonderzeichen in Beschreibungen

Ein weiteres Problem sind Sonderzeichen in der Beschreibung. Da kommt es ebenfalls zu einem Fehler des nbm-maven Builders. So wie es sich darstellt, wird als Encoding nicht das (nach Spezifikation) erforderliche UTF-8, sondern UTF-16 verwendet. Der Fehlerreport findet sich hier #184135.

Das Build läuft durch und auch der Modul-Loader hat damit keine Probleme, aber die Anzeige im Plugin-Manager ist entsprechend kaputt. Umlaute und Sonderzeichen werden als Glyphensalat dargestellt.

Um das zu verhindern, sollte man in der Projektbeschreibung auf Sonderzeichen verzichten. Oder gleich die Beschreibungen lokalisier

Lokalisierung der Modulbeschreibung

Das ist keine Besonderheit der Maven Builds und ist im Prinzip immer der richtige Weg, um Module mit einer Beschreibung zu versehen.

Es empfiehlt sich in den Projekteigenschaften die Artifact-Beschreibung zunächst sehr kurz und in Englisch zu halten.

Das Branding der Modulbeschreibung erfolgt dann unter Other Sources des Moduls. Dort befindet sich schon der "Bereich" src/main/resources, der in Maven Projekten der übliche Ort für Ressourcen ist.

Darunter legt man (wenn es noch nicht existiert) ein Package mit dem Namen des Modul-Packages an (z.B. org.sepix.mymodule). Darunter wird eine Bundle.properties und für unseren Sprachraum eine Bundle_de.properties Datei angelegt.

Meistens existiert das Paket und die Bundle.properties schon an passender Stelle, weil dort beim Erzeugen des Moduls (per Assistent), die Plugin-Kategorie hinterlegt wird:

OpenIDE-Module-Display-Category=foobar

Schon foobar sollte man ändern ;-)

Zwei weitere Schlüssel kann man hinzufügen:

OpenIDE-Module-Short-Description=Kurzbeschreibung
OpenIDE-Module-Long-Description=Eine überlange Beschreibung zu dem Modul

Dort darf man Umlaute und andere Sonderzeichen verwenden. Zeilenumbrüche werden mit \n gekennzeichnet.

Wenn man aber mit der rechten Maustaste auf Bundle.properties klickt und "Open" im Kontextmenü auswählt, wird auch ein Bundle-Editor geöffnet. Dort kann man etwas komfortabler (über alle Sprachversionen) die Einträge der Bundle-Datei anpassen.

Beste Grüße,
  Josch.

Moin!

Hier ein paar (ausgesuchte) Links für die Entwicklung mit Maven 2 in NetBeans.

NetBeans.org Links

• RCP Entwicklung mit Maven Builds in NetBeans 6.8
• NetBeans Platform Development mit Maven 2 (NetBeans Magazine)
• Maven Best Practice in NetBeans 6.x
• Maven Dependencies Screencast
• Maven Plan für NetBeans 6.8
• Maven Plan für NetBeans 6.9

NetBeans Maven Plugins

• NBM Maven Plugin
• JIRA für das NBM Maven Plugin

Blogs

• 10 Steps to start a Maven project
• Working with Maven in NetBeans 6.7.1
• NetBeans und Maven (mein Blog)

Ich möchte die Liste gerne erweitern. Wer Infos hat, darf sie mir gerne mitteilen. Danke und beste Grüße,
  Josch.

Nachdem man das erste Application Projekt erstellt hat, fallen einem viele Kleinigkeiten auf, die Unschön sind.

Besonders die Label, Icons und Namen der ausführbaren Dateien stören mit "komischen Platzhaltern"

Foo und Foobar

Der Wizard lässt einige Einstellungen vermissen. Es kann noch ein Problem des 6.9'er Dev Builds sein, aber foo und foobar für Clusternamen, Branding Tokens und Name der ausführbaren Startdatei (Executable) sind doch nicht wirklich schön.

Angepasst werden diese Namen im pom.xml des Maven Projektes.

Ganz am Ende der pom.xml findet sich:

    <properties>
        <netbeans.version>SNAPSHOT</netbeans.version>
        <brandingToken>foo</brandingToken>
    </properties>

Das Brandingtoken kann man in einen gewünschten Namen (ohne Leerzeichen) ändern.

Ich nehme mal "s3" (ein Applikationsname in meinem Unternehmen). Tipp: Keine Bindestriche im Branding-Token verwenden, ansonsten startet unter Windows die Applikation nicht!

Mit einem Clean & Build wird im target-Ordner nun ein s3-Ordner angelegt und darunter im bin-Ordner findest sich nun s3.exe. Man sieht also, dass sich das Branding-Token auf den Applikationsnamen auswirkt.

Unter dem s3-Ordner liegt aber noch ein foobar-Ordner. Das ist ein Clusterordner, in dem die Module der Applikation zusammengefasst sind. Auch foobar ist ein recht unnützer Name.

Geändert wird das in der selben pom.xml weiter oben:

<configuration>
   <brandingToken>${brandingToken}</brandingToken>
   <cluster>foobar</cluster>
   <useOSGiDependencies>true</useOSGiDependencies>
</configuration>

Auch der Clustername sollte keine Leerzeichen enthalten. Nicht mal Bindestriche oder Punkte. Ich wähle sxbase als Clustername.

Nach einem Clean & Build findet sich nun im sxbase-demo/application Ordner folgende zufrieden stellende Ordnerstruktur:

sxbase-demo/application:
│   └───target
│       └───s3
│           ├───bin
│           ├───etc
│           ├───platform
│           │   ├───config
│           │   │   ├───ModuleAutoDeps
│           │   │   └───Modules
│           │   ├───core
│           │   ├───docs
│           │   ├───lib
│           │   ├───modules
│           │   │   └───ext
│           │   └───update_tracking
│           └───sxbase
│               ├───config
│               │   └───Modules
│               ├───core
│               │   └───locale
│               ├───modules
│               │   └───locale
│               └───update_tracking

Der Clustername findet sich auch im branding Ordner wieder:

└───branding
[...]
    └───target
[...]
        ├───maven-archiver
        └───nbm
            └───netbeans
                └───sxbase
                    ├───config
                    │   └───Modules
                    ├───core
                    │   └───locale
                    ├───modules
                    │   └───locale
                    └───update_tracking

Damit hat man schon mal zwei unschöne Namen korrigiert.

Branding der Texte

Das weitere Branding der Texte wird nicht im Maven-Parent-Projekt sondern im Branding Modul durchgeführt. Zwar kann man einiges in dem Kontext-Menü aufgerufenen Branding... Assistenten durchführen, aber ein Streifzug durch die Bundle.properties kann nicht schaden.

Folgende Ansicht, zeigt den Other Sources Zweig des Branding-Moduls:

Die drei Bundle-Dateien unter core.jar, org-netbeans-core-windows.jar und org-netbeans-core.jar werden durch den Branding-Assistenten gespeist. Insbesondere den Application Title verteilt der Branding-Assisten über die drei Bundle-Dateien. core.jar/**/Bundle.properties bekommt currentVersion und LBL_splash_window_title gefüllt. In org-netbeans-core-windows.jar/**/Bundle.properties werden CTL_MainWindow_Title und CTL_MainWindow_Title_No_Project gefüllt. Die Datei org-netbeans-core.jar/**/Bundle.properties nimmt das Label für LBL_ProductInformation auf. Alle gefüllt durch ein Textfeld.

Möchte man das individuell steuern, kann man die Werte in den Bundle-Dateien von Hand anpassen. Man darf dann aber nicht mehr den Menüpunkt Brandings... im Kontextmenü aufrufen. Schade, wenn man darüber nachträglich den Spashscreen anpassen will.

Tragen wir mal den Text "My Test Application" ein:

Dann ergibt sich folgendes Bild in den Bundle.properties:

Um die Auswirkung testen zu könne, muss man ein Clean & Build machen, danach Run:

Anpassung der Icons

Leider ist es z.Z. möglich über den Branding-Assistenten nur die Icons für die Oberfläche zu ändern. Das Executable-Icon für Windows ändert sich dabei nicht. Eine FAQ existiert für das Problem.

Anpassung des Splash Screens

Die Änderung des Splash Screens erfolgt so, wie man es in älteren Versionen gewohnt war. Nur nun über den Branding-Assistenten und nicht mehr über die Project Properties des Kontextmenüs.

Anpassungen zum Übersetzen und weitere Branding-Einstellungen werde ich im nächsten Teil beschreiben.

Beste Grüße,
  Josch.

Ich bin gerade dabei meine Platform Projekte auf das Maven Build System umzustellen. Damit die Sache noch ein wenig spannender wird, das auch noch mit dem NetBeans 6.9 Dev Build (genauer Build 201004120251).

Grundsätzlich will ich für die Umstellung der einzelnen Bestandteile (Application, Suites und Modules) die Projekte komplett neu aufbauen, damit ich keine Altlasten meiner Ant-Builds habe und die Abhängigkeiten sauber aufgelöst sind.

Dies wird der erste Teil einer lockeren Reihe von Tutorials, wie man solche Builds aufbaut, inkl. meiner Fehlschläge und Erkenntniss

Application Projekt erzeugen

Zunächst baue ich mir ein Application Build auf. Der Wizard für neuen Projekte ist in 6.9 etwas anders als in 6.8. Bisher musste man zunächst ein Maven Projekt aussuchen, um dann im zweiten Schritt ein Platform Template zu wählen. Die NetBeans Maven Projekte sind inzwischen auf die erste Seite des Assistenten gerutscht, allerdings weiterhin unter der Kategorie Maven.

Man wählt im "New Project" Assistenten also als erstes "Maven NetBeans Application" auf. Auf der nächsten Seite wählt man einen Projektnamen. Dieser Name wird an vielen Stellen im Branding verwendet. Also auch für die Titelleiste des Hauptfensters. Da man als Projektnamen keine Leerzeichen verwenden darf, nehme ich sowieso immer kurze Bezeichnungen, muss dann aber überall wieder das Branding anpassen. Als Trenner im Namen darf man auch Bindestriche verwenden (z.B. sXbase-demo).

Als Project Location empfiehlt sich ein Ordner, der speziell alle Platforms aufnehmen soll. Ich spiele gerne mit verschiedenen Platform-Builds. Diese an einer Stelle wiederzufinden ist sinnvoll.

Group-Id ist üblicherweise ein Domain-Name wie man das von package Beschreibungen gewohnt ist, z.B. de.sepix wäre in meinem Fall eine passende Group-Id.

Als Version wird 1.0-SNAPSHOT vorgegeben, das lasse ich so. Das Package wird aus der Group-ID und dem Projektnamen (ohne Bindestriche) zusammengesetzt.

Die nächste Registerzunge erlaubt nun mit 6.9 OSGi Bundles als Abhängigkeiten zu binden. Ich setze da meinen Haken, weil ich das gerne in Zukunft probieren möchte.

Mit Finish werden nun drei einzelne Projekte erzeugt (ein Maven Projekt, eine Application Suite mit orangem Puzzel-Icon und ein Modul Projekt für das Branding, das ein violettes Puzzel-Icon trägt).

Das dauert auch relativ lange, wenn man das zum ersten Mal gemacht hat. Zum Teil wird nämlich das lokale Maven Repository aufgebaut (es findet sich im Homeverzeichnis unter ~/.m2). Auch wenn der Wizard sich beendet, werden im Hintergrund (über die Progessbar in der Statuszeile zu sehen) Quelltexte und Dokumentation aus öffentlichen Repositories heruntergeladen.

Der erste Build

Ist das alles erfolgreich abgeschlossen (und die Voraussetzung ist natürlich eine Internetverbindung), kann man mal einen Build des Maven-Hauptprojektes versuchen (sic!).

Macht man das wirklich zum ersten Mal, wird das Build nicht klappen. Man kann es auch den einzelnen Projekten ansehen (die Symbole haben ein Warndreieck), dass es Probleme gibt.

Eine Abhängigkeit für das Branding-Modul konnte nicht geladen werden. Das Modul org-opende-util-SNAPSHOT.jar wird nicht erzeugt, weil die zugrunde liegende Datei nicht aus den NetBeans Repository geladen wurde (ggf. hat man schon CRC-Fehler im Output-Fenster gesehen). Das Problem kann gelöst werden, in dem man (nicht wie vorgeschlagen) aus dem Kontextmenü "Resolve Dependency Problems" aufruft.

Auch die Fehlermeldung mit dem Hilfshinweis im Build, die Datei manuell zu laden und zu installieren, sollte man erst gar nicht anfangen. Es reicht einfach das Branding-Modul als Erstes zu erzeugen (rechte Maustaste auf das Projekt -> Build), dann einen Build mit der Suite (NetBeans Platform based application) und zum Schluss ein Build mit dem Maven Projekt.

In Zukunft wird das hoffentlich nicht mehr notwendig sein. Ein Bugreport gibt es bereits dazu. Aber ich musste ja mit dem Dev-Build spielen.

Run

Jetzt endlich kann man die Applikation per Run (übrigens vom Suite Projekt, NetBeans platform based application) aus dem Kontextmenü starten. Oder man setzt das Suite-Projekt als Main-Projekt und kann dann den Toolbar-Button (der grüne Play Pfeil) nutzen.

Ohne angepasstes Branding sieht es noch etwas Mau aus, aber die erste Application basierend auf der NetBeans Platform per Maven Build ist fertig, und keine Zeile XML oder Java programmiert.

Im nächsten Teil gehe ich ein wenig auf das Branding ein.

Beste Grüße,
  Josch.

Gleich zu Beginn dieses neuen Blogs muss ich einmal ein bischen angeben. Seit gestern bin ich ein “NetBeans Certified Engineer“. Eingebracht hat mir das eigentlich nur die Tatsache, dass ich immernoch dem Java Editor von Eclipse nach trauere. Auch wenn die NetBeans Platform an sich recht nett ist und ich mittlerweile auch die NetBeans IDE ganz [...]

Es wurde ja schon länger vermutet, dass James Gosling nicht sehr lange bei Oracle bleiben wird. Nun ist es aber schon seit dem 2. April geschehen. James hat Oracle verlassen. In seinem neuen Blog hat er es offiziell gemacht.

James schreibt weiterhin, dass er auch in St. Petersburg nicht bei den TechDays dabei sein kann.

Eine neue Firma für seine Schaffenskraft gibt es noch nicht, er will sich etwas Zeit nehmen, eine Entscheidung zu finden.

Ich wünsche James Gosling alles Gute und hoffe, dass er uns in Zukunft mit seinen Ideen zur Seite stehen wird.

Beste Grüße,
  Josch.

Moin!

Mir ist es schon ein paar mal passiert, andere Entwickler stolpern auch ständig darüber.

Da hat man alles ganz sauber programmiert, nichts vergessen und doch wollen die Nodes in NetBeans nicht das tun, was sie sollen.

Der klassische Aufbau einer TopComponent mit BeanTreeView, ExplorerManager.Provider und associateLookup ist immer ein wenig Bastelei und verursacht schon so unnötige Tippfehler. Hat man alles zusammen (und es funktioniert) klappt es auch mit der Kopplung der weiteren Features in der RCP Anwendung. Magischerweise zeigt das Eigenschaftsfenster die Properties des Nodes, Kontextmenüs zeigen die gewünschten Actions und Toolbar-Buttons reagieren exakt wie gewünscht.

Aber manchmal will das alles nicht klappen. In voller Überzeugung alles richtig gemacht zu haben, stellt man fest, dass die selektierten Nodes im BeanTreeView eben nicht im globalen Lookup auftauchen. Und wenn die Nodes das nicht tun, dann können alle anderen Module der Plattform die Nodes auch nicht sehen. Und was man nicht sieht, kann man nicht unterstützen.

Dieses "Sichtbarmachen" oder das bekannt machen der aktuellen Auswahl erledigt der ExplorerManager. Er verwaltet das Selection Management. Das Node-View sucht sich normalerweise den passenden ExplorerManager über die Swing-Hierarchie. In einer TopComponent muss man dafür nur das Interface ExplorerManager.Provider implementieren und in der Methode getExplorerManager eine Instanz zurückgeben. Innerhalb der TopComponent wird aus dieser ExplorerManager-Instanz das Lookup geholt und mit der Methode associateLookup an das globale Selection-Management gekoppelt (siehe auch meinen Artikel von 2008)

Nur durch diesen Weg ist es möglich ohne direkte Abhängigkeiten das View auszutauschen. Aber dieser Automatismus: der Suche nach der passenden Komponente, die ExplorerManager.Provider implementiert, hat so seine Tücken. Denn syntaktisch (und selten semantisch) ist es ohne Probleme möglich jeder Klasse, beliebigen Access Modifier zum trotz, Interfaces anzuhängen. Und da kommen wir schon zum Problem und zur Lösung.

Manchmal passiert es schlicht und einfach, dass man den Access Modifier public für die Swing-Komponente vergessen hat. Also

class MyWindow extends TopComponent implements ExplorerManager.Provider

Die TopComponent kann so ohne Probleme funktionieren, aber die View Komponenten in der TopComponent haben gar kein Zugriff auf das Interface ExplorerManager.Provider - es ist der API unsichtbar. Damit wird der gesamte Mechanismus der Entkopplung ausgehebelt. Die Nodes werden im View angezeigt, aber alle anderen erweiterten Funktionalitäten stehen einem nicht zur Verfügung. Keine Anzeige im Property-Window, keine funktionierenden NodeActions, usw. usf.

Man sollte also immer darauf achten, dass man bei Implementation von Interfaces die der Modulkommunikation dienen, auch immer die Klasse öffentlich sichtbar macht. Ansonsten bekommt man recht unbefriedigende Ergebnisse.

Beste Grüße,
  Josch.

In meinem letzten Interview auf JAXenter wurde ich gefragt wie es mit der Integration einer Modell getriebenen Softwareentwicklung in der NetBeans IDE steht.

Zwar besitzt NetBeans mit MDR ein Framework, es wird aber schon seit einiger Zeit nicht mehr weiterentwickelt.

Auch halte ich es für unwahrscheinlich, dass Oracle nach der Übernahme selbst eine MDA-Technologie in NetBeans integrieren wird, wenn so etwas schon in den JDeveloper Tools zur Verfügung steht.

Trotzdem hielt ich die Zukunft für MDA Tools in NetBeans für nicht ganz ausgeschlossen. Schließlich öffnet sich NetBeans immer mehr anderen Frameworks und Modulsystemen (z.B. OSGi). So gab ich als Antwort, dass ich davon ausgehe, dass in Zukunft eine Integration des EMF von Eclipse in NetBeans machbar wäre.

Tatsächlich wurde das schon von einem Entwicklerteam aus Norwegen der Firma Exie umgesetzt. In deren internen RCP Anwendungen wurde das EMF integriert. Ein Beispiel, wie das in NetBeans umzusetzen ist, wird heute als OpenSource vorgestellt. Das Projekt wird unter der BSD Lizenz auf java.net gehostet. Bis das Projekt aktiviert ist, findet man den Quelltext unter diesem Link.

Eclipse Anwender werden sich fragen, warum man das UI des EMF unter einer anderen Plattform erneut programmieren will. Zunächst verwendet Exie das EMF in einer RCP Anwendung basierend auf der NetBeans Plattform. Da wurde also schon das NetBeans Platform Framework dem Eclipse RCP Framework vorgezogen. Außerdem finde ich es reizvoll ein neues UI für EMF in dem intuitiv zu bedienendem NetBeans Ökosystem der Entwicklungsumgebung zu integrieren. Das UI aus Eclipse kann man nicht übernehmen, da SWT unter Swing nur mit schweren Bauchschmerzen zum laufen zu bringen ist (schon SWT allein ist nicht trivial).

Einen englischsprachigen Beitrag zu dem Thema findet sich auf dzone.

So bin ich gespannt, was die Zukunft für dieses Projekt bringen wird.

Beste Grüße,
  Josch.

Nach nur 1 1/2 Tagen haben wir unser NetBeans Platform Certified Training in Weihenstephan (FH, Fachbereich Bioinformatik) abgeschlossen. 

Normalerweise dauert das Training 2-3 Tage. Wir haben es diesmal (trotz meiner Überziehungen) geschafft alle erforderlichen Themen in das Training zu packen.

Danke auch an die Studenten, die an ihren ersten Tagen zum neuen Semester so konzentriert mitgemacht haben!

Hier ein paar Bilder zu unserem Training.

Natürlich wurde auch gemütlich zusammen gesessen. In der berühmten Brauerei Weihenstephan:

:

Zum Schluss das obligatorische Gruppenfoto.

Natürlich kommen wir das nächste Jahr zu einem neuen Training an die Fachhochschule Weihenstephan.

Beste Grüße,
  Josch.

Wie ich gestern in einer Mail lesen konnte, wird tatsächlich an einer Migration von kenai.com nach java.net gearbeitet. 

Work is on-going for migrating the Java.net domain over to the Kenai infrastructure and we will move the existing Kenai.com projects over to the Java.net domain as soon as we have everything in place.

Nur bittet das Projekt Team um etwas Geduld, weil der Prozess wohl aufwändig ist.

The work will take a bit of time to complete, so please feel comfortable using Project Kenai while we work towards the final move to Java.net.

Im Netz gibt es zwar viele Stimmen trotzdem kenai.com zu verlassen, damit man sich der Abhängigkeit eines kommerziellen Anbieters wie Oracle entzieht, aber nüchtern betrachtet kann dies einem mit jedem Hoster passieren.

Trotz der ursprünglichen (schockierenden) Informationspolitik scheint sich Oracle doch eines besseren besinnt zu haben. Damit hat man hier schon einen Ansatz von Sicherheit, was die Beständigkeit von java.net haben wird.

Ich werde der Migration zu java.net eine Chance geben. Wohl aus einem (eventuellen trügerischen) Sicherheitsgefühl, dass java.net für eine lange Zeit ein gutes Heim sein wird, vielleicht auch aus Bequemlichkeit ;-)

Beste Grüße,
  Josch.

Wenn man Java Projekte hat, die Bibliotheken aus einem Maven Projekt benötigen, steht man zunächst auf dem Schlauch.

Das simple "Add Project..." eines Maven Projektes zu einem NetBeans Java Projekt wird zwar angeboten, funktioniert aber nicht. Es werden keine JAR-Dateien gefunden und eingebunden. Die Problematik liegt vermutlich daran, dass die abhängigen Bibliotheken eines Maven Projektes in einem lokalem Repository zwischengespeichert sind (%homepath%/.m2/repository/ ...).

Wie bekommt man aber alle Dependencies mit einem Schlag in eine herkömmliches Java Projekt?

Etwas versteckt aber letztendlich einfacher als gedacht. Man öffnet per rechtem Mausklick das Kontextmenü des Maven-Projektes und führt "Show Dependency Graph" aus.

Im Graph-View kann man sich die Abhängigkeiten veranschaulichen (und sogar Konflikte korrigieren).

Im Classpath View kommt nun die eigentliche Funktion zu tragen. Der Toolbar-Button "Create Library" rettet vor viel Arbeit:

Nur noch im Dialog einen Namen vergeben und per [Ok] die Bibliothek erzeugen.

Im Library Manager wird dann die Bibliothek mit den Archiven angezeigt, wenn alle abhängigen JARs heruntergeladen wurden.

Nun kann man diese Bibliothek dem eigenen Projekt hinzufügen.

Beste Grüße,
  Josch.

Moin!

Aktuell hatte ich CalDav4j als SVN Snapshot heruntergeladen und musste mal wieder feststellen, wie gut die Maven-Integration in NetBeans inzwischen ist.

Ein schlichtes checkout mit anschließendem Öffnen des Projektes - Build - und alle Dependencies werden sauber geladen.

Wenn nur das aktuelle Snapshot des Google Projektes nur so sauber wäre ;-)

Die Test Ressourcen sind teilweise unvollständig, es fehlt auch eine Klasse komplett und einige Testparameter funktionieren schlicht und einfach nicht, weil Server und Berechtigungen fehlen. Nun will ich nicht alles an Tests löschen, sondern nur mal schnell ein JAR erzeugen, um das 0.6'er Snapshot ersatzweise für die ältere 0.5'er Version in meine Projekte integrieren. Aber ohne erfolgreichen Test kein JAR, weil das "Build failed" mir einen Strich durch die Rechnung macht.

Maven hat aber eine Option, zum Deaktivieren der Tests. Und diese lässt sich sehr einfach in dem NetBeans Projekt setzen. Die Projekteigenschaften öffnen, in den Abschnitt Actions wechseln, "Build project" auswählen und in den "Set Properties" folgende Zeile einfügen:

maven.test.skip=true

Das war es auch schon. Nun wird das JAR erzeugt, die Tests werden ignoriert.

Beste Grüße,
  Josch.

Besonders ein Blogeintrag zeigt mir in den letzten Tagen, wie sehr NetBeans als PHP IDE inzwischen geschätzt wird.

Die Kommentare auf Nikita Makeyevs Artikel sind überwiegend positiv, was den Einsatz mit NetBeans für PHP betrifft.

Nikita hebt hervor, wie gut die IDE zu konfigurieren ist.

One of the best things about this IDE is its UI.  All of the toolbars can be docked, closed or minimized depending on your display preferences.  Minimized toolbars will helpfully spring open when you mouse over them and hide again once you click off of them.

Nicht verwunderlich, wenn das vorherige Tool der Wahl das Programm TextPad gewesen ist. Aber gerade für PHP Anwender ist die Suche nach einer passenden IDE wohl eine Sisyphos Arbeit:

gollyg:

I have been using Aptana for about 2 years. Recently they announced that they were dropping development support for their PHP plugin and were going to use pdt instead. The sudden nature of this decision, along with some of the ‘Aptana Cloud’ marketing integration into the interface, left me feeling far less love for Aptana. After increasingly regular program freezes I decided to give Netbeans a try.

Stuart Laverick:

I’ve been using Netbeans since about 6.2 after I moved over from Aptana. As I run 64bit Linux as a desktop, I am precluded from using some IDE’s [...]

Christian Zumbrunnen:

I made the switch from Aptana and I’m pretty impressed.

Gordon:

Zend is a great IDE, but it is super expensive when you consider Netbeans has more functionality (ever so slightly slower, but unnoticeable on a 4GB Dual Core Windows Vista Laptop), and arguably still better code completion(as you can write custom rules, to personalise the code-completion responds).

Die Performance wurde von Nikita als gut bezeichnet mit Abzüge in der B-Note. Die IDE braucht relativ viel Arbeitsspeicher. NetBeans ist da aber nicht alleine und macht wohl seinen Job am besten, wenn man sich die anderen Kommentare betrachtet.

Colin McCormick:

I’ve been using Netbeans as my main IDE for 3/4 years now. I find it a pretty decent IDE. Yes it can be a little slow at times, but it’s certainly faster than its main competitor, Eclipse, which is slow regardless of the OS it’s running on.

Nacereddine:

I was using Komodo IDE for my websites even it’s slow as hell, and crashes all the time, [...]

Den abschließenden Worten von Nikita ist nichts hinzuzufügen:

Even if you’re pretty happy with your current IDE, give NetBeans a try because as a good developer you should never stop trying out new things and looking for tools that make you better at what you do; and hey, let’s face it, at the incredible price of $0 it’s truly a crime to pass up such a great product that has pretty much everything you will ever need.

Beste Grüße,
  Josch.

(hier ein Update zu meinem letzten Blog-Eintrag vor meinem Urlaub)

Das die Informationspolitik nicht ideal sei, gibt das kenai-Team selbst in einer kurzen Mitteilung zu.

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you.

Aber was das Team zu melden hat, ist dann doch positiver, als es sich in Vergangenheit las.

Kenai.com als Domain wird wohl tatsächlich nicht mehr bestehen bleiben. Eine Migration nach java.net wird empfohlen. Aber der Grund, warum java.net statt kenai.com genutzt werden soll ist neu:

We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net.

Somit gibt Ted Farrell eine beruhigende Meldung aus:

So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.

Ich bin gespannt was Ende diesen Monats für Infos kommen. Vielleicht werden ja die Projekte automatisch nach java.net migriert.

Beste Grüße,
  Josch.

Es scheint im Moment unausweichlich zu sein, dass kenai.com abgeschaltet wird. Damit fällt ein nützlicher Dienst unter den Hammer. Besonders schmerzlich ist das, weil gerade mit NetBeans eine relativ einfache Integration möglich ist (bald war).

Oracle spricht davon, dass kenai.com intern weiter genutzt werden soll. Nicht verwunderlich. Die Site netbeans.org ist darauf umgestellt worden und keiner will davon wohl wieder weg. Auch andere Projekte, beispielsweise odftoolkit.org, basieren auf dem Kenai Projekt.

Die Überlegung von Oracle war einfach, dass der größere Fokus auf Community basierte Projekte gelegt werden soll. Die Plattform java.net ist eindeutig näher an der Community. Wobei kenai.org eher das Hosting für Inselprojekte und (später) kommerzielle Projekte sein sollte.

Ob aber in näherer Zukunft java.net tatsächlich auf Kenai basieren soll, halte ich im Moment für ausgeschlossen. Diese Umstellung erscheint mir unter aktuellen Gesichtspunkten einfach zu aufwändig.

Nun stellt sich die Frage nach Alternativen.

Da gäbe es natürlich java.net selbst. Mir erschien aber bisher die Struktur zu unflexibel, ist aber nur eine persönliche Präferenz. Weiterhin gäbe es noch Google Code - der Dienst bietet auch Mercurial als Versioning System.

Viele Projektbesitzer liebäugeln mit http://github.com/. Die git-Integration in NetBeans wäre tatsächlich möglich. Es gibt ein Plugin dafür. 

Auch sieht JavaForge gar nicht so schlecht aus (ebenfalls Mercurial). Der Dienst ist in einer Cloud implementiert und bietet als Highlight ein ALM Plugin für NetBeans an. Ich konnte das Plugin aber leider unter 6.8 noch nicht testen.

Einen Vergleich weiterer Dienste findet sich hier und auch auf Wikipedia.

Eine Empfehlung kann ich kaum geben. Ich werde zunächst javaforge ausprobieren (entgegen des Namens ist es nicht ausschließlich für Java Projekte gedacht). Ich finde es nur sehr ärgerlich, dass es z.Z. keinen Zeitplan gibt, wann kenai.com verschwindet, bzw. wie lange man noch auf die Projekte (zumindest read only) zugreifen kann.

Beste Grüße,
  Josch.

Nun ist es raus, in den nächsten 100 Tagen wird Oracle die Strategie mit den Java-Tools neu aufbauen. Allerdings gibt es jetzt schon eine Richtung wohin es gehen wird.

Hier ein paar Slides und Fotos aus einem Podcast von Ted Farell (Chief Architect of Oracle Tools and Middleware), die die Strategie von Oracle verdeutlichen sollen.

Ted Farrel spricht von einem Oracle Stack. Java Development aus der Midleware ist ist ein primärer Bereich worüber er spricht.

Besonders spannend ist, wie Oracle mit den drei großen IDEs umgehen will.

Ted Farell spricht im Video eindeutig darüber, dass die NetBeans IDE die primäre Plattform für Java Development wird. Darunter fällt JavaME, JavaSE, JavaEE und auch JavaFX sowie alle aktuellen Scripting Sprachen auf der Java VM.

Eclipse wird weiterhin von Oracle als Partner und Mitglied unterstützt.

Auch JDeveloper behält seinen Platz im Oracle Portfolio. JDeveloper wird in Zukunft (und im Prinzip wie bisher) die komplette Middleware der Oracle Tools übernehmen. 

Die Unterscheidung zwischen NetBeans und JDeveloper divergiert dann in den beiden Attributen: Lightweight Java Development für NetBeans und Heavyweight Java Development für JDeveloper. 

Nichts desto trotz werden alle drei IDEs gleichberechtigt von Oracle als IDE angeboten und unterstützt. Besonders zwischen NetBeans und Eclipse wird es wohl weiterhin Überschneidungen geben. Aber das ist so gewollt, weil es nicht zu übersehen ist, dass die Entwickler weltweit doch in Zukunft zwei "Lager" bleiben werden. Ich denke das ist auch ganz gut so, denn nur wo Konkurrenz existiert bleibt die Entwicklung nicht stehen.

Die CDDL für die NetBeans IDE (und Platform) wird in zukünftigen Versionen wohl weiter existieren. Sie wird mit mit einer flexibleren Policy von Oracle erweitert. Wie erwartet bleibt GPLv2 mit classpath exception. Das bedeutet eine Sicherheit in der Entwicklung von Rich Client Platform Anwendungen auf freier und kommerzieller Basis.

kenai.com wird als Hosting Project wohl nicht mehr bestehen bleiben. Oracle will kenai.com intern weiterverwenden. Das wäre ein herber Verlust für die NetBeans Integration. IMHO ein Punkt, wo die Community unbedingt intervenieren sollte, damit Oracle diesen Dienst bestehen lässt.

Ein wirklich schöne Neuigkeit ist, dass die JavaONE bleibt und sogar auf weitere Länder ausgeweitet werden soll.

Ich vermisse nur ein Land in Europa.

Ich denke damit haben wir insgesamt sehr gute Neuigkeiten von Oracle erhalten. Nach den sehr stillen Tagen ohne das kleinste Commit zur NetBeans IDE und Platform ist das eine fantastische Aussage.

Beste Grüße,
  Josch

RCP Anwendungen im Unternehmenseinsatz benötigen meistens eine Updatepolitik, die mit dem Standard Autoupdatecenter nicht optimal abgebildet wird. Über das, von der NetBeans Platform gebotene, AutoUpdate Center wird vom Anwendern einiges an Konfiguration und manuellen Eingriffen erwartet, was häufig nicht gewünscht ist.

Die zwei wichtigsten Gründe sind, dass der Anwender zum einem mit der (teilweise fehleranfälligen) Konfiguration der Updates schlicht überfordert ist und zum anderen, dass ein Updaterollout der RCP Anwendung durch Anwender nicht verhindert werden soll.

Bisher wurde empfohlen, dass man stille (silent) Updates über das Kopieren von Dateien in Cluster-Ordner realisieren soll. Der wichtigste Nachteil ist, dass man beim Kopieren exakt wissen muss, in welchem Cluster-Ordner die Installationsdateien kopiert werden sollen.

Der zweite deutlich Nachteil ist, dass man danach den Updater explizit per Befehl aufrufen muss. Das ist für platformunabhängige Anwendungen schon fast ein Totschlagargument gegen diese Vorgehensweise.

Jiri Rechtacek hat in seinem Blog aufgezeigt wie man mit der Autoupdate Services API im Hintergrund Updates aller Bibliotheken durchführt, so dass bestehende (im Plugin-Dialog eingetragene Updatecenter) automatisch komplett aktualisiert werden. Ich habe das bisher so in meinen Anwendungen ähnlich angewendet. Allerdings habe ich teilweise Infrastrukturen, wo ich nicht mal Updatecenter als XML-Dateien auf Servern zur Verfügung stellen kann. Teilweise werden die NBM-Dateien sogar "on-the-fly" erzeugt, um diese direkt zu installieren.

Aber sogar für manuell heruntergeladene NBM-Dateien bietet die Update Autoupdate Services API eine Möglichkeit der Installation. Es ist nämlich nicht zwingend notwendig ein Updatecenter zu haben, um NBM-Dateien zu installieren. Der Plugin Dialog zeigt es ja schon selbst mit der Registerzunge für Downloads.

Zunächst benötigt man eine Modul mit einer ModuleInstall Klasse die am besten über den Assistenten erzeugt wird. Man überschreibt die restored() Methode und sucht sich die passende (bereits) heruntergeladene NBM-Datei. Hier im Beispiel soll das in einer Methode namens getMyDownloadedNBMFile() realisiert werden:

  @Override
  public void restored() {
    // schedule refresh providers
    // install update checker when UI is ready (main window shown)
    WindowManager.getDefault().invokeWhenUIReady(new Runnable() {
      public void run() {
        File file = getMyDownloadedNBMFile();
        RequestProcessor.getDefault().post(new SilentNBMInstaller(file), 10000); 
      }
    });
  }

Der Aufruf der Hilfsklasse SilentNBMInstaller erfolgt erst, wenn die Anwendung einigermaßen hochgefahren ist (invokeWhenUIReady). Der SilentNBMInstaller ist eine schlichte Java Klasse die massiven Gebrauch von der Autoupdate Services API macht. Im Gegensatz zu dem Beispiel von Jiri Rechtacek verwende ich die Progress API gar nicht, um den Fortschritt der Installation zu visualisieren. Auch bekommt der Anwender keine Info die Anwendung neu zu starten. Das kann aber individuell nachgerüstet werden.

public class SilentNBMInstaller implements Runnable {
  
  private final File nbmFile;

  public SilentNBMInstaller(File nbmFile) {
    this.nbmFile = nbmFile;
  }
}

Die run-Methode muss erstmal implementiert werden, außerdem sollte man für das Update (oder die Neuinstallation) aus dem EventDispatchThread heraus sein. Die Methode timeToCheck() liefert true, wenn das Update/die Installation durchgeführt werden soll. Wie das gemacht wird, kann man selbst implementieren. Auch könnte die Prüfung eher im ModulInstall durchgeführt werden.

  public void run() {
    if (SwingUtilities.isEventDispatchThread()) {
      RequestProcessor.getDefault().post(this);
      return;
    }
    if (timeToCheck()) {
      runUpdate();
    }
  }

Das Kernstück ist nun die runUpdate()-Methode. Außerdem unterscheidet sich meine Implementation von Jiri Rechtaceks Beispiel bei dem Ermitteln des Updates. In meinem Fall erzeuge ich einen temporären UpdateUnitProvider zu einer (oder auch mehreren) NBM Datei(en). Dafür nutzt man die Klasse UpdateUnitProviderFactory.

  private void runUpdate() {
    try {
      // Step (1) 
      boolean isInstalled = false;
      // A temporary installer for downloaded nbm files:
      UpdateUnitProvider uup = UpdateUnitProviderFactory.getDefault().create("Installer for " + nbmFile.getName(), nbmFile);
      Collection<UpdateElement> elements4update = new HashSet<UpdateElement>();
      List<UpdateUnit> updateUnits = uup.getUpdateUnits();
      for (UpdateUnit unit : updateUnits) {
        isInstalled = unit.getInstalled() != null; // We need this flag for different OperationContainer
        List<UpdateElement> updates = unit.getAvailableUpdates();
        if (!updates.isEmpty()) { // has updates
          elements4update.add(updates.get(0)); // add plugin with highest version
        }
      } 
      // ... continue with (2)

Wie man oben sieht, wird aus dem UpdateUnitProvider die Collection der UpdateUnits gezogen. Außerdem merke ich mir, ob die NBM-Datei neu installiert werden soll, oder ein Update erfährt. Das ist notwendig, weil da für unterschiedliche OperationContainer erzeugt werden müssen. Das habe ich in eine extra Methode ausgelagert:

      // Step (2)
      if (elements4update.size() > 0) {
        OperationContainer<InstallSupport> operation = getOperationContainer(elements4update, !isInstalled);
        // ... continue with (3)

Die Methode getOperationContainer liefert mir den passenden Container, der die folgende Installation oder das Update durchführen soll.

  private OperationContainer<InstallSupport> getOperationContainer (Collection<UpdateElement> elements4update, boolean install) {
    OperationContainer<InstallSupport> container = install ? OperationContainer.createForInstall() : OperationContainer.createForUpdate ();
    for (UpdateElement element : elements4update) {
        if (container.canBeAdded (element.getUpdateUnit(), element)) {
            OperationInfo<InstallSupport> operationInfo = container.add (element);
            if (operationInfo == null) {
                continue;
            }
            container.add (operationInfo.getRequiredElements ());
        }
    }
    return container;
  }

Im dritten Schritt (der runUpdate-Methode) kann ich den OperationContainer (vom Typ InstallSupport) nun endlich für die Installation oder das Update nutzen:

        // Step (3)
        InstallSupport install = operation.getSupport();

        Validator validator = install.doDownload(null, false);     // Yes we need this call (but the file is already downloaded)
        Installer installer = install.doValidate(validator, null); // Validating
        Restarter restarter = install.doInstall(installer, null); //  Installing

        // ... continue with (4)

Auch wenn man das NBM-File schon lokal auf der Festplatte haben wird, müssen zwingend die drei Aufrufe doDownload/doValidate/doInstall durchgeführt werden. Nur so bekommt man die Objekte Validator/Installer/Restarter, um die Kette auszuführen. Die null-Parameter sind die von mir vernachlässigten ProgressHandle Objekte für die Darstellung des Verlaufs. Die Installation ist aber meistens so schnell, dass das UI in der Statuszeile gar nicht reagiert.

Der Installationsvorgang ist mit den obigen Schritten "vorbereitet". Wir müssen nur dem InstallSupport sagen, wann der Abschluss erfolgen soll.

        // Step (4)

        // It's a silent updated library. For the current run it's unnessesary to ask the user for a restart.
        install.doRestartLater(restarter);
        // ... continue with (5)

Für den Abschluss der Methode runUpdate() noch dieses hier:

      // Step (5)
      }
    } catch (OperationException ex) {
      Exceptions.printStackTrace(ex);
    }    
  }

Damit wäre die Klasse SilentNBMInstaller vollständig. Jiri Rechtacek empfiehlt noch, die Lizenzen der Updates abzufragen und (ggf.) dem Anwender vorzulegen. Das ist spannend bei 3rd-party Bibliotheken und Plugins. Für Silent Updates von Unternehmensanwendungen ist das eher hinderlich und wird bei mir auch damit nicht abgefragt.

In Jiris Blog findet man dazu mehr, wie man die Lizenzen ausliest.

SilentNBMInstaller installiert auch nur einzelne NMB-Dateien. Das ist aber keine notwendige Einschränkung, weil der UpdateUnitProviderFactory.create Methode mehr als eine Datei für die Installation übergeben werden darf. Allerdings erhöht sich dann der Komplexitätsgrad, wenn einige NBM Dateien neu installiert werden und andere nur ein Update benötigen (verschiedene OperationContainer!). Für das einfache Beispiel habe ich es damit erstmal bei einer Unterscheidung einer NBM-Datei belassen.

Beste Grüße,
  Josch.

Moin!

Auf dzone gibt es eine brandneue Ref-Card zur NetBeans Platform. Die Essential NetBeans Platform Refcard zeigt auf sechs Seiten die wichtigsten Referenzen der NetBeans Platform. 

Also ausdrucken und an die Wand gepinnt!

Beste Grüße,
  Josch.

Moin!

Irgendwie hatte ich in Erinnerung, dass das Plugin für den nativen Webbrowser als Embedded Komponente nicht unter 64Bit OS funktioniert. Nun ja. Mit 6.8 wollte ich es einfach mal selber testen und sogar Win7 deutsch, 64Bit ausprobieren.

Das Plugin findet sich ganz oben in der Liste des AutoUpdate Center. Der Download ist schnell, reicht dann aber noch nicht. Mit dem ersten Aufruf des Webbrowser (zu finden mit Menu View/Ansicht) müssen die nativen Bibliotheken nachgeladen werden. 

Bis zum Schluss glaubte ich nicht an einen Erfolg. Aber wie man sieht, es geht doch :-D

Der Embedded Browser (auf Basis des XULRunner für den Mozilla Browser) verhält sich dann so, wie gewohnt. Nur nicht als extra Browserfenster, sondern direkt in NetBeans integriert. Also auch für Kenai.com Projekte, JavaDoc usw..

Nur der Mauszeiger ist nicht immer passend und flackert. Ansonsten ist mir nichts Negatives aufgefallen.

Beste Grüße,
  Josch.

Moin!

Es geht nun los. Der interaktive IDE Vergleich hat gleich mit meinen Antworten auf JAXenter begonnen. Jeder IDE Nutzer und interessierte Leser darf die Fragen und Antworten gerne kommentieren.

Alle Kommentare werden gesammelt und im Finale zusammengefasst. Hier geht es nicht um die 100% objektive Empfehlung und vielleicht bleibt jeder Anwender da wo er heute mit seiner IDE ist. Aber ich finde es sehr wichtig sich im IDE "Geschäft" nicht nur als Konkurrenz zu sehen, sondern auch die IDE User der Mitbewerber zu verstehen. Bestimmt lässt sich viel über die Motivation der Community lernen. Aber dafür brauchen wir nun Feedback:

Kommentarbereich zum interaktiven IDE Vergleich

Danke für Eure Hilfe!

Beste Grüße,
  Josch.

Moin!

Votings zu einer Lieblingsanwendung sind selten Objektiv und belastbar, besonderns wenn es ein Onlinevoting ist.

Aber in diesem Fall ist es nicht so wichtig. JAXenter versucht mal auf eine andere Art und Weise heranzugehen, wie man die aktuellen IDEs vergleichen kann. Es wurden drei Fragen gestellt, die man über die Kommentar-Funktion der JAXenter Seite beantworten kann. 

Wir werden darauf eingehen und bestmögliche Antworten finden. Daniel Megert, Roman Strobl und ich haben die Antworten schon hinterlegt die in Zusammenfassung mit allen anderen Antworten der Community in ein paar Tagen veröffentlicht werden sollen.

So lässt sich vielleicht mal die Motivation erkennen, warum sich andere für eine bestimmte IDE entschieden haben. 

Hier geht es zu dem Einstiegsartikel auf JAXenter. Es würde mich freuen, wenn viele mitmachen würden. Denn auch für mich ist es spannend zu wissen, was die persönliche Entscheidung ausmacht eine bestimmte IDE einzusetzen.

Beste Grüße,
  Josch.

Moin!

Einige Zeit gab es weniger Blog-Posts von mir, aber das hat gute Gründe: Ich hab viel zu tun, was ja auch was Positives ist.

Nach dem ich aber Charles Ditzel mit seinem letzten Blog gelesen hatte, musste ich doch selber mal wieder was schreiben. Statistiken sind eine schöne Sache etwas zu untermauern, von dem man selbst überzeugt ist. Und gerade die Google Trends Statistiken helfen einem sehr dabei.

Ich muss Charles Ditzel sehr zustimmen, dass Oracle die NetBeans IDE und Platform erheblich unterschätzt. Allerdings geht es auch in einem solch kommerziell orientierten Unternehmen nicht nur ausschließlich um ein Wesen als Gesamtes, das Fehler macht, sondern auch um eine gehörige Portion von Lobbyismus - und die geht wohl gerade von der JDeveloper Entwicklingsabteilung aus. Aber egal, das soll jetzt nicht mein Thema sein.

Charles hatte Eclipse aus der Google Trends Abfrage raus genommen, weil das Ergebnis (wegen der angeblichen Marktdominanz) von Eclipse das Ergebnis schwerer zu lesen macht. Aber das ist m.E. eine falsche Einschätzung, denn der Suchbegriff Eclipse bei Google Trends gibt keinesfalls das Ergebnis der Suchmasse zur Eclipse Entwicklungsumgebung wieder. Das sieht man eindeutig an den Trend-Peeks zu den letzten Naturschauspielen: Sonnenfinsternisse.

Also habe ich mal mir genehme Suchbegriffe genommen. NetBeans IDE vs. Eclipse IDE. Und schon verändert sich die Welt der Wahrnehmung. Eclipse IDE nimmt mehr und mehr ab. NetBeans war bis 2007 stabil und schoss dann Ende 2007 sogar über die Eclipse IDE Suchanfragen. Beide IDEs nahmen dann aber auch weiter (und wieder) ab, bis NetBeans Anfang 2009 plötzlich wieder einbrach (womit wir wieder beim Oracle/IBM-Übernahme Thema wären). Seit 2009 halten sich beide IDEs im Trend stabil, weder NetBeans IDE noch Eclipse IDE verlieren oder gewinnen.

Dabei ist der Druck bei NetBeans IDE eindeutig: die Übernahmegerüchte durch IBM und die tatsächliche Übernahme von Oracle (und die nun furchtbare Informationspolitik).

Warum schwächelt aber Eclipse? Ist die Stabilisierung von Eclipse (nach dem langen Fall) nur eine Auswirkung des "schwachen" NetBeans? (Ich spreche nicht von den Features, sondern von der Wahrnehmung in der Community, denn nur das zeigt Google Trends auf). Würde der Trend Eclipse IDE weiter sinken, wenn Oracle sich besser zu NetBeans positionieren würde?

Ich kann das kaum beantworten, subjektiv habe ich mir meine Meinung gebildet, untermauern könnte ich es mit Google Trends Abfragen, die meiner Meinungsbildung am besten passen. Aber ganz neutral: NetBeans IDE vs. Eclipse IDE ist schon ein spannender Blick.

Beste Grüße,
  Josch.

Es stellt sich für mich immer wieder die Frage, ob die JAR-Dateien unserer Firmen-Projekte signiert werden müssen. Für die meisten Entwicklungen war es nicht notwendig. Nur für spezielle Java ME Projekte brauchte ich Signaturen die auf Root-Zertifikate basieren, die von der VM ohne Klage angenommen werden.

Gerade im ME Bereich ist es recht schwer passende Root CA's zu finden, die auf möglichst vielen Mobiles funktionieren. Und einige Endgeräte Hersteller brauen da sowieso ihre eigenen Süppchen.

Im Java SE/EE Bereich gibt es zumindest einen festen Satz von vorinstallierten Root-CA's die man nicht mehr importieren muss. Das manuelle Importieren kann schon eine Hürde für den Endanwender einer Software sein, die dieser nicht bereit ist zu überspringen.

Aber wie lautet nun die Liste? Es gibt da tatsächlich nichts öffentliches. Trotzdem kann man diese Liste mit einem installierten JDK schnell ermitteln.

Es wird das keytool benötigt, es muss bekannt sein, wo sich die Zertifikate der Root-CA's befinden und es wird das Kennwort für den Keystore gebraucht.

1. Das keytool findet sich im Ordner "bin" des installierten JDK
2. Die Datei "cacerts" findet sich im JRE Ordner: "lib/security"
3. und das Kennwort? Sun verrät es auf seiner Homepage: changeit

Nein das ist kein Witz, es funktioniert ;-)

Also in den "bin"-Ordner wechseln und (z.B. für Windows) folgenden Befehl eingeben:

keytool -list -storepass changeit -keystore {...}\jre\lib\security\cacerts 

Statt {...} gibt man natürlich den Pfad zum JRE an.

Das Ergebnis ist eine Liste mit Aliasnamen der Root-CAs, Datum der Ausstellung, Typ und MD5-Hash.

Meine Java Runtime in Version 1.6_14 enthält 63 Aliasnamen mit zugehörigen Zertifikaten. Mehrere Zertifikate wurden allerdings teilweise von einer Stelle ausgestellt. Z.B. Verisign hat da mehrere Root-Zertifikate hinterlegt.

Mit dem -v Parameter wird die Ausgabe erheblich geschwätziger. Die ca. 80kB große Ausgabe informiert dann genauer über die Aussteller und Eigner der Zertifikate.

Mit dieser (doch sehr umfangreichen) Liste kann man sich übrigens gut auf die Suche machen, um einen Root CA mit passenden Konditionen zu finden. Außerdem läuft man nicht in Gefahr, dass der Anwender (trotz Signatur) genötigt wird ein Root-Zertifikat zu importieren.

Beste Grüße,
  Josch.

Während der Göttinger Source Talk Tage wird vom 29.-30. September 2009 ein NetBeans Platform Certified Training am Mathematischen Institut angeboten.

Wer noch den Early Bird Rabatt für das NetBeans Platform Certified Training in Göttingen abschnappen möchte, sollte sich umgehend (und spätestens bis Freitag, 4. September) dazu verbindlich anmelden. 

Die Plätze schmelzen langsam dahin! 

Weitere Infos zum Kurs finden sich hier.

Für Firmenmitglieder gilt eine Teilnahmegebühr von 699,-- Euro. Für Frühbucher gibt es einen Early Bird Discount bis zum 4. September 2009, dann kostet die Teilnahme nur 599,-- Euro. Studenten und Mitarbeiter von Non-Profit-Organisationen dürfen kostenlos teilnehmen!

Hier geht es zur verbindlichen Teilnameanmeldung:

Anmeldeseite der Source Talk Tage 2009

Wir benötigen die Anmeldedaten (auch von Studenten) so früh wie möglich, damit auch die Zertifikate vorbereitet werden können. 

Beste Grüße,
  Aljoscha Rittner

Der Tutorial Builder hat ein kleines Update erhalten. 

• Sortieren der Galeriebilder funktioniert nun mit passender Selektion
• Tastaturkürzel zum Sortieren sind nun [Alt-Shift-Pfeil auf] und [Alt-Shift-Pfeil ab]
• Unter Linux/Unix-Systemen wurde der Screen Shot zweimal ausgeführt. Das müsste nun korrigiert sein. Bitte mal testen.
• Bei Macs wurden die Sondertasten in der Optionsauswahl als Icons dargestellt. Allerdings musste ich feststellen, dass die Symbole schlecht zu lesen sind und teilweise auf MacBooks gar nicht existieren... Für Macs werden nun Texte angezeigt
• Meta-Taste im Optionsdialog ist für Linux/Win ausgeblendet
• Es gibt einen neuen Speicher-Provider für die Screen Shots. Man kann nun auch JPEG speichern. Bei Bildern mit Transparenz kann man im Speicherdialog die Hintergrundfarbe festlegen (JPEG unterstützt ja keine Transparenz)
• Der Toolbar Button für die Bereichsanalyse ist in das Vorschaufenster gewandert (wegen kompletter Umstellung der Programmierung)
• Im Bereichsanalyse-Modus kann man nun per Strg+Mausklick mehrere Bereiche direkt in der Vorschau zusammenfassen. Das ging auch schon im Inspektor. 
• Die Mehrfachauswahl von Bereichen wird nun ordentlich im Vorschaufenster angezeigt.
• Im Optionsdialog wurden für einige Werkzeuge das Optionspanel mehrfach angezeigt. Korrigiert.

Außerdem gibt es ein paar Verbesserungen und Refactorings im Quelltext, die aber so noch nicht sichtbar sind. Performance-Verbesserungen sind auch ein paar rein gekommen.

Das Update ist wie immer im UpdateCenter erreichbar. Oder per Download:

Download-Link.

Beste Grüße,
  Josch.

Während der Göttinger Source Talk Tage wird vom 29.-30. September 2009 ein NetBeans Platform Certified Training am Mathematischen Institut angeboten.

Studenten und Mitglieder einer Non-Profit Organisation haben die Möglichkeit kostenlos an dem zweitägigen Kurs teilzunehmen. Zum Abschluss des Kurses erhält jeder Teilnehmer und jede Teilnehmerin ein Zertifikat.

Nähere Details zu den Inhalten des Trainings findet sich auf der Homepage von NetBeans.

Themenübersicht

Hier eine Übersicht der Themen zu einem Kurs:

Tag 1

• Intro & Simple Port of a Swing Application
• Window System (Teil 1)
• Window System (Teil 2)
• Nodes & Views
• Workshop

Tag 2

• Visual Library
• Workshop
• Lookup
• Module System
• Workshop
• Wrap Up

Es stehen insgesamt 24 Rechnerplätze zur Verfügung. Darüber hinaus ist es möglich ein eigenes Notebook mitzubringen (kostenloses WLAN ist verfügbar). Alle Teilnehmer mit einem eigenen Notebook sollten ein installiertes Java 6 JDK und die aktuelle NetBeans 6.7.1 IDE zur Verfügung haben, damit die Workshops erfolgreich durchgespielt werden können.

Infos zum Zertifizierungsprogramm

Es gibt insgesamt drei Stufen der Zertifizierung.

NetBeans Certified Associate

Die erste Stufe bekommt schon man mit der Teilnahme an beiden Tagen des Zertifizierungskurses. Danach sollte jeder Teilnehmer das Rüstzeug in die Hand gelegt bekommen haben, um sich in der Platform Entwicklung bei den ersten Schritten zurechtzufinden.

NetBeans Certified Engineer

Dieses Zertifikat erhält jeder Teilnehmer, der ein Programm basierend auf der NetBeans Platform (zum Beispiel eine Migration einer alten Swing Anwendung) oder ein Plugin programmiert hat. Dabei geht es nicht um Größe, sondern um das Verständnis. Wir schauen uns die Projekte an, helfen dabei und geben Tipps, bis das Projekt den Status erreicht hat, wo so ein Zertifikat besten Gewissens vergeben werden kann.

NetBeans Certified Committer

Diese höchste Stufe ist schon etwas anspruchsvoller. Es handelt sich dabei um Erweiterungen und Korrekturen (z.B. Bug fixing, Feature enhancements) der NetBeans Platform (oder Derivate, wie z.B. die IDE selbst), die in den Quelltext von NetBeans eingereicht und bestätigt werden. Da werden dann noch andere Augenpaare auf die eingereichten Quelltexte geworfen (nämlich von den Core Entwicklern) und erwartet auch eine hohe Bereitschaft sich direkt mit den Entwicklungsprozessen auseinander zu setzen. Aber auch hier lassen wir niemanden allein.


Alle Teilnehmer erhalten eine Nachbetreuung in einer dafür speziell eingerichteten Mailingliste. In der können sich weltweit die Mitglieder der Zertifizierungskurse austauschen.

Studenten & Non-Profit frei!
Frühbucherrabatt bis 4.9. sichern...

Für Firmenmitglieder gilt eine Teilnahmegebühr von 699,-- Euro. Für Frühbucher gibt es einen Early Bird Discount bis zum 4. September 2009, dann kostet die Teilnahme nur 599,-- Euro. Studenten und Mitarbeiter von Non-Profit-Organisationen dürfen kostenlos teilnehmen!

Anmeldung

WICHTIG: Hier geht es zur verbindlichen Teilnameanmeldung:
Anmeldeseite der Source Talk Tage 2009

Wir benötigen die Anmeldedaten so früh wie möglich, damit auch die Zertifikate vorbereitet werden können.

Beste Grüße,

Aljoscha Rittner

Moin!

Auf JAXenter ist ein kleiner Artikel zu dem Substance Support Plugin erschienen. Wer mehr über die Interna des Plugins erfahren möchte, findet weitere Infos dort:

JAXenter: Mehr Substanz für NetBeans

Beste Grüße,
  Josch.

Moin!

Da mein Blog etwas unter Überlastung leidet, habe ich das Plugin nun nach kenai.com verschoben (was sowieso meine Intention war). Damit sollte das hängende Update-Center wieder funktionieren.

Wer das Plugin schon installiert hat, wird automatisch nach kenai.com für die Updates umgeleitet. Es muss also nichts neu installiert werden (ja, wie genial ist das denn...)

Die neuen Download Links sind folgende (nur für eine Neuinstallation notwendig):

1. Substance Support Plugin
2. Substance 5.2 Patch Module
3. Substance LAF Widget Patch Module

Das Plugin hat auch eine Änderung erfahren. Man erhält nur eine Neustart Erinnerung, wenn man das Skinning geändert hat. Das ist sinnvoll, da manche Editor-Elemente nach dem Ändern etwas "spinnen".

Beste Grüße,
  Josch.

Moin!

Hier ein Aufruf aus dem PHP Blog, ein neues spezielles NetBeans PHP Build zu testen:

Wir suchen Anwender, die uns beim Testen unseres neuen experimentellen PHP NetBeans Builds helfen möchten. Jeder ist willkommen, aber wir benötigen ein besonderes Feedback von den Benutzern, die häufig zwischen NetBeans und externen Anwendungen wechseln müssen (Versionierung, PHP-Framework etc.), wobei es zu externen Dateiänderungen kommen kann. Alle diese Veränderungen durch Drittanbieter-Tools sollten korrekt in NetBeans zurück fließen. Es geht also um eine gut funktionierende Synchronisation der Dateiänderungen zwischen NetBeans und anderen Tools, die an den selben Dateien arbeiten.

Allerdings könnte die Performnce, vor allem auf nicht-lokalen Festplatten, etwas schlechter werden. Wenn Sie PHP-Projekte mit solchen Quellen auf externen Medien haben (z.B. Netzlaufwerke), testen Sie bitte den aktuellen Build, weil wir wirklich an Ihren Ergebnissen interessiert sind.

Wenn Sie als an diesem Test teilnehmen möchten, downloaden Sie das aktuelle Build (93,2 MB) und starten Sie NetBeans mit der Option

-J-Dorg.netbeans.modules.masterfs.REFRESH.level=0

damit nützliche Informationen protokolliert werden können. Senden Sie bitte bis Ende August 2009 (je früher, desto besser) uns Ihr Feedback zusammen mit dem IDE-Log direkt an an tomas (dot) mysik (at) sun (dot) com.

Der Link zum Download ist in dem englischsprachigen PHP Blog zu finden.

Beste Grüße,
  Josch.

In einem mehrteiligen Tutorial habe ich beschrieben, wie man mit GUI Beans im GUI Builder umgeht. Eine Spezialität ist aber offen geblieben. Wie kann man GUI Container in den GUI Builder verwenden und zugleich schon Komponenten vorgeben?

Generell ist es erstmal nur möglich Container als GUI Elemente zu verwenden, wenn diese keine Komponenten enthalten. Also ein leeres JPanel. Diese Container müssen auch zwingend java.awtContainer als Super-Klasse haben und die letzte Einschränkung: der LayoutManager des Beans muss vom GUI Builder verstanden werden.

Wenn diese Voraussetzungen erfüllt sind, kann man das Bean direkt per Drag and Drop in den GUI-Builder ziehen und dann auch sofort Komponenten einfügen.

Aber gerade bei GUI Beans will man schon Komponenten in das Bean einfügen. Das darf man auch, allerdings muss dann das Bean im GUI Builder "so-wie-es-ist" verwenden. Man darf dem Bean selber keine Komponenten mehr hinzufügen.

Was also tun, wenn man dem Bean-Anwender doch die Möglichkeit geben möchte, Komponenten hinzufügen zu dürfen. Beispiele gibt es genug. Vielleicht könnte es ein File-Dialog Bean sein, dem der Entwickler später eine Vorschauansicht mitgeben möchte.

Wenn man solche Beans realisieren möchte, kommt man (leider) um die BeanInfo Klasse nicht herum. Man muss nämlich auf dem Bean eine freien Platz reservieren, in dem der spätere Anwender seine Komponenten hinzufügen darf.

Diesen freien Platz muss man in der BeanInfo Klasse bekannt machen. Aber erstmal zum ersten Schritt. Einfach mal ein JPanel-GUI mit der NetBeans IDE erzeugen. Dort packe ich ein Label und ein Textfeld rein. Diese beiden Komponenten sollen immer von diesem Bean vorgegeben sein:

Den Container (das Delegate Panel) habe ich grün eingefärbt, damit man ihn in diesem Tutorial besser sehen kann. Es ist ein einfaches JPanel mit beliebigen Namen. In diesem Fall ist es der Name innerPane.

Das Bean benötigt nun eine Methode, die das JPanel als Container bekannt gibt. Auch dieser Name der Methode ist gleichgültig. Aber getInnerPane bietet sich an:

Aber damit kann der GUI Builder noch nichts anfangen. Wenn wir das Bean (im compilierten Zustand) so per Drag and Drop in den GUI Builder ziehen würden, könnte man dem Bean keine Komponente hinzufügen.

Nun der Trick. Auf das Bean die rechte Maustaste und eine BeanInfo-Klasse erzeugen lassen. Der Quelltext wird folgendermaßen ergänzt:

Es muss also nur der Wert containerDelegate gesetzt werden: Mit dem Methodennamen aus unserem Bean.

Nun kann man das Bean (neu compiliert und eingefügt) als Container für Komponenten nutzen. Wenn man den grünen Platzhalter nicht sofort sieht, einfach trotzdem eine Komponente von der Palette auf das Bean ziehen. Die Komponente wird dann an der passenden Stelle eingefügt. Ggf. wurde nämlich vom LayoutManager der Bereich einfach auf 0 * 0 Pixel zusammen geschrumpft.

Hier das Ergebnis:

Bleibt nur noch zu sagen, dass in diesem Fall das Delegate die Einschränkungen geerbt hat: Es dürfen keine vorgegebenen Komponenten im Panel liegen und ein bekannter LayoutManager des GUI-Builders muss genutzt werden.

Beste Grüße,
  Josch.

Moin!

Seit dem 10. Januar 2009 gibt es eine nette Erweiterung der NetBeans API für TopComponents. Die @ConvertAsProperties Annotation erlaubt es Eigenschaften des Fensters als Properties zu speichern. 

Das ist sehr bequem, weil man sich erstmal nicht generell mit der Serialisierung beschäftigen muss.

@ConvertAsProperties einsetzen

Das Schreiben von Eigenschaften sieht dann so aus:

  void writeProperties(java.util.Properties p) {
    p.setProperty("version", "1.2");
    // TODO store your settings
    p.setProperty("dividerLocation", Integer.toString(jSPLMain.getDividerLocation()));
    p.setProperty("regionViewer.visible", Boolean.toString(((JPreviewViewer)jPNPreview).isRegionViewerVisible()));
  }

Und das Einlesen:

  private void readPropertiesImpl(java.util.Properties p) {
    String version = p.getProperty("version");
    // TODO read your settings according to their version
    if ( "1.1".equals(version) ) {
      jSPLMain.setDividerLocation(Integer.parseInt(p.getProperty("dividerLocation")));
    }
    if ( "1.2".equals(version)) {
      ((JPreviewViewer)jPNPreview).setRegionViewerVisible(Boolean.valueOf(p.getProperty("regionViewer.visible", "true")));
    }
  }

Die NetBeans Platform kümmert sich automatisch um das Speichern auf die Festplatte (oder sonst wo hin). Ich als Programmierer muss mich darum nicht kümmern. Die TopComponent muss aber annotiert werden:

@ConvertAsProperties(
  dtd = "-//org.sepix.tutorialbuilder.ui//Gallery//EN",
  autostore = false)
public final class GalleryTopComponent extends TopComponent {

Das erstellt übrigens schon alles das Template, wenn man neue TopComponents mit dem Wizard erzeugt.

Singleton Pattern funktioniert nicht mehr

Nun zum Problem. Es passiert nun, dass zum Einlesen der Properties das Fenster zwei mal erzeugt wird. Einmal zum Einlesen der Eigenschaften und das zweite Mal bei ersten Anzeigen der TopComponent. Das ist natürlich fatal, wenn man davon ausgeht, dass das Fenster ein Singleton sein soll. Zum Beispiel wenn man Resourcen bindet, Listener verknüpft usw...

Es wurde ein Issue dazu angelegt und heute kam

...die Lösung

Es ist tatsächlich kein API Problem, sondern das vom Wizard erzeugte Template hat einen winzigen Bug.

Wie man oben sehen kann, werden die Eigenschaften in der Methode readPropertiesImpl eingelesen. Es gibt auch noch readProperties, die in der alten Version des Templates folgendes machte:

  Object readProperties(java.util.Properties p) {
    GalleryTopComponent singleton = GalleryTopComponent.getDefault();
    singleton.readPropertiesImpl(p);
    return singleton;
  }

Das sieht zunächst sauber aus, verursacht aber durch den getDefault()-Aufruf eine Instanz, die bedauerlicherweise später verworfen wird.

Das neue (korrigierte) Template wurde nun in den main-golden Trunk integriert und würde folgende Methode erzeugen:

  Object readProperties(java.util.Properties p) {
    if ( instance == null ) {
      instance = this;
    }
    instance.readPropertiesImpl(p);
    return instance;
  }

Sieht eigentlich noch logischer aus ;-) - Und das ist übrigens auch die Lösung für aktuelle Versionen (6.7 und 6.7.1) von NetBeans. Einfach in den TopComponents, die man durch den Assistenten erzeugt hatte, die readProperties-Methode mit dem obigen Quelltext austauschen. Dann werden die TopComponents garantiert nur noch einmal erzeugt.

Beste Grüße,
  Josch.

Moin!

Das Plugin für den Substance Support hat ein kleines Update erfahren.

Zum einem gab es noch eine Violation Exception im Plugin Manager, die nun unterdrückt wird und man kann nun "On-the-fly" die Skins ändern (soweit man das erste mal das Substance PLAF aktiviert hatte und ein Neustart erfolgte). Man kann Substance trotz Plugin deaktivieren und Fensterdekoration von Substance übernehmen lassen (Unterschiede sieht man in den unteren Screenshots)

Ich habe das Plugin in meinem Updatecenter aktualisiert. Wenn es Probleme beim Updatecenter gibt (ewiges herunterladen), gelten noch diese Download-Links:

1. NetBeans Substance 5.2 Module
2. NetBeans Substance 5.2 Patch Libraries
3. NetBeans Substance LAF Widget Patch

Fensterdekoration vom Betriebssystem:

Fensterdekoration von Substance:

Beste Grüße,
  Josch.

Moin!

Ich habe heute noch mal schnell ein Substance Look And Feel Support erstellt. Es ist etwas Beta und man kann nur ein paar PLAFs über die Optionen einstellen (die --laf Einstellung geht im Moment nicht).

Hier ein Screen-Shot einer der PLAFs:

Man benötigt für das Plugin drei Dateien:

1. NetBeans Substance 5.2 Module
2. NetBeans Substance 5.2 Patch Libraries
3. NetBeans Substance LAF Widget Patch

Nach der Installation der drei NBM-Dateien findet Ihr unter den Optionen (in Verschiedenes) eine Registerzunge Look and Feel. Mal eines ausprobieren und die IDE neu starten. Updates zu dem Plugin erhaltet Ihr per Update-Center.

Voraussetzung ist NetBeans 6.7.1 und Java 6. Und es ist pure Beta, nur unter Windows getestet.

Beste Grüße,
  Josch.

Moin!

Am Wochenende gab es wieder ein Certified Training zur NetBeans Platform in der schönen und quirligen Universitätsstadt Bonn.

Das war die Ankündigung der studentischen Consultingfirma AureliusConsult. Ich möchte mich im Namen der Trainer für die hervorragende Planung und Bewirtung bedanken!

Zusammen mit Geertjan (Sun Microsystems) und Toni (Eppleton) haben wir in zwei Tagen ein strammes Programm zur Platform Programmierung geboten:

Samstag

• Intro & Simple Port of Anagram Game (Geertjan)
• Window System (Teil 1) (Toni)
• Window System (Teil 2) (Toni)
• Nodes & Views (Josh)
• Workshop (Geertjan)

Sonntag

• Visual Library (Toni)
• Workshop (Toni)
• Lookup (Josh)
• Workshop (Geertjan)
• Wrap Up (all)

Hier ein Gruppenfoto aller Teilnehmer mit uns Trainern im Hintergrund:

Die Unterlagen zu dem Training sind unter edu.netbeans.org zu finden.

Meine Vortrags-Präsentationen waren folgende:

• Modules & Lookups (vollständige Präsentation)
• Nodes & Views (vollständige Präsentation)

Und hier noch ein paar Impressionen:

Geertjan (links) und Toni (rechts) beim Intro zur Visual Library

Geertjan unterstützt die Studenten bei den Workshops.

Ich bei der Präsentation der Nodes und Explorer API

Dieser 2-tages Kurs ist Teil des NetBeans Platform Certified Training. Wir bieten diese Kurse kostenlos für Universitäten, Java User Groups und Non-Profit-Unternehmen an. Als Ergebnis erhalten die Teilnehmer Zertifikate, die noch in zwei Stufen erweitert werden können.

Natürlich bieten wir erweiterte Kurse auch für Firmen weltweit in deutscher und englischer Sprache an. Sprechen Sie uns an!

Beste Grüße,
  Josch.

Moin!

Ich habe der Project Group Toolbar ein kleines Update gegeben.

Nun werden alle Änderungen der Gruppen an den Toolbar-Button und an das Menü weitergereicht. Darunter fällt das Hinzufügen und Entfernen sowie das Umbenennen von Projekt-Gruppen.

Weiterhin habe ich einen Lizenztext hinzugefügt. Ich werde für den Sourcecode ein paar Hinweise als zukünftige Blog-Einträge posten. Der Quelltext selbst kämpft mit so vielen Hacks und Tricks, das will ich so nicht veröffentlichen. Ich möchte eher dafür sorgen, dass die API in NetBeans da verbessert wird ;-)

Link für Download. Ein Update ist im Plugin-Center auf plugins.netbeans.org. Und mein Update-Center wird bei allen installierten Versionen sowieso reagieren.

Beste Grüße,
  Josch.