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.

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.

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.

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.

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.

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.

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.

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.

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.

├───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.