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.

Moin!

Ich arbeite sehr gerne mit Projekt-Gruppen, da ich ständig in unterschiedlichen Bereichen mit verschiedenen Projekten arbeiten muss. So habe ich eine Projektgruppe für den Tutorial Builder, für den CronJob Scheduler und noch viele weitere Projektgruppen (für das Certified Training und für meine kommerziellen Anwendungen). 

Allerdings nervte mich das ständige rumgeklicke im Datei-Menü. Mit dem kleinen Plugin wird das Projektgruppen-Untermenü als DropDown Menü in die Toolbar übertragen:

Mit dem Mausklick auf den kleinen Pfeil wird das Menü geöffnet und man kann eine Projektgruppe auswählen. Ein direkter Klick auf den Button öffnet umgehend die Projektgruppeneigenschaften. Das finde ich persönlich sehr bequem, um unmittelbar die Gruppenzugehörigkeit zu speichern (Ich verwende nämlich nicht das automatische Speichern).

Für wen das kleine Plugin auch praktisch ist, findet es im Plugin-Center von netbeans.org oder bei mir als Download.

Beste Grüße,
  Josch.

Ich programmiere gerade eine kleine Web-Applikation und möchte dazu die neuen REST-Features vom Spring-Framework benutzen. Bis gestern habe ich mir dazu in Netbeans ein Webprojekt gebaut und dann ganz artig alle notwendigen Bibos von Hand dem Projekt hinzugefügt. Gestern wurde nun der Milestone 4 von Spring 3.0.0 veröffentlicht und ich wollte mir nicht noch einmal die Arbeit machen.

Also musste ein Tool her, welches mir alle notwendigen Jar’s auflösen kann und in mein Projekt einhängt. Da ich nicht so ein rechter Fan von Maven bin, habe ich wieder einmal die Gelegenheit genutzt und Ivy ausprobiert. Als IDE verwende ich Netbeans – also muss ein Plugin für Netbeans her, welches mir die Arbeit mit Ivy innerhalb der IDE vereinfacht. Also schnell mal bei ivybeans vorbeigeschaut. Version 1.1 unterstützt jetzt auch Webprojekte – Schick! Also schnell das Plugin installiert und ein Repository gesucht in welchem die 3.0.0M4 Version von Spring liegt. Nach ein wenig Suchen habe ich dann herausgefunden, dass es ein Spring-eigenes Repository in Amazon S3 gibt (S3Browse ist übrigens ein guter Browser für S3).

Dann habe ich mir noch die folgenden zwei Dateien für die Konfiguration von Ivy im Projektverzeichnis meines Webprojektes angelegt:

Hier der Inhalt der Dateien:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation=
                   "http://ant.apache.org/ivy/schemas/ivy.xsd">
    <info module="WebApplication2" organisation="WebApplication2" revision="1.0"/>
    <configurations>
        <conf name="compile"/>
        <conf name="runtime"/>
        <conf name="compile-test"/>
        <conf name="runtime-test"/>
    </configurations>
    <dependencies>
        <dependency org="org.springframework" name="spring-webmvc" rev="3.0.0.M4" conf="" />
    </dependencies>
</ivy-module>

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="UTF-8"?>
<ivysettings>
    <settings defaultResolver="chained"/>
    <resolvers>
        <chain name="chained">
            <ibiblio name="maven2" m2compatible="true"/>
            <ibiblio name="s3.maven.springframework.org" m2compatible="true" root="http://s3.amazonaws.com/maven.springframework.org/milestone/"/>
        </chain>
    </resolvers>
</ivysettings>

Dann im Projekt Ivy aktivieren. Dazu mit der rechten Maustaste auf das Projekt und in den Ivy-Einstellungen das Häkchen machen und die zwei Dateien auswählen:

Dann noch das Projekt zwingen sich die Jars zu holen:

Und siehe da… alle Jar’s und Sourcen (wenn im Repository) sind da:

Mit der rechten Maustaste kann man nun ganz einfach die Abhängigkeiten entfernen, die man nicht braucht.

Da das Plugin für CronJobs in NetBeans relativ schnell gewachsen ist, sammele ich hier mal ein paar Feature und gebe Tipps, wie man das Tool einsetzen kann.

Die grundsätzliche Überlegung ist natürlich: Braucht man sowas?

Natürlich gibt es 100 andere Lösungswege, wenn man zeit- und aktionsgesteuert Ant-Targets auslösen möchte. Aber es macht Sinn innerhalb der IDE von NetBeans, direkt das Build-System ansprechen zu können. Und auch die Aktionen Projekt öffnen, Projekt schließen, IDE starten und IDE beenden gehören einfach zur IDE. Darum das Plugin.

Warum Ant Targets?

Wenn man bei fast allen Projekt Typen in NetBeans Ant basierte Build Systeme hat (ausgenommen mal C/C++ und PHP), macht es schon Sinn auf dieser Ebene das (in der IDE) frei verfügbare "Scripting"-Framework zu verwenden. Allerdings möchte ich für die Zukunft nicht ausschließen, andere Aktionen (als Ant-Targets) zu starten. Deswegen muss man schon jetzt immer bei den Aktionsdefinitionen das Schlüsselwort "ANT" verwenden.

Und auch bei Nicht-Ant-Projekte kann man natürlich eigene Ant Scripte angeben und ausführen lassen.

Warum die CronJob Syntax?

Die Syntax ist zwar auf den ersten Blick nicht sofort verständlich aber universell. Man bekommt in allen Ecken des Internets Doku und Hilfestellung. Außerdem erschien mir die Cron4j Implementation sehr sauber und stabil. Schlussendlich kam ich erstmal um ein eigenes Scheduler Framework plus GUI drumherum. Damit konnte die erste Version innerhalb von drei Mannstunden zum laufen gebracht werden. Ich will aber nicht ausschließen, dass ein Assistent zum Einplanen von CronJobs folgen wird.

Man darf aber auch den Nachteil nicht vergessen. Exakt alle (möglichen) Zeitpunkte für einen Job kann man nicht definieren. Auch sind CronJobs wiederkehrend. Einen Job für nur ein Datum kann man nicht einrichten (der längste Wiederholungszeitraum ist jährlich). Wenn gewünscht könnte man die Syntax erweitern, um den CronJob nach erster Ausführung zu deaktivieren...

Außerdem sind CronJobs exakt an Minuten ausgerichtet. Deswegen kann man keine CronJobs 10 Sekunden nach IDE Start ausführen (ich erzeuge nämlich aus der relativen Angabe von z.B. 3m einen CronJob zu einem Zeitpunkt exakt 3 Minuten nach IDE Start). Es wäre aber möglich diese Einschränkung in Zukunft fallen zu lassen.

Unterschiede der Job-Einplanungen

Globale Jobs

Man kann Global (in den Optionen der NetBeans IDE) Jobs einplanen. Einmal für wiederkehrende Zeiten und außerdem für den NetBeans Start und für das NetBeans Beenden. Jobs für den NetBeans Start müssen mit einer Duration-Angabe versehen werden (z.B 2m für zwei Minuten nach IDE Start oder 1h für eine Stunde). Jobs für das Beenden der IDE werden unmittelbar ausgeführt (eine Angabe einer Zeit ist da nicht möglich). Die Jobs beim Beenden verhindern natürlich erstmal den Shutdown der IDE. Es erscheint der bekannte Progress Dialog, dass noch Tasks am laufen sind.

Projektbezogene Jobs

Die projektbezogenen Jobs beziehen sich direkt auf das Projekt, dem sie zugeordnet sind. Dafür erhalten fast alle Projekttypen (JavaSe, -ME, EE, PHP, Web, Groovy, NetBeans-Modules, usw) einen neuen Anzeige-Knoten in der Projektansicht. Unter dieser CronJob Konfiguration verbergen sich zur Zeit drei Punkte zum konfigurieren von Jobs. Projekt-CronJobs, Beim Öffnen ausführen und Beim Schließen ausführen. Bei all diesen Jobs wird das Ant-Script aus dem Projekt ermittelt (also gibt man es bei der Definition nicht mit an). "Beim Öffnen" bedeutet nicht nur das Öffnen eines Projektes während der Arbeit mit der IDE, sondern auch bei IDE Start (wenn das Projekt schon vormals geöffnet war). "Beim Schließen" triggert auch beim Beenden der IDE.

Nicht immer will man (oder kann man, siehe PHP-Projekte) das Script des Projektes verwenden. In dem Konfigurationsdialog kann man dann ein individuelles Script angeben.

Erste Schritte

Ein Testtarget

Als ein sehr nützliches Ant Target hat sich dieses Beispiel bewährt:

    <target name="scheduletest">
      <tstamp>
	<format property="start" pattern="yyyy MMMM dd HH:mm:ss" locale="en"/>
      </tstamp>

      <echo message="Target started at ${start}"/>
      <sleep seconds="15"/>
      <echo message="Target finished. Thank you for the audience."/>
    </target>

Es zeigt die Startzeit an, wartet 15 Sekunden und verabschiedet sich höflich.

Wann immer man am Anfang mit dem Plugin rumspielt sollte man diese Target parat haben und es in die eigenen Ant-Scripte einfügen. Ein komplettes Ant-Script (jetzt ohne Target) sollte so aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<project name="somename" basedir=".">
    
</project>

Das Target kann man zwischen <project> (hier) </project> einfügen. Gerade für Globale Jobs muss man ein eigenes Script anlegen.

Ein globaler CronJob

Das obige Script einfach mal (komplett) in das Home-Verzeichnis in den Unterordner jobs ablegen. Das Script als text.xml benennen.

Nun in der IDE Extras->Optionen (Tools->Options) öffnen. Unter Verschiedenes (Miscellaneous) den Tab "CronJob" auswählen. Unter Globale CronJobs nun diese Zeile einfügen:

*/2 * * * * ANT "{user.home}/jobs/test.xml" scheduletest

Die ersten fünf Angaben der Zeile sind echte CronJob-Syntax und bedeuten, dass der nachfolgende Befehl alle 2 Minuten ausgeführt werden soll (*/2 bedeutet: Nimm die Minuten der aktuellen Zeit, führe die Operation "aktuelle_minute modular 2" aus und prüfe das Ergebnis auf 0, dann führe den Befehl aus - also */5 würde alle 5 Minuten ausgeführt. */30 würde um :00 und :30, also jede halbe Stunde, und nun die Preisfrage: */31?).

Die Angabe ANT ist einfach ein eigenes Schlüsselwort (im Moment das einzige). Für globale Jobs muss (nach ANT) immer ein individuelles Script angegeben werden. Am besten in Anführungsstriche, besonders dann, wenn man Properties mit angibt. In diesem Fall wäre das {user.home} und wird mit dem Home-Pfad des Betriebsystems-Anwenders substituiert. Und da so ein Pfad Leerzeichen enthalten kann, brauchen wir die Anführungsstriche...

Als Properties sind alle System.properties der Java VM möglich (aber nicht unbedingt sinnvoll). Der letzte Parameter ist das Target in dem ANT Script. Man darf auch mehrere mit Komma getrennt (aber ohne Leerzeichen) angeben. Die werden dann in der vorgegebenen Reihenfolge abgearbeitet (z.B. clean,compile).

Damit das obige Beispiel nun läuft, muss man die Jobs generell aktivieren. Entweder auf die Uhr (obere rechte Ecke) klicken (so dass diese farbig wird), oder die Checkbox unten links anhaken.

Den kompletten Optionsdialog mit [Ok] bestätigen. Dann ist alles scharf geschaltet.

Sofort sollte sich das Ausgabe Fenster öffnen und folgendes anzeigen:

Try to start scheduler
Initializing 1 cronjob tasks for the scheduler...
  Scheduler started.

Das ist das CronJob Fenster (ein extra Ausgabe Fenster nur für Job-Einplanungen)

Nach zwei Minuten (+ x Sekunden < 60) erscheint ein weiteres Fenster (Titel ist test(scheduletest)) mit folgender Ausgabe:

scheduletest:
Target started at 2009 August 06 10:36:00
Target finished. Thank you for the audience.
ERSTELLEN ERFOLGREICH (Gesamtzeit: 0 Minuten 15 Sekunden)

Nun exakte zwei Minuten später die Aktualisierung:

scheduletest:
Target started at 2009 August 06 10:38:00
Target finished. Thank you for the audience.
ERSTELLEN ERFOLGREICH (Gesamtzeit: 0 Minuten 15 Sekunden)

Das war es auch schon. Der Test für die ersten Schritte war erfolgreich. Am besten wird der CronJob nun wieder in den Optionen deaktiviert...

Ein Job beim IDE Start

Wenn man das selbe Script auch beim Hochfahren der IDE starten will, muss man dieses in den Optionen im zweiten Eingabefeld eintragen. Allerdings verlassen wir damit die reguläre CronJob-Syntax. Die erste Angabe ist ausschließlich eine Duration Angabe:

2m ANT "{user.home}/jobs/test.xml" scheduletest

Damit uns der erste Test nicht reinpfuscht, kommentieren wir im darüber liegenden Feld (für die CronJobs) die Testzeile mit einem # aus.

Nicht die angehakte Checkbox vergessen, mit [Ok] bestätigen und mal in das CronJob Ausgabefenster schauen. Folgende Zeilen sind hinzugekommen:

Starting ANT {user.home}/jobs/test.xml scheduletest 
Starting succeeded ANT {user.home}/jobs/test.xml scheduletest 
Starting ANT {user.home}/jobs/test.xml scheduletest 
Starting succeeded ANT {user.home}/jobs/test.xml scheduletest 
Starting ANT {user.home}/jobs/test.xml scheduletest 
Starting succeeded ANT {user.home}/jobs/test.xml scheduletest 
Stopping tasks for the schedulerScheduler stopped.
Try to start scheduler

Die Starting-Zeilen sind noch vom letzten Test. Die letzte Zeile verwundert erst. Es fehlt eine Angabe von neuen Taskeinplanungen. Aber tatsächlich ist das nicht falsch. Denn für den Neustart eingerichtete Jobs werden erst bei dem Start der IDE aktiviert. Im Moment läuft die IDE ja schon eine Weile.

Also die IDE beenden und neu starten.

...

Wieder da? Gut.

Unmittelbar sieht man nun im CronJob-Ausgabefenster dies hier:

Try to start scheduler
Initializing 1 startup tasks for the scheduler...
  Scheduler started.

Na also, ein Startup-Task wurde eingerichtet. Und zwei Minuten später die bekannte Testausgabe:

scheduletest:
Target started at 2009 August 06 10:51:00
Target finished. Thank you for the audience.
ERSTELLEN ERFOLGREICH (Gesamtzeit: 0 Minuten 15 Sekunden)

Damit funktionieren auch die Startup-Jobs.

Ein Job beim IDE beenden

Jobs, die beim Beenden aktiviert werden, benötigen gar keine Zeitangabe mehr. Wer will schon länger auf den Feierabend warten, als es nötig ist?

Wieder in den CronJob-Optionen kommt in das letzte Feld diese Zeile:

ANT "{user.home}/jobs/test.xml" scheduletest

Nun mal die IDE schließen. Unmittelbar erscheint ein Dialog "IDE beenden", in dem sind zwei Prozesse aufgelistet:

Prozess - Run 1 shutdown task(s)
test (scheduletest)

                      [IDE beenden]  [Abbrechen]

Wenn man nun geduldig wartet ist die IDE 15 Sekunden später weg vom Fenster. Ungeduldigerweise könnte man auf [IDE beenden] klicken. Der aktuelle Ant-Task (und alle weiteren) würden abgebrochen werden. Mit [Abbrechen] beendet sich die IDE nicht. Aber es würden trotzdem alle Shutdown-Jobs weiter eingeplant laufen (das kann zu dem Zeitpunkt nicht mehr verhindert werden)!

 

Soweit erstmal die wichtigsten Tipps zum neuen CronJob-Plugin. In einem zweiten Teil gehe ich auf die projektbezogenen Ant Jobs ein.

 

*) Zur Preisfrage: Nur einmal jede Stunde in der 31. Minute, nicht um :31 und :01! Wenn man zur ersten und 31. Minute den Job haben will, muss man den ersten Parameter so schreiben 1,31 (ohne Leerzeichen)

Moin!

Die Version 1.0.4 hat gleich einiges zu bieten.

• Unterstützung für alle bekannten offiziellen Projekttypen (z.B. PHP, Web, J2EE, Grrovy, Ruby, NetBeans Plugins und Module)
• Für das Schließen eines Projekts können nun auch Jobs eingeplant werden (die auch alle beim Runterfahren der IDE ausgeführt werden)
• Man darf nun für jedes Projekt (auch für nicht Ant-Build basierte Projekte) eine eigenes Ant-Script angeben.
• Mehrere Targets pro Ant Job (mit Komma trennen - ohne Leerzeichen), z.B.: clean,compile

Damit ist von meiner Seite das CronJob-Plugin nahezu Feature complete. Wenn noch weitere Wünsche bestehen, würde ich mich freuen, wenn entsprechende Diskussionen auf der Projekt-Homepage starten würden.

Hier noch ein paar Screen shots (natürlich mit dem Tutorial Builder erstellt):

Hier die Auswahl eines eigenen Scripts in einem PHP-Projekt:

Der Download des Binaries erfolgt im Download-Bereich des Projektes. Wer schon ältere Versionen hat, checkt einfach mal auf Updates (im Hilfe Menü der IDE).

Beste Grüße,
  Josch.

Nun ist ein wichtiger Teil der Kür geschafft.

Jetzt können für JavaSE - Projekte Cronjobs und "Beim-Öffnen" Jobs für Ant Targets definiert werden. "Beim Schließen" folgt noch (das ist etwas komplizierter).

Auf kenai.com ist alles aktualisiert, AutoUpdate-Center hat auch die aktuelle Version.Dort findet sich im Download-Bereich das Binary und im Wiki ein Screenshot.

Es ist übrigens auch eine nette Studie für Entwickler, die herausfinden wollen, wie man bestehende Projekt-Typen sowie geöffnete Projekte abfragt und erweitert. Die Doku dazu ist nämlich recht spärlich oder besser gesagt: sehr dünn im Internet verteilt...

Die aktuelle Version 1.0.2 bietet nun Startup- und Shutdown-Jobs an. Startup-Jobs benötigen eine Zeitangabe in Minuten oder Stunden nach dem Starten der NetBeans IDE und Shutdown-Tasks ausschließlich nur den ANT-Befehl.

Hier der neue Optionen-Dialog:

Wenn Shutdown-Jobs beim Beenden von NetBeans angestoßen werden, sieht das folgendermaßen aus:

Um das vernünftig zu testen, kann man mal folgendes Ant-Script verwenden:

<?xml version="1.0" encoding="UTF-8"?>
<project name="test" basedir=".">
    <description>Builds the module suite sXprjsched-suite.</description>
    <target name="run">
      <tstamp>
	<format property="start" pattern="yyyy MMMM dd HH:mm:ss" locale="en"/>
      </tstamp>

      <echo message="Task started at ${start}"/>
      <sleep seconds="15"/>
      <echo message="Task finished. Thank you for the audience."/>
    </target>
</project>

Ich hoffe damit sind erstmal die wichtigsten Features implementiert. Der Sourcecode wurde auf kenai.com aktualisiert. Das Projekt findet sich hier.

Wer die Version 1.0.1 schon hat, erhält das Update im Auto-Update Center. Ansonsten biete ich hier einen Download des Plugins an.

Wenn weitere Änderungen gewünscht werden, kann man sich ja als Developer in dem kenai-Projekt anmelden.

Beste Grüße,
  Josch.

Moin!

Die Idee hatte lothorien (Twitter) in diesem Forums-Eintrag. Die Umsetzung dauerte ungefähr 3h (ohne Doku zu schmökern, ohne Mittagspause und ohne andere wichtige Arbeiten ;-)).

Nun kann man in den Optionen CronJobs für Ant-Scripte einrichten.

Die Syntax ist gleich den normalen CronJobs, die man von Unix/Linux kennt. Der Befehl ANT muss folgen, dann das Ant-Script. In geschweiften Klammern sind alle System-Properties erlaubt. Letzter Parameter ist das Target.

Als Scheduler verwende ich Cron4j.

Wenn man diese Ant-Script verwendet:

<?xml version="1.0" encoding="UTF-8"?>
<project name="test" basedir=".">
    <description>Builds the module suite sXprjsched-suite.</description>
    <target name="build">
      <tstamp>
        <format property="start" pattern="yyyy MMMM dd HH:mm:ss" locale="en"/>
      </tstamp>
      <echo message="Task started at ${start}"/>
    </target>
</project>

Gibt es minütlich (soweit natürlich eingerichtet) diese Ausgabe:

Und nicht vergessen: In den Optionen auch den Scheduler aktivieren!

Download: CronJob Scheduler.

AutoUpdate-Center ist gleich mit dabei.

Lokalisierung in Deutsch und Englisch. Über Feedbacks würde ich mich freuen. Lizenz wird LGPL werden.

Kenai.com

Das Projekt ist nun auf kenai.com gehostet.

Beste Grüße,
  Josch.

Moin!

Wieder ein kleines Update für den Tutorial Builder. Ich freue mich über jedes Feedback!

Updatehinweise

• Das AutoUpdate erzwingt nun ein Neustart der IDE (geht nicht anders, da die Service-API verwendet wird).
• Man kann nun zwischen drei verschiedenen Vergrößerungswerkzeugen aussuchen. Dafür habe ich den DropDownToggleButton von NetBeans etwas umgestrickt (die NetBeans-Variante kam nur mit horizontalen Toolbars klar)
• Das Hinweisfenster kann nun dauerhaft deaktiviert werden. Um das Hinweisfenster wieder anzuzeigen, gibt es eine Einstellung in den Optionen.
• Im Hinweisfenster habe ich mir erlaubt einen Link zu diesem Blog zu setzen, damit bekommt man schnell die neuesten Infos.
• Das Statusleisten-Icon hat sich ein wenig verändert
• Wenn man im Regionen-Navigator mehrere Well-Known-Areas (mit der Strg-Taste) auswählt, kann man nun diese gemeinsam in ein neues Bild zuschneiden. So kann man Toolbars, Menüs und Modes gemeinsam auf ein Screenshot bannen.
• Es gibt eine weitere Drucktastenkombination.
  • Druck (Prinstcreen) macht eine Kopie des kompletten Desktops
  • Alt+Druck macht eine Kopie des NetBeans Anwendungsfenster
  • Strg+Druck erzeugt ein Bildschirmfoto des aktiven Fensters der NetBeans-Anwendung (praktisch für modale Dialoge)
• Der Kopie-Bereich "blitzt" nun beim Screenshot auf.
• Die Vorschau hat nun eine verbesserte Darstellung, wenn der Screenshot verkleinert dargestellt wird
• Es gibt ein Optionsdialog für den Tutorial Builder

In den Optionen wird man nun die Einstellungen des Tutorial Builders finden. Ich habe mich dazu entschlossen eine Hauptkategorie zu erstellen, da ich selbst für den Tutorial Builder jede Menge Unter-Registerzungen habe.

In der Unterkategorie Darstellung können grundlegende Einstellungen vorgenommen werden:

Wie man sieht, ist es nun möglich, die Tastenkombinationen für die unterschiedlichen Screenshot-Aktionen einzustellen. Da einige Tasten nicht einfach einzugeben sind, muss man den [...] Button dafür verwenden. Ansonsten einfach in das Textfeld Klick und z.B. Strg+F10 drücken.

Die Einstellung für den Doppelklick auf das Statusleistensymbol wird im nächsten Update aktiviert. Das ist noch nicht fertig geworden.

In der zweiten Unterkategorie "Werkzeuge" werden in Zukunft alle Optionen der Werkzeuge des Vorschaufensters vereinigt. Im Moment ist dort nur das Lens-Werkzeug. Die anderen bestehenden Werkzeuge (Zuschneiden usw.) werden noch umprogrammiert...

Durch die Erweiterung mit Optionen und Werkzeugeinstellungen gab es ziemlich große Umstellungen im Quelltext. Aber so kann jedes Werkzeug in Zukunft seine Einstellungen global registrieren, die ich dann im Options-Dialog anzeige.

Bekannte Probleme

Move-Up und Move-Down der Screenshots aktualisieren immer noch nicht die Selektion...

Java 1.6 ist Voraussetzung.

Wenn man nun die Screenshots mit den Pfeiltasten sortiert, aktualisiert sich nicht korrekt die Selektion der Screenshots.

Es gibt neuerdings eine Racecondition bei der Darstellung des Screenshots. Manchmal vergrößert sich die Vorschau nicht vollständig. Workaround: In der Galerie deselektieren und wieder selektieren. Ich habe da zu viel optimiert und es scheint nicht 100% Threadsafe zu sein.

Es ist noch nicht alles 100% in Deutsch/Englisch übersetzt.

Download

Das Update ist im Update-Center seit gestern verfügbar. Ansonsten gilt wie immer: Dieser Download-Link.

Beste Grüße,
  Josch.

Hi!

Updateinformation

Mit dem Update auf 1.0.5 werden ein paar nützliche Features hinzugefügt.

Regionen Viewer

Was ursprünglich eine Combobox war ist nun zu einer JList mutiert und hat einen eigenen Bereich rechts neben dem Vorschaubild erhalten. Man kann den Regionen Viewer auch ausblenden, wenn er zu viel Platz verbraucht.

Der Vorteil ist, dass man einfach schneller einen bekannten Bereich auswählen kann, um diesen zuzuschneiden.

Mouse Gestures

Der Doppelklick wird nun massiv unterstützt. Doppelklick in den Regionen-Viewer und Doppelklick auf ein angezeigtes Areal im Vorschaubild erzeugen immer einen neuen Zuschnitt. Schneller geht es jetzt wohl nicht mehr.

Hoover

Es gibt einen Hoover-Effekt, den man mit dem neuen Werkzeug im Regionen-Viewer aktivieren kann. Wenn das Werkzeug aktiv ist, wird unter der Maus ein hellgrüner Bereich dargestellt und wechselweise mit dem Region-Viewer synchronisiert. Somit kann man im Vorschaufenster eine Zuschnittsregion sehr schnell ausmachen und per Doppelklick herausschneiden.

Toolbars und Statusbar

Der Regionen-Viewer zeigt nun auch alle Toolbars und die Statusleiste mit ihren Elementen an. Somit kann man jede Toolbar für sich ausschneiden. Auch auf Wunsch jedes einzelne Statusline-Element.

Lupe

Die Lupe blendet sich nun automatisch aus, wenn die Maus das Vorschaufenster verlässt.

Bekannte Probleme

Wenn man mehrere Screenshots auf einmal speichert, wird die Ersetzungsregel im Speicherdialog verwendet. Allerdings kann das im Moment zu Problemen führen, wenn die Bereichsnamen Sonderzeichen enthalten (z.B. das Property-Fenster, wenn man Favoriten markiert hat). Man muss dann diese Screenshots einzeln mit selbst festgelegten Namen exportieren.

Move-Up und Move-Down der Screenshots aktualisieren immer noch nicht die Selektion...

Java 1.6 ist Voraussetzung.

Es gibt noch keine Optionsdialog.

Schließt man dass Hinweisfenster erscheint es nach Neustart der IDE.

Download

Der Download erfolgt hier. Ansonsten bekommt man die aktuelle Version auch im AutoUpdate-Center.

Beste Grüße,
  Josch.

Hi!

Updatehinweise

Der Tutorial Builder in der Version 1.04 hat ein paar neue Features erhalten. Zusätzlich wurde die interne Umsetzung der Galerie von einer Swing-JList in eine ListView Komponente mit Nodes umgestellt. Der NodeRenderer bereitete mir zwar einige graue Haare, aber nun geht es. 

Mit der Umstellung sind nun die Toolbar-Actions der Galerie nun echte NetBeans-Actions, die man in der layer.xml konfigurieren kann. Außerdem werden nun ausgewählte Screenshots in dem Property-Fenster angezeigt. Die Entfernen-Action ist mit der Entf (Delete) - Taste verknüpft. Auch die Verschieben-Actions haben Tastenkürzel. Infos zeigen die Tooltips dazu an.

Aber auch bei der Erkennung von "Well-Known-Areas" gibt es Fortschritte. Nun werden alle Popup-Menus (Menüs bei rechter Maustaste) erkannt. Inkl. der HeavyWeight Menüs, die aus dem Fenster herausragen. Auch dort kann man nun echte Clipping-Areas als Zuschnitt verwenden.

Das Menü in der Statusleiste hat Zuwachs bekommen: Man kann nun das Hauptfenster in bestimmte Größen zwingen. Ein paar Vorgaben hat das Menü, aber man darf auch eigene Pixel-Breiten/Höhen in einem Dialog festlegen. Sinn dieser Funktion ist es, einheitliche Hauptfenstergrößen für Tutorials zu erreichen. Gerade in Blogs möchte man z.B. nur exakte 800px Breite haben, und das möglichst über mehrere Tutorials hinweg.

Die ComboBox mit den Well-Known Regionen nimmt nicht mehr die komplette Vorschaubreite ein. Außerdem habe ich teilweise einen Wunsch von "Arno.Nyhme" aufgenommen. Wenn man mit der Maus über die ComboBox-Einträge wandert, wird der Hoover-Bereich im Vorschaufenster markiert. Für die Mausbewegung über der Vorschau wird ein Hoover, in einem zukünftigen Update, noch hinzugefügt (den müsste man dann aber explizit aktivieren).

Ein weiterer Wunsch war, den manuellen Zuschnitt sofort per Doppelklick durchzuführen. Auch das ist implementiert.

Bekannte Probleme

Einen Backport zu Java 1.5 ist leider noch nicht möglich. Eine statische Methode Frame.getWindows() wird benötigt, um die HeavyWeight-Popup-Menüs und Dialog-Fenster zu finden. Ich weiß leider noch nicht, wie man das in 1.5 abbilden könnte.

Wenn man nun die Screenshots mit den Pfeiltasten sortiert, aktualisiert sich nicht korrekt die Selektion der Screenshots. Wird bestimmt im nächsten Update korrigiert.

Toolbars werden noch nicht als bekannte Bereiche erkannt.

Das Hilfefenster aktualisiert auf manchen Systemen nicht die kontextsensitiven Hilfen. Da läuft noch was mit dem Laden des ServiceProviders schief. Wird in 1.0.5 korrigiert. Ärgerlich ist, dass das in der Testuserdir-Umgebung funktioniert, nur nicht deterministisch in der IDE...

Noch ein paar Tipps zur Version 1.0.3 und 1.04:

Man kann alternative Tastenkürzel hinzufügen: Tools -> Options -> Keymap. Nach "Bild" (oder "Screen" in der englischen Version) suchen und dann einen Shortcut hinzufügen. Dann kann man zusätzlich zu Printscreen andere Tasten verwenden. Die über die Keymap konfigurierten Tasten funktionieren aber nicht in modalen Dialogen. Dann muss man doch die Bildschirm-Druck Taste verwenden.

Man kann einen Screenshot auch mit Doppelklick auf das Kamerasymbol in der Statusleiste auslösen.

Update/Download

Wer die älteren Version 1.0.2 und 1.0.3 hatte, erhält das Update über das AutoUpdate-Center. Ansonsten gilt immer noch dieser Download-Link.

Infos im Blog

Ich habe die Blog-Einträge zu dem Tutorial-Builder unter einer Blog-Kategorie zusammengefasst. Alle Aktualisierungen finden sich unter diesem Link: TutorialBuilder.

Beste Grüße,
  Josch.

Moin!

Die neue Version des Tutorial Builders ist verfügbar.

Änderungen:

• Neben der Snapshot Kamera in der Statusleiste wird die Anzahl der Bilder in der Galerie angezeigt.
• Nach einem Snapshot gibt es eine kurze Info in der Statusleiste
• Lokalisierung in Deutsch (teilweise!)
• Lupe mit 4-facher Vergrößerung für die Bildervorschau, wenn man mit der Maus drüber wandert
• Und das Wichtigste:
  Manuelle Zuschnitte mit der Maus
• Da das Ausschnittswerkzeug einer Erklärung bedarf, gibt es noch oben drauf (zum selben Preis!) eine kontextsensitive Hinweisbox. Das manuelle Zuschneiden hat nämlich noch zwei Tastaturbefehle, die mit der Hinweisbox erklärt werden.

Alle, die schon Version 1.02 haben, erhalten das Update über das Auto-Update Center. Einfach in dem IDE Hilfe Menü nach Updates suchen.

Für Neueinsteiger gilt wie immer dieser Link: Download Tutorial Builder.

Beste Grüße,
   Josch.

Der Begriff Extension Point wird in der Eclipse Welt so inflationär verwendet, dass man meinen könnte in der NetBeans Platform würde so etwas nicht existieren. Dabei ist das nicht richtig, im Gegenteil. Es gibt so viele Möglichkeiten, dass man als Modulentwickler schon mal etwas überfordert ist.

Möchte man selber Extension Points anbieten, muss man sich sowieso zwangsläufig damit beschäftigen. Aber es ist einfacher als man denkt. Der Modul-Assistent legt bei Wunsch schon eine deklarative Schnittstelle an, in der man eigene Objekte global registrieren kann. Die globalen Bekanntmachungen können von anderen Modulen aufgegriffen, erweitert und sogar ausgeblendet werden. Umgekehrt habe ich aus meinem Modul die Möglichkeit auch anderen Modulen in die Registrierung einzugreifen (Menüs ausblenden oder neue hinzufügen, Tastenkürzel anpassen, Toolbars verändern, Paletten anreichern, Lokalisierungen vornehmen, usw usf.).

Hier geht es aber mal erstmal darum selber Extension-Points anzubieten.

Wie schon gesagt, auf Wunsch wird eine XML-Datei zum Modul erzeugt und diese XML-Datei als deklarativer Ansprungspunkt registriert. Die Info, dass es eine (sogenannte) Layer Datei gibt, erfolgt in der MANIFEST.MF:

OpenIDE-Module-Layer: org/sepix/tutorialbuilder/layer.xml

Damit muss eine Datei namens layer.xml im Paket org.sepix.tutorialbuilder existieren. Diese Datei enthält zunächst nur den Struktureintrag <filesystem></filesystem>.

In meinem (gar nicht so fiktiven) Modul habe ich ein Icon in der Statusleiste registriert und möchte dort per Mausklick ein Popup-Menu darstellen. Das möchte ich selbst einfach aufbauen können und auch anderen Entwicklern die Möglichkeit bieten dieses Menü zu erweitern/verändern.

Ich füge dafür folgende Einträge zwischen <filesystem></filesystem> ein:

    <folder name="org-sepix-tutbuilder">
      <folder name="Menu">
      </folder>
    </folder>

Es bietet sich immer an, für ein Modul als Root-Folder den eigenen Paket-Namen zu verwenden. Ansonsten kommt es ggf. zu unerwünschten Überdeckungen in der globalen Registry. Schließlich werden alle Layer-Dateien aller aktiven Module zu einem großen globalen Lookup zusammengestellt.

Irgendwo in meinem Modul gibt es nun einen MouseListener, der darauf wartet, dass der Anwender das Statusleisten-Icon anklickt. Dann baue ich eine Popup-Menü zusammen:

    JPopupMenu menu = new JPopupMenu();
    Lookup lookup = Lookups.forPath("org-sepix-tutbuilder/Menu");
    for (Action a : lookup.lookupAll (Action.class)) {
      menu.add(new JMenuItem (a));
    }

Der Aufruf Lookups.forPath("org-sepix-tutbuilder/Menu") liefert mir umgehend ein Lookup (das ist ein "Korb" von Objekten) auf mein Menu-Folder. Mit lookupAll (Action.class) will ich aus dem "Korb" nun alle Objekte mit der Super-Klasse javax.swing.Action. Aus den Actions bastele ich mit Menü-Einträge und füge diese dem Popup-Menü hinzu.

Wenn ich nicht nur Actions in dem Folder habe, sondern auch andere Objekte, sieht das nur unwesentlich komplizierter aus:

    JPopupMenu menu = new JPopupMenu();
    Lookup lookup = Lookups.forPath("org-sepix-tutbuilder/Menu");
    Collection c = lookup.lookupAll (Object.class);
    for (Object next : c) {
      if (next instanceof Action) {
        JMenuItem item = new JMenuItem ((Action)next);
        menu.add(item);
      } else if (next instanceof JSeparator) {
        JSeparator item = (JSeparator)next;
        menu.add(item);
      }
    }

Mit lookupAll (Object.class) muss ich mich dann aber selber darum kümmern, welche Objekte mir in der Collection angeboten werden.

Wenn ich jetzt mein Modul teste, wird das Popup-Menü etwas traurig sein. Kein Wunder. In meiner layer.xml sind ja auch keine Actions vorhanden. Die werden da auch nicht direkt eingetragen. In der NetBeans Platform werden alle Actions zentral registriert. Dazu nutze ich den "New Action" Assistenten. Dieser erzeugt mir ebenfalls in meiner layer.xml einige Einträge und eine ActionListener-Klasse:

    <folder name="Actions">
        <folder name="Help">
            <file name="org-sepix-tutorialbuilder-ui-ScreenShotAction.instance">
                <attr name="SystemFileSystem.localizingBundle" stringvalue="org.sepix.tutorialbuilder.Bundle"/>
                <attr name="delegate" newvalue="org.sepix.tutorialbuilder.ui.ScreenShotAction"/>
                <attr name="displayName" bundlevalue="org.sepix.tutorialbuilder.ui.Bundle#CTL_ScreenShotAction"/>
                <attr name="iconBase" stringvalue="org/sepix/tutorialbuilder/res/statusicon.gif"/>
                <attr name="instanceCreate" methodvalue="org.openide.awt.Actions.alwaysEnabled"/>
                <attr name="noIconInMenu" boolvalue="false"/>
            </file>
        </folder>
    </folder>

Das Attribut "delegate" verweist übrigens auf die reale Klasse ScreenShotAction die aber nichts anderes als ein Object implements ActionListener ist (also in Wirklichkeit keine javax.swing.Action).

Wie komme ich aber an meine Action ran, die ich dem Popup-Menü hinzufügen will? Durch Magie. Oder besser gesagt, der automatischen Erstellung von Actions aus Layer.xml-Einträgen durch die NetBeans Platform. Alle global registrierten Actions werden nämlich auf Wunsch in echte Action-Objekte ins Leben gerufen. Das geht aber nur, wenn man sie eben in dem Root-Folder "Actions" einträgt und diese Bekanntmachungen als symbolische Links an anderen Stellen "überträgt". Damit kommen wir zu den shadow-Links.

Also, der "New Action"-Assistent erzeugt mir eine globale Registrierung einer Klasse, die nichts anderes ist als ein ActionListener. Diese Klasse soll aber in meinem Popup-Menü liegen. Also füge ich in meinem Menü einen Link zu dieser globalen Registrierung ein:

    <folder name="org-sepix-tutbuilder">
      <folder name="Menu">
        <file name="org-sepix-tutorialbuilder-ui-ScreenShotAction.shadow">
          <attr name="originalFile" stringvalue="Actions/Help/org-sepix-tutorialbuilder-ui-ScreenShotAction.instance"/>
        </file>
      </folder>
    </folder>

Und (taaaraaa) nun habe ich in meinem Popup-Menü auch eine echte Action liegen (nicht nur einen ActionListener), weil NetBeans bei shadow-Anforderungen automatisch ein Wrapper-Objekt erzeugt (was als Superklasse eine javax.swing.Action ist) und ActionEvents an den ActionListener delegiert.

Das sieht ungeheuer kompliziert aus, um ein Popup aufzubauen. Aber doch auch schlüssig. Jetzt gibt es eine zentrale Deklaration von einer Action. Der Anwender findet diese in den Optionen zur Keymap wieder und darf beliebige Tastenkürzel hinzufügen. Andere Modulprogrammierer können ebenfalls diese Action manipulieren (sogar austauschen). Zusätzlich habe ich mit meinem Extension-Point eine Möglichkeit geboten Menüeinträge hinzufügen zu lassen.

Denn jetzt kann ein anderes Modul in "seiner" layer.xml folgendes machen:

   <folder name="org-sepix-tutbuilder">
      <folder name="Menu">
        <file name="other-company-ui-GalleryAction.shadow">
          <attr name="originalFile" stringvalue="Actions/Window/other-company-ui-GalleryAction.instance"/>
        </file>
      </folder>
   </folder>

Damit ist in meinem Popup-Menü ein neuer Eintrag hinzugefügt worden. Mein Modul wurde also erweitert. Und nur so können eigene Entwicklungen in dem Ökosystem NetBeans Platform bestehen: Nicht durch Abkapselung, sondern durch Offenheit und Extension Points. Man kann selber die eigenen Module besser erweitern und fremde Entwickler fügen Funktionen hinzu, an die man selber vielleicht nie gedacht hatte.

Beste Grüße,
  Josch.

In einer internen Mailingliste hatte ich es schon angekündigt. Ich entwickle ein Plugin, damit man innerhalb von NetBeans und Platform-Anwendungen sehr einfach Tutorials erzeugen kann.

Der erste Schritt ist gemacht. Der Tutorial Builder kann nun Screenshots erzeugen und bietet eine sehr schnell zu bedienendes Crop-Tool (Ausschnitte von Screenshots).

Nach der Installation des Plugins hat man in der Statusleiste einen kleinen Fotoapparat. Per Klick gibt es ein Popup-Menü mit "Gallery" und "Screen capture". Der Menüpunkt "Screen capture" kann auch über der Printscreen-Taste ausgelöst werden (auf deutschen Tastaturlayouts: Druck S-Abf...).

Der Capture wird mit einer Sekunde verzögert ausgeführt und steht dann in der Gallery zur Verfügung. Es können beliebig viele Screenshots erzeugt werden. Diese können in der Gallery sortiert und wieder entfernt werden.

Ein besonderes Feature ist aber der Befehl Crop. Wählt man ein Bild in der Gallery aus, erscheint dieses (ggf. verkleinert) in der Vorschau. Über dem Vorschau-Bild ist eine Combobox mit allen ermittelten Clipping-Regionen des NetBeans-Fensters. Einfach mal unterschiedliche Regionen auswählen. In der Vorschau erscheint dafür ein roter Rahmen. Mit dem Mausklick auf "Crop" (rechts neben der Combobox) wird dieser Ausschnitt der Gallery neu hinzugefügt.

Für aufgeklappte Menüs bietet die Auswahl an Regionen sogar ein "nichtrechteckiges", also polygonales Clipping an, damit man keinen störenden Fensterhintergrund hat, wenn man Menüverschachtelungen darstellen will.

Die so erzeugten Screenshots können auch als PNG-Dateien gespeichert werden. Alle gewünschten Bilder markieren, den Speicherbutton in der Gallery anklicken, einen Ort festlegen und speichern. Polygonale Clippings sind in den freien Bereichen transparent.

Damit habe ich nun Meilenstein 1 erreicht.

Mit der weiteren Entwicklung werden folgende Features hinzugefügt (ohne bestimmte Reihenfolge):

• [Erledigt] Manuelle Clippings (wie in einem Grafik-Programm)
• Snapping für manuelle Clippings (auch wieder an bekannten Komponentengrenzen)
• Umbenennen von Screenshots schon in der Gallery
• [Angefangen] Mehrsprachigkeit
• Hinzufügen von Kommentaren "in" den Screenshots
• Hinzufügen von grafischen Elementen in den Screenshots

• Zu den Screenshots sollen Kommentare und Kurztexte sowie Sourcecode hinzuzufügen sein
• Kommentare mit Stilen (fett, kursiv, ...)

• Export der komponierten Gallery (mit Texten) als PDF, ODF (Writer und Presentation), HTML (damit wird es zum echten Tutorial Builder)
• Export als Java Help
• Export als NetBeans RCP Java-Help Projektteil

• [Angefangen] Ausbau von Extensionpoints, damit fremde Modulentwickler zusätzliche Funktionen (z.B. Grafikbearbeitung, Exportformate) hinzufügen können.

Und ja klar: Hier ist der Download. Und noch mein Disclaimer: BETA, nicht auf allen OS und allen NB Versionen getestet (mind. 6.7 erforderlich). Support gibt es nicht, aber ich freue mich über Feedback - auch über Fehlermeldungen. Für Mac-User eine gute Nachricht: Java-Abhängigkeit ist nun >= 1.5

So, nun hat die aktuelle Version ein Update-Center. Für Neuerungen muss man nicht mehr immer hier ungeduldig reinschauen. Wer das Update-Center von Hand eintragen will: http://www.sepix.de/fileadmin/tutorialbuilder/updates.xml

Bitte diese Update-Hinweise beachten für 1.0.3.

Bitte diese Update-Hinweise beachten für 1.0.4.

Bitte diese Update-Hinweise beachten für 1.0.5.

Beste Grüße,
  Josch.

Gerade hab' ich eine witzige Fehlermeldung in meiner IDE gefunden:

WARNUNG [org.openide.util.lookup.MetaInfServicesLookup]: org.sepix.tutorialbuilder.api.ScreenCaptureProvider is not the real McCoy! Actually found it in ModuleCL@ae678a[org.sepix.tutorialbuilder]

Das kann passieren, wenn man Plugins in der eigenen IDE testet und man mit der ServiceProvider Annotation arbeitet. Es kann wohl passieren, dass die registrierten Services in einem Plugin in der aktuellen IDE nicht immer ausgetauscht werden.

Dann muss man entweder in einer neuen IDE Instanz testen oder (wenn man unbedingt in der aktuellen IDE etwas probieren muss), neu starten.

Beste Grüße,
  Josch.

PS: Elijah McCoy

In einem älteren Blog für die platform8 hatte ich eine Möglichkeit ausgearbeitet eine RCP Anwendung neu zu starten.

Jesse Glick verweist auf eine Neuerung in 6.7 / 6.8 (für 6.8 wohl dann mit eigener API), die mit der Besonderheit des AutoUpdate Center arbeitet.

Jesse zeigt in diesem Issue die Kennzeichnung eines Neustarts:

File targetUserdir = new File(System.getProperty("netbeans.user"));
File restartFile = new File(targetUserdir, "var/restart");
if (!restartFile.exists()) {
    restartFile.createNewFile();
}

Man muss also nur eine Datei namens restart in den var-Bereich schreiben und dann die Anwendung neu starten.

Der Neustart erfolgt wie gewohnt mit dem LifecycleManager.getDefault().exit().

Wenn man den Neustart nicht direkt per Action initiieren will, sondern als Vorschlag für den Anwender angezeigt werden soll, dann hat man mit der platform10 (seit NetBeans 6.7) noch ein zusätzliches nettes Feature. Man kann ein Icon in der Statuszeile einblenden lassen, der den User darüber informiert, dass es sinnvoll wäre die Anwendung einmal durchzustarten.

Hier ein adaptiertes Beispiel aus einem anderen Blog:

@org.openide.util.lookup.ServiceProvider(service=org.openide.awt.StatusLineElementProvider.class, position=610)
public class RestartNotification implements org.openide.awt.StatusLineElementProvider {
  public Component getStatusLineElement () {
      ImageIcon img = new ImageIcon (ImageUtilities.loadImage ("org/netbeans/modules/mymodule/restart.png", false));
      JPanel p = new StatusLinePanel (img);
      p.setVisible (false);
      return p;
  }

  public static class StatusLinePanel extends JPanel {
    private ImageIcon icon = null;
    public StatusLinePanel (ImageIcon img) {
      icon = img;
    }

    @Override
    public void addNotify () {
      this.addMouseListener (new MouseListener () {
        public void mouseClicked (MouseEvent e) {
          if (isVisible ()) {
            File targetUserdir = new File(System.getProperty("netbeans.user"));
            File restartFile = new File(targetUserdir, "var/restart");
            if (!restartFile.exists()) {
              restartFile.createNewFile();
            }
            LifecycleManager.getDefault().exit();
          }
        }
        public void mousePressed (MouseEvent e) {}
        public void mouseReleased (MouseEvent e) {}
        public void mouseEntered (MouseEvent e) {}
        public void mouseExited (MouseEvent e) {}
      });
    }

    @Override
    public void paint (java.awt.Graphics g) {
      if (isVisible ()) {
        icon.paintIcon (this, g, 0, 0);
      }
    }
  }
}

Da RestartNotification von Applikations-Start an in der Statusbar registriert ist, wird diese erstmal mit setVisible (false) abgeschaltet. Wenn man den Neustart nun benötigt, holt man sich das Object aus dem globalen Lookup-Pool:

RestartNotification rn = Lookup.getDefault.lookup(RestartNotification.class);
rn.getStatusLineElement().setVisible(true);

Der Vorteil dieser neuen Methode ist, dass man keine OS-abhängigen Bestandteile mehr berücksichtigen muss. Auch muss man nicht mehr den Namen des Launchers kennen.

Beste Grüße,
  Josch.

Nur wenige Stunden ist es her, als das deutsche NetBeans Forum, plötzlich und unerwartet in einem komplett neuen Look erschien. "Smurfi" (Michael, auch hier mit einem DZone Interview), hat mal das komplette Forum auf den neuesten (und damit auch Sicherheits-) Stand gebracht.

Was natürlich bleibt, ist die große Vielfalt an Unterforen - nicht nur Java und die NetBeans IDE sondern auch zu PHP, JavaFX und Glassfish. Und die freundliche deutschsprachige Community, die das Vorhaben mit großem Spaß unterstützt!

Beste Grüße,
  Josch.

Mit der IDE Version 6.7 gibt es auch eine neue Platform Version 10. Und mit jedem Update der Platform kommt für die Entwickler auch die Arbeit (oder Freude) die RCP Entwicklungen mit neuen Features anzureichern. 

Eine sehr schöne Funktionailtät ist das neue Importieren und Exportieren von Optionen. Wie immer im deklarativen Ansatz und modulorientiert.

Man kann nun in der layer.xml festlegen, welche Optionen des eigenen Moduls vom Anwender zu exportieren sind. Diese darf er beliebig häufig in andere Programmversionen importieren. Das ist praktisch für Backups und für Programme auf verschiedenen Rechnern.

Nebenbei erhält man noch einen automatischen Import-Dialog für Moduloptionen, wenn man eine neue Version installiert. Die IDE macht es mit Version 6.7 schon vor.

Grundsätzlich ist es notwendig, dass man seine Optionen schon seit je her mit NbPreferences speichert, damit diese im config/* Ordner aufschlagen. Aber auch andere Speicherorte von Dateien wären möglich, soweit es Dateien sind, die als Ablageort von Eigenschaften verwendet werden. Was für das Dateien letztendlich sind, ist auch egal. Der Export zippt nur die Daten und interpretiert nichts. Dem Import ist auch herzlich egal, was in den Dateien stand.

Jeder Modul-Entwickler kann seine eigenen Export-Definitionen festlegen. In der layer.xml muss dazu ein Folder namens OptionsExport angelegt werden. In diesem Ordner muss ein Unterordner eingefügt werden, der die eigenen Export-Definitionen als File deklariert. Tiefere Unterordner (zur Gruppierung) werden ignoriert.

Hier ein kleines Beispiel:

<folder name="OptionsExport">
    <!-- Meine Kategorie im Export -->
    <folder name="Mapping">
        <!-- Lokalisierte Darstellung der Kategorie-->
        <attr name="displayName"
          bundlevalue="de/sepix/mapping.options.Bundle#Category_Display_Name"/>
        <!-- item -->
        <file name="mapOpt">
            <!-- Lokalisierte Darstellung des Export-Elements-->
            <attr name="displayName"
              bundlevalue="de/sepix/mapping.options.Bundle#Export_Display_Name"/>
            <attr name="include"
              stringvalue="config/Preferences/de/sepix/mapping/settings(.*?)\.properties"/>
        </file>
    </folder>
</folder>

Mit der obigen Konfig wird eine Export-Kategorie mit dem internen Namen Mapping angelegt. Dargestellt wird aber der Text aus dem ResourceBundle mit dem Schlüssel Category_Display_Name. Unter dieser Kategorie wird eine Export-Definition mit einem include deklariert. Es ist ein regulärer Ausdruck für Dateinamen.

Man darf übrigens auch per exclude Dateien ausschließen.

Grundsätzlich zeigt so schon die Platform im Export-Dialog die Kategorie mit der Exportdefinition an. Wenn aber keine Dateien existieren, die mit include/exclude gefunden werden sollten, ist der Bereich in Export-Dialog deaktiviert. Finden sich aber Dateien, kann der Anwender, diese auch zum Exportieren auswählen. 

So sieht das letztendlich aus:

Wählt man eine Datei zum Importieren aus, kann der Anwender nur die Kategorien auswählen, die tatsächlich in der ZIP-Datei liegen.

Weitere Informationen finden sich dazu im NetBeans Wiki.

Beste Grüße,
  Josch.

Für viele im nichtenglischsprachigen Raum ist es eine Erleichterung, dass NetBeans 6.7 seit dem RC1 mehrsprachig ausgeliefert wird. D.h. für viele Sprachen sind schon die passenden Resource-Bundle-Dateien mitgeliefert. 

Welche Sprachen das sind, kann man mal im platform10/modules/locale Ordner nachprüfen. Französisch, Spanisch, Deutsch, Niederländisch, Polnisch, Russisch... alles dabei.

De Java-VM selbst gibt die Spracheinstellungen vor, die sie sich einfach aus dem Locale des Betriebsystems zieht. Java legt diese Information in den beiden System Properties user.language und user.country an.

Damit kommen wir schon zu einer Problemlösung. Manche wollen nämlich lieber mit der englischen Oberfläche arbeiten - aus Gewohnheitssache, oder weil man im Team mehrsprachig ist und sich auf eine Sprache geeinigt hat.

Man überschreibt einfach die Java-VM Vorgaben, in dem man in der der netbeans.conf den Parameter netbeans_default_options am Ende um folgende Optionen erweitert:

-J-Duser.country=US -J-Duser.language=en

Die netbeans.conf findet sich im etc-Ordner der NetBeans-Installation.

Beim Neustart von NetBeans 6.7 ist dann die komplette Oberfläche in englischer Sprache.

Beste Grüße,
  Josch.

Das Ausgabe (Output) Fenster der neuen NetBeans IDE 6.7 hat ein paar kleine Überraschungen parat. 

Augenfällig ist die Farbe bei einem Build. Ant-Target-Namen erscheinen nun in Hellgrau, Echo-Ausgaben in Schwarz und auch rote und grüne Zeilen sind zu finden. Wer sich mit der Platform-API beschäftigt und eigene Plugins schreibt kann auch selber farbige Ausgaben in das Output-Fenster bringen.

Allerdings werden ANSI-Konsolen Spiele immer noch nicht möglich sein ;-)

Für den IDE Endanwender gibt es aber noch ein paar zusätzliche Features: Man kann nun die Schriftgröße und die Schriftart verändern. Entweder per Kontextmenü (rechte Maustaste in das Ausgabefenster) oder Tastenkürzel: Strg+- verkleinert und Strg+= vergrößert. Und damit kommen wir zu einem Problem mit deutschem Tastaturlayout. Nur Strg+- funktioniert... (ändern lassen sich hier die Tastenkürzel nicht)

Über die Menüfunktion "Schrift wählen" kann eine gänzlich andere Schriftart (und Größe) gewählt oder auf die Standardschrift zurückgesetzt werden.

Aber richtig genial ist die neue Filter-Funktion (Strg+G). Mit ihr kann man die Ausgabezeilen einfach und schnell filtern. Strg+G -> Text eingeben, Enter und schon werden nur noch die Zeilen mit der beinhalteten Suchzeichenkette angezeigt. Auf Wunsch wird der Suchfilter auch als Regular Expression behandelt.

Man sieht also, dass auch in kleinen Dingen die IDE immer weiter entwickelt wird. Und gerade so kleine Features erleichtern einem das Leben wirklich.

Beste Grüße,
  Josch.

Die letzten Monate war ich etwas "Busy" und steckte in ein paar Projekten. Damit lag das Blog etwas brach. Aber so habe ich jetzt die Möglichkeit ein paar Dinge nachzuholen und die Schlagzahl etwas zu erhöhen.

Die neue Beta-Version von NetBeans 6.7 ist seit einigen Tagen endlich auf meiner Festplatte gelandet (viel zu spät, ich hätte mich schon mit den M-Kandidaten befassen müssen) und finde lauter schöne neue Dinge.

Aber auch Sachen, da bin ich etwas überrascht - nicht nur im Positiven. Wer versucht, das Issue-Tracker Modul mit NetBeans Issuezilla zu verknüpfen, muss feststellen, dass man - egal welche URL angegeben wird - immer nur mit Fehlermeldungen bei der Testverbindung bestraft wird.

Der Grund liegt an der Inkompatibilität zwischen Bugzilla und Issuezilla. Das Bugzilla-Plugin kann den Fork Issuezilla nicht bedienen. Schade eigentlich. Und m.E. etwas unverständlich, da doch gerade NetBeans Issuezilla verwendet.

Beste Grüße,
  Josch.

Einer der richtig schönen neuen Features von NetBeans 6.7 (jetzt als beta zu erhalten) ist, Werte während des Debuggens mit konfigurierten Formatierungs-Befehlen anzuzeigen.

Ich programmiere zur Zeit einen DayPlanner und habe naturgemäß viel mit java.util.Calendar zu tun. Dessen toString()-Methode ist mehr als geschwätzig und hilft mir, für einen schnellen Überblick, wenig.

Also mal schnell: Extras -> Optionen -> Verschiedenes -> Java Debugger geöffnet. Mit [Add...] kann man eine neue Formatierung anlegen. Hier ein einfaches Beispiel für java.util.Calendar:

Wenn man nun den Debugger anwirft, zeigt mir NetBeans an einem Breakpoint alle Calendar-Variablen mit meinem neuen Formatter an:

Übrigens, das Symbol mit dem Schraubenschlüssel öffnet direkt aus dem Debugger-Fenster die Formatter-Optionen.

Beste Grüße,
  Josch.

Eine spannende Darstellung, wie die Entwicklung von NetBeans vorangeschritten ist, findet sich unter diesem Link.

Die Berechnung für den Code-Swarm wurde aus den CVS-History Daten von 1998 bis 2008 erstellt. Danach wurde das NetBeans Projekt in das Mecurial Repositiory verschoben.

Viel Spaß beim anschauen und zuhören...

Josch.

Am 12. Februar folgte ich einer Einladung zu der Java User Group Nürnberg. Ich wurde gefragt, ob ich ein wenig über NetBeans, dem Swing GUI Builder, BeansBinding und JPA erzählen könnte.

Nun ja, ein weites Feld könnte man da sagen. Für den Tag habe ich drei aufbauende Präsentationen und einiges an Demoapplikationen vorbereitet. Die Zeit von 18:00 Uhr bis 19:45 reichte natürlich nicht, aber es hat mich sehr gefreut, dass die Hälfte der ca. 40 Zuhöhrer bis halb Zehn durchgehalten haben.

Im ersten Teil zeigte ich das Swing Application Framework, mit dem man deutlich einfacher Swing Anwendungen von Null auf programmieren kann. Viele Standardprobleme von Swing (und Applikationen allgemein) werden von dem Framework abgefangen. Zum Beispiel Lifecycle-Management, Persistens von Applikations-Sessions, Task-Verwaltung, vereinfachte Bindung von Actions und Ressource-Injection.
Insbesondere die NetBeans-Integration wurde gezeigt. 

Der zweite Teil befasste sich mit dem BeansBinding Framework. In kleinen Beispielen (mit und ohne NetBeans-Integration) bekamen die Zuschauer ein Bild davon, wo BeansBinding sinnvoll einzusetzen ist und welche Arbeitserleichterung BeansBinding bietet. Insbesondere in der Problematik der Bindung von Swing-Komponenten mit Beans. Das BeansBinding Framework verinfacht solche Bindungen durch vorgefertigte Adapter, die über Factory-Methoden erzeugt werden können. Besonders mit JTables eine Vereinfachung.

Mit dem dritten Teil wurde zu dem Swing Application Framework und BeansBinding die Java Persistence API hinzugefügt. Ich war erstaunt, dass viele Teilnehmer sich gar nicht bewusst waren, dass JPA auch problemlos in Java Desktop Anwendungen eingesetzt werden kann. Die meisten gingen davon aus, dass man unbedingt einen Server-Container (Glassfish, JBoss, ...) dafür benötigt.
Ich gab noch mal einen winzigen Überblick von JPA und zeigte dann, wie BeansBinding mit JPA und Swing-Komponenten realisiert wird. In Demos wurde eine kleine CRUD-Anwendung aufgebaut.

Ich möchte mich nochmal herzlich für die vielen Fragen und die Aufmerksamkeit bedanken. Es hat mir viel Spaß bereitet den Abend in Nürnberg sein zu dürfen.

Hier noch die Links zu den Präsentationen als PDF:

• Swing Application Framework
• Beans Binding
• JPA, BeansBinding und das SAF

Beste Grüße,
  Josch.

 

Die letzten zwei Tage war ich mit Geertjan Wielenga und Toni Epple als Trainer an der Universität Ulm.

Mit dem NetBeans Platform Certified Training unterstützen wir die Studenten an der Universität mit einem Einstieg in die Softwareentwicklung mit der NetBeans Platform. Am Freitag erhielten wir Verstärkung von Lorenz Weber. Er ist Student der Universität Würzburg und hatte vor einiger Zeit das Certified Training erfolgreich absolviert. Er zeigte den Studenten sein Batch Refactoring Projekt für die NetBeans IDE

Ganz besonders freuten wir uns über den Besuch von David Botterill, dem Technology Manager der Sun Campus Ambassadors. Vielleicht bringt er unsere Trainings ja über die Campus Ambassadors in die Universitäten? Das wäre fantastisch :-)

An dieser Stelle möchte ich mich auch für die hervorragende Führung durch die wunderschön Stadt Ulm bedanken. Der Organisator des Kurses, Ph. D. Guido de Melo, gab uns einen unvergesslichen Einblick in die Geschichte von Ulm mit seinen kuriosen und staunendswerten Gebäuden und Eckchen.

Folgendes Programm haben wir den Teilnehmern geboten:

• Tag 1
  • Präsentation 1: Einführung in den Kurs (Geertjan)
  • Präsentation 2: Einstieg in die NetBeans Platform (Toni)
  • Präsentation 3 + Workshop: Modular Systems & Lookup API (Geertjan)
  • Präsentation 4: System FileSystem (Toni)
  • Präsentation 5: Window System (Aljoscha)
• Tag 2
  • Präsentation 1: Nodes und Explorer Views (Aljoscha)
  • Präsentation 2 + Workshop: Visual Library (Toni)
  • Präsentation 3: Portierung einer Anwendung zur NetBeans Platform (Aljoscha)
  • Präsentation 4: Ideen für Studenten Projekte (Alle)
  • Präsentation 5: Beispiel eines Studenten Projektes: Batch Refactoring (Lorenz)
  • Präsentation 6: Zusammenfassung des Kurses (Geertjan)

Von hier aus noch mal viele Grüße an die Uni Ulm und den Teilnehmern des Kurses. Wir Trainer hatten viel Spaß und hoffen, dass es Euch gefallen hat!

Beste Grüße,
  Josch.

This blog is about unit-testing using netbeans Repository. I'm using the solution described below on Netbeans 6.5.

In my netbeans plugin-project I have code like

        Repository r = Repository.getDefault();
        FileSystem fs = r.getDefaultFileSystem();
        FileObject root = fs.getRoot();
        FileObject baseFolder = FileUtil.createFolder(root, "nb-xpath/data");
        final String foName = "history.xml";
        FileObject historyFileObject = baseFolder.getFileObject(foName);
...
        File file = FileUtil.toFile(historyFileObject);

When you try to unit-test this code, the file instance is null.

Thus I read UsingFileSystemsMasterfs, and I installed the masterfs in the UnitTestLibary. By selecting "UnitTestLibraries|Add UnitTest Dependency", selecting "Show Non-API Modules, and searching for "masterfs", and selecting the Module "Master Filesystem".

The nbproject/project.xml results :

...
            </module-dependencies>
            <test-dependencies>
                <test-type>
                    <name>unit</name>
                    <test-dependency>
                        <code-name-base>org.netbeans.modules.masterfs</code-name-base>
                        <compile-dependency/>
                    </test-dependency>
                </test-type>
            </test-dependencies>
            <public-packages/>
...

But this does not help! The file instance is still null!

After examing the Repsitory sources, I came to the conclusion that if there is no Repository registered in META-INF/services, the MemoryFileSystem is used. Thus I need a way to register some repository class.

Thanks to InitializationOfDefaultLookup, MockServices can help.

I wrote a simple Repository implementation, and register it as Repository implementation to use:

The Repository implemenation for my test-case:

    public static final class MyRepositoryIOTempDir extends Repository {

        private static final long serialVersionUID = 20090127L;

        public MyRepositoryIOTempDir() {
            this(new LocalFileSystem());
        }

        private MyRepositoryIOTempDir(LocalFileSystem lfs) {
            super(lfs);
            // make the java.io.tmpdir the root of this lfs
            final String tmpDir = System.getProperty("java.io.tmpdir");
            assertNotNull(tmpDir);
            File rootFile = new File(tmpDir);
            assertTrue(rootFile != null);
            assertTrue(rootFile.canRead());
            assertTrue(rootFile.canWrite());
            assertTrue(rootFile.isDirectory());
            try {
                lfs.setRootDirectory(rootFile);
            } catch (Exception ex) {
                AssertionError ae = new AssertionError("Cannot set root directory");
                ae.initCause(ex);
                throw ae;
            }
        }
    }

My test-case setUp registers this class like:

    @Before
    public void setUp() {
        MockServices.setServices(MyRepositoryIOTempDir.class);
        // assert that for lookup(Repository.class) MyRepositoryIOTempDir is returned
        final Repository repositoryInstance = Lookup.getDefault().lookup(Repository.class);
        assertTrue(repositoryInstance instanceof MyRepositoryIOTempDir);
    }

Now my tests can run the above code, and the file instance is not null!

Now, that I removed the Master Filesystem dependency from the Unit Test Libraries, my test-cases still work, so it seems to me that when you use File instances retrieved via Repository, you don't need the masterfs test dependency, so far.

Have fun!

Nicht nur Werbung in eigener Sache, sondern ein Hinweis auf ein doch bestimmt sehr spannendes Thema. 

Am 12. Februar bin ich in Nürnberg und bringe, den hoffentlich zahlreich anwesenden Zuhörern, die Technologien Beans Binding, Java Persistence API und Matisse im Zusammenhang mit NetBeans, nahe.

Es gibt ein wenig Theorie über Beans Binding und JPA, und ordentlich Praxis, wie das in NetBeans umgesetzt wird. Insbesondere, die Anwendung des Swing GUI-Designer mit Beans Binding wird demonstriert.

Wer am 12. Februar 2009 von 18:00 bis 19:45 Uhr Zeit hat, melde sich doch bitte kurz formlos über die folgende Mail an: info <at>  jug-ern.de

Der Veranstaltungsort ist:

ING DiBa,
Allgemeine Deutsche Direktbank AG,
Südwestpark 97,
90449 Nürnberg, Deutschland

Weitere Infos zur Java User Group Erlangen/Nürnberg finden sich auf der Homepage source-knights.de

Da der Termin rum ist, hier die Präsentationen.

Beste Grüße,
  Josch.

Die achte Auflage des Java-Kurses "Java ist auch eine Insel" ist draußen: Ein praxisorientiertes Buch nicht nur für diejenigen, die beim Brennball in der Schule immer als letztes gewählt wurden! (He... woher weiss der das?)

Das Buch erwähnt (empfiehlt) auch IDEs (z.B. auch den NetBeans GUI Builder), bleibt aber insgesamt Tool-neutral. Das hat den Vorteil, dass man das Gelernte überall einsetzen kann -- und welchem IDE-Menüpunkt das Beschriebene eventuell entspricht, findet man recht schnell raus. Anscheinend ist geplant, die achte Auflage nach und nach für JDK 7 zu aktualisieren.

Für 50 Euro bekommt man das komplette Buch auf toten Bäumen ausgedruckt -- plus eine DVD mit JDK 6, NetBeans, Eclipse, Beispielprogramme, Aufgaben und Lösungen, und sogar (hä?) ;) ein paar C/C++ Openbooks.
Das Javainsel-Ebook ist kostenlos online, und es gibt's es auch als 14MB Download zum Mitnehmen.

Wade Chandler vom NetBeans Dream Team hat eine Umfrage gestartet, um abzufragen wer BeansBinding (JSR-295) in der NetBeans IDE verwendet.

Poll: Do you use Beans Binding in the NetBeans IDE?

In der Umfrage gibt es auch eine Kommentar-Funktion. Wäre schön wenn Ihr schreiben könntet, warum Ihr BeansBinding (oder auch nicht) verwendet.


Unterstützung für BeansBinding gibt es seit Version 6.0 in NetBeans - insbesondere in dem Projekttyp "Java Desktop Application" mit dem Swing Application Framework und der Java Persistence API.


Tutorials und Screencasts zu BeansBinding (wer es noch nicht nutzt):
http://www.netbeans.org/kb/60/java/gui-binding.html
http://www.netbeans.org/kb/60/java/swing-app-beans-binding-screencast.html
http://wiki.netbeans.org/NBDemoTicker
http://www.bestechvideos.com/2008/10/29/netbeans-tv-swing-application-framework-and-beans-binding
http://wiki.netbeans.org/BestPracticesWithJPAAndBeansBinding
http://blogs.sun.com/roumen/entry/swing_application_framework_swing_databinding

Beste Grüße und vielen Dank für Eure Hilfe!
Josch.

Dieses Jahr geht es richtig ab, bei der Preisvergabe.

NetBeans hat gleich in mehreren Disziplinen gewonnen.

Development Tool

Winner: NetBeans Platform

Development Utilities

Winner: NetBeans Profiler

Wireless/Mobile

Winner: NetBeans Mobility Pack for Connected Device Configuration (CDC) 5.5

Java Tool

Winner: NetBeans IDE

Open Source

Winner: NetBeans

Beste Grüße,
  Josch.

In den letzten drei Teilen nahm das JImagePanel durchaus schöne Formen an. Nur fehlt mir noch ein Editor für das Hintergrundbild. Die einfachste Möglichkeit per Dateipfad ein Bild auszuwählen möchte ich hier besprechen.

Vorweg auch der größte Nachteil: Der Pfad ist natürlich unabhängig vom Programm. Das ist für eine Anwendung, die bei einem Nutzer installiert wird, nicht praktikabel. Zu einem späteren Zeitpunkt zeige ich aber die Möglichkeit, Bilder aus dem Projekt zu wählen. Hier im letzten Teil geht es aber zunächst nur um den Custom Editor. Eine weitere Besonderheit ist der Typ des Property: ImageIcon. Der PropertyEditor verwaltet aber nur eine Pfadangabe. Bestimmt wäre es einfacher das Property von Anfang an als Pfadangabe zu betrachten, aber im realen Leben ist es leider nicht immer zu vermeiden, dass man solche Sonderfälle zu meistern hat. Deswegen auch hier ein komplizierteres Beispiel.

Unser JavaBean JImagePanel hat das Property backgroundImage und erwartet den Typ ImageIcon. Da man dem GUI-Design-Anwender nicht zumuten kann, das Bild jedes mal neu zu zeichnen, müssen wir eine Möglichkeit bieten, dieses von der Festplatte zu laden. Natürlich könnte der Anwender auch den Pfad als Text eingeben, aber das soll ja bequem gehen.

Zunächst brauchen wir wieder einen PropertyEditor für ImageIcons. Strg+N -> Kategorie "JavaBeans Objects" -> Property Editor. Name: ImageIconPropertyEditor.

Die Java-Klasse wird dann folgendermaßen erweitert: 

package org.sepix.beandemo;

import java.beans.*;
import javax.swing.ImageIcon;

public class ImageIconPropertyEditor extends PropertyEditorSupport {
    private String pathToImage;

    @Override
    public String getJavaInitializationString() {
        if ( pathToImage != null ) {
            return "new javax.swing.ImageIcon (\"" + pathToImage.replace ('\\', '/') + "\")";
        }
        return "null";
    }

    @Override
    public String getAsText() {
        ImageIcon ii = (ImageIcon) getValue();
        if ( ii == null ) return null;
        return pathToImage;
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
        pathToImage = text;
        setValue(new ImageIcon (pathToImage));
    }
}

Im Gegensatz zum letzen PropertyEditor wird hier getTags() nicht überschrieben. Damit kann ein Anwender auch direkt einen Pfad in der Wertfeld des Properties eingeben. Die Methode getAtText() und setAsText(String) konvertieren eine Pfadangabe in ein ImageIcon. Eingehende Prüfungen auf korrekte Pfadangaben ignoriere ich erstmal (Nur Backslash wird in Slash gewandelt)

Der Property-Editor wird wieder (per BeanInfo-Editor), in der JImagePanelBeanInfo-Klasse registriert.

Gewünscht ist aber die Auswahl per Custom Editor. Dazu erstelle ich zunächst ein Customizer Panel. Strg+N -> Kategorie "JavaBeans Objects" -> Customizer. Der Name ist: ImageIconCustomizer.

So sollte der minimale Customizer dann aussehen:

package org.sepix.beandemo;

public class ImageIconCustomizer extends javax.swing.JPanel implements java.beans.Customizer {
    private Object bean;

    public ImageIconCustomizer() {
        initComponents();
    }
    public void setObject(Object bean) {
        this.bean = bean;
    }
    private void initComponents() {                          
        setLayout(new java.awt.BorderLayout());
    }                        
}

Im Design-Modus habe ich den Customzier in dieser Art aufgebaut:

Ansonsten ist noch keine Funktion hinterlegt. Der Customizer muss aber nun im PropertyEditor hinterlegt werden:

public class ImageIconPropertyEditor extends PropertyEditorSupport {
    private String pathToImage;
    private ImageIconCustomizer customizer;
    public ImageIconPropertyEditor () {
        customizer = new ImageIconCustomizer();
    }

und am Ende folgende Methoden hinzufügen:

    @Override
    public Component getCustomEditor() {
        return customizer;
    }

    @Override
    public boolean supportsCustomEditor() {
        return true;
    }

Das war es auch schon erstmal. "Clean & Build" des Projektes. Im Test-JFrame das alte Bean entfernen und aus der Bean-Kategorie erneut hinzufügen. Jetzt kann man im Property backgroundImage den Button [...] anklicken und bekommt den selbst programmierten Customizer angeboten. Zusätzlich kann man natürlich über die ComboBox alle weiteren NetBeans-Editoren auswählen.

Die Kommunikation zwischen PropertyEditor und Customizer muss über PropertyChangeEvents erfolgen. Wenn der Customizer etwas ändert, muss dieser ein Event feuern. Der PropertyEditor setzt ohne zu zögern den Wert in das Bean ein. Zwar kann der Anwender den Customizer-Dialog abbrechen, aber um das Zurücksetzen des alten Wertes kümmert sich dann NetBeans selber.

Also erweitere ich schon mal den ImageIconPropertyEditor, um das Event-Handling:

    public ImageIconPropertyEditor() {
        customizer = new ImageIconCustomizer();
        customizer.addPropertyChangeListener(new PropertyChangeListener() {
            public void propertyChange(PropertyChangeEvent evt) {
                if ( "backgroundImage".equals(evt.getPropertyName()) ) {
                    setAsText (customizer.getPath());
                }
            }
        });
    }

Die Methode getPath() existiert im Customizer noch nicht, wird aber gleich hinzugefügt. Ich lege dazu das Feld path an, dazu noch setPath und getPath und weitere Hilfsmethoden zum Anpassen der Customizer-GUI-Ausgabe:

public class ImageIconCustomizer extends javax.swing.JPanel implements java.beans.Customizer {

    private Object bean;
    private String path;

    // ... Constructor und setObject bleibt wie es ist

    public void setPath (String path) {
        this.path = path;
        updateEditor();
        updateImage();
    }

    public String getPath () {
        return path;
    }

    private void updateUserChange (String newPath) {
        path = newPath;
        firePropertyChange("backgroundImage", null, null);
        updateEditor();
        updateImage();
    }
    
    private void updateEditor() {
        jTF_Path.setText (path != null ? path : "");
    }

    public void updateImage() {
        jLB_IconViewer.setIcon(path != null ? new ImageIcon(path) : null);
    }

Die obige Methode updateUserChange() kümmert sich um das Feuern des Events und um die passende Aktualisierung im Customizer-Dialog. Damit der Dialog überhaupt auf Benutzereingaben reagieren kann, setze ich einfach zwei Action-Listener an das Textfeld und den Button für die Pfadauswahl. In NetBeans ist das sehr einfach gemacht. Im Designer des Customizers das Textfeld markieren -> Property Window -> View Events -> In das Wertfeld von actionPerformed klicken -> jTF_PathActionPerformed mit [Enter] bestätigen. NetBeans wechselt sofort in den Quelltexteditor und ich fülle die neue Methode aus:

    private void jTF_PathActionPerformed(java.awt.event.ActionEvent evt) {                                         
      updateUserChange (jTF_Path.getText());
    }                                        

Der gleiche Vorgang mit dem Button. Im Designer des Customizers den Button markieren -> Property Window -> View Events -> In das Wertfeld von actionPerformed klicken -> jPB_ChooserActionPerformed mit [Enter] bestätigen. NetBeans wechselt erneut in den Quelltexteditor und ich fülle die zweite Methode so aus:

    private void jPB_ChooserActionPerformed(java.awt.event.ActionEvent evt) {
      JFileChooser loadFile = new JFileChooser (path);
      loadFile.setFileFilter(new FileFilter() {
            @Override
            public boolean accept(File f) {
                String name = f.getName().toLowerCase();
                return     name.endsWith(".jpg")
                        || name.endsWith(".png")
                        || name.endsWith(".gif");

            }
            @Override
            public String getDescription() {
                return "Grafikdateien";
            }
        });
      int result = loadFile.showOpenDialog(this);
      if ( result == JFileChooser.APPROVE_OPTION ) {
          updateUserChange (loadFile.getSelectedFile().getAbsolutePath());
      }
    }

(ggf. muss man nun die Imports korrigieren. Rechte Maustaste -> Fix imports...).

Das war es auch schon. Der Customizer funktioniert nun und übergibt die Benutzereingaben an den PropertyEditor. Damit kann der Customizer mit dem Editor schon erheblich mehr, als das eigentlich Bean. Denn JImagePanel macht ja nun überhaupt nichts mit den mühevoll übertragenen Daten.

Aber auch das ist schnell erledigt. Einfach folgende Methode in JImagePanel einfügen:

    @Override
    public void paintComponent(Graphics g) {
        super.paintComponent(g);
        ImageIcon background =  getBackgroundImage();
        if ( background != null ) {
            Dimension s = getSize();
            int x = 0;
            int y = 0;
            int width = background.getIconWidth();
            int height = background.getIconHeight();
            switch ( getAppearance() ) {
                case SCALE: {
                    width = s.width;
                    height = s.height;
                    break;
                }
                case CENTER: {
                    x = (s.width/2) - (width/2);
                    y = (s.height/2) - (height/2);
                    break;
                }
            }
            g.drawImage(background.getImage(), x, y, width, height, this);
        }
    }

Die Methode berücksichtigt allerdings nicht die Breite eines eingefügten Border-Objektes. Das ist aber bestimmt einfach nachzuprogrammieren.

Mit diesem kleinen Vierteiler sollte es nun möglich sein, beliebig komplexe GUI JavaBeans in NetBeans integrieren zu können. Inklusive eigenen Property-Editoren. Über Feedback würde ich mich natürlich freuen.

Beste Grüße,
  Josch.

Teil 1 | Teil 2 | Teil 3 | -> Teil 4

In diesem dritten Teil geht es ans Eingemachte. Das farbenfrohe Klicken ist vorbei, es wird programmiert.

Im vorherigen Teil habe ich den BeanInfo-Editor vorgestellt und zu der JImagePanel-Klasse nur wenige Eigenschaften freigeschaltet.

Die zwei neuen Eigenschaften backgroundImage und appearance bieten aber nur einen Komfort von zweifelhaften Wert an. NetBeans bietet keinen Editor für ImageIcons an und schon gar nicht für die selbst programmierte Enumeration Appearance.

Ich fange mal mit Appearance an, weil ich dafür erstmal nur die Möglichkeiten von NetBeans ausschöpfen will. Da NetBeans (leider noch nicht) selbst enum-Klassen erkennt, muss ich selber ran und einen eigenen Editor dafür programmieren. Einmal geht es dafür noch in den Datei-Assistenten: Strg+N -> Kategorie "JavaBeans Objects" -> Property Editor. Name soll sein: "AppearancePropertyEditor". Die erzeugte Klasse ist klein und bietet nicht viel.

Nun wird folgendes in die Klasse programmiert:

package org.sepix.beandemo;

import java.beans.*;
import org.sepix.beandemo.JImagePanel.Appearance;

/**
 * @author Aljoscha Rittner
 */
public class AppearancePropertyEditor extends PropertyEditorSupport {
    @Override
    public String[] getTags() {
        return new String[] {"SCALE", "CENTER"};
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
        String input = text != null ? text.toLowerCase() : "";
        if ( input.equals("scale")) {
            setValue(JImagePanel.Appearance.SCALE);
        } else if ( input.equals("center")) {
            setValue(JImagePanel.Appearance.CENTER);
        } else {
            setValue (null);
        }
     }

    @Override
    public String getJavaInitializationString() {
        JImagePanel.Appearance app = (Appearance) getValue();
        if ( app == null ) return "null";
        switch (app) {
            case SCALE: {
                return "org.sepix.beandemo.JImagePanel.Appearance.SCALE";
            }
            case CENTER: {
                return "org.sepix.beandemo.JImagePanel.Appearance.CENTER";
            }
        }
        return "";
    }
}

Was da passiert ist relativ einfach. Die Methode getTags() liefert alle möglichen "Human readable" Werte für appearance. Die Methode setAtText "übersetzt" diese Zeichenketten in echte Werte vom Typ JImagePanel.Appearance. Und letztendlich bastelt die Methode getJavaInitializationString() aus dem Wert einen Java-Befehl, der direkt in das Programm vom Form-Designer eingefügt wird.

Woher weiß nun NetBeans, dass ich nun einen neuen Editor für Appearance habe? Noch gar nicht. Dafür rufe ich wieder die Klasse JImagePanelBeanInfo auf, wechsele in den Desinger und markiere das Property appearence. Auf der rechten Seite kann ich nun die Eigenschaft "Property Editor Class" setzen. In meinem Fall ist das der Name: org.sepix.beandemo.AppearancePropertyEditor.class - es muss also der vollqualifizierte Name der Editor-Klasse sein (mit Package) und dem Anhängsel .class (das ist übrigens ein Pseudofeld der Java-Programmiersprache für Object-Klassen).

Nun erneut ein "Clean & Build" des Projektes. Das Test-JFrame öffnen und das alte JImagePanel rauslöschen und erneut über die Palette hinzufügen.

Und tatsächlich: appearance hat nun eine Combobox mit zwei Werten.

Wenn ich einen auswähle, wird im Guarded Block des Quelltextes auch der passende Programmbefehl eingefügt:

jImagePanel1.setAppearance(org.sepix.beandemo.JImagePanel.Appearance.CENTER);

Nur noch eine Sache stört mich. Das Property appearance zeigt zunächst immer null an. Wenn man aber JImagePanel anpasst und das Feld appearance initialisiert, dann ist das Problem auch verschwunden:

public class JImagePanel extends JPanel {

    public static enum Appearance {SCALE, CENTER};

    private ImageIcon backgroundImage;
    public static final String PROP_BACKGROUNDIMAGE = "backgroundImage";
    private Appearance appearance = Appearance.SCALE; // <- Standard
    public static final String PROP_APPEARANCE = "appearance";
    ...

Super. Eine Eigenschaft haben wir schon auf die Sprünge geholfen. Nun geht es um das Hintergrundbild. Dazu mehr im nächsten Teil!

Teil 1 | Teil 2 | -> Teil 3 | Teil 4

Im vorherigen Teil habe ich eine Bean-Klasse erstellt, die zwei zusätzliche Eigenschaften zu einem JPanel hinzufügt. Zum einem Appearance (Darstellung) und backgroundImage (Hintergrundbild). 

In diesem Teil möchte ich den BeanInfo-Editor verwenden, um diese Eigenschaften in gewünschter Form in NetBeans darzustellen und vor allem viele andere Properties (von JPanel) abschalten.

Zunächst wähle ich die JImagePanel-Klasse im Explorer aus, rechte Maustaste und rufe im Kontextmenü den "BeanInfo Editor..." auf. Da noch keine BeanInfo-Klasse exisitiert, fragt NetBeans noch höflich nach, ob diese Klasse erzeugt werden soll. Das bestätige ich und erhalte damit eine wirklich monströs große Klasse mit dem Namen JImagePanelBeanInfo. Im BeanInfo-Editor habe ich zwei Views zur Verfügung: Source und Designer. Source zeigt mir den Java-Quelltext und Designer eine hierarchische Darstellung von Properties, Event Sources und Methods. Natürlich auch alle Elemente aus JPanel und den Superklassen. Zwischen den ganzen Properties verstecken sich auch die neuen Eigenschaften appearance und backgroundImange.

Um die spätere Darstellung der Eigenschaften im NetBeans-GUI-Designer übersichtlich zu halten, deaktiviere ich einfach erstmal alle Properties und Methods. Also alle Property-Knoten markieren, rechte Maustaste -> "Toggle Include". Das selbe mit den Methoden durchführen. 

Wenn man nun speichert und in die Source-Ansicht wechselt, sieht man, dass der Quelltext doch deutlich kürzer geworden ist. Zurück in der Design-Ansicht markiere ich in der Kategorie Properties die Eigenschaften appearance, backgroundImage und border -> rechte Maustaste -> "Toggle Include".

Damit sollten nur noch die drei Eigenschaften und alle Ereignisse (Event Source) aktiviert sein.

Jetzt kommt die Stunde der Wahrheit. Vom Projekt ein Clean&Build machen. Mit der rechten Maustaste auf JImagePanel klicken -> Tools -> Add to Palette... In dem Dialog nun die Beans-Kategorie auswählen (so finden wir unser Bean einfacher wieder).

Nun erzeuge ich ein neue JFrame zum testen. Strg+N -> Kategorie "Swing GUI Forms" -> JFrame Form.

Der Designer öffnet sich auch sofort und aus der Palette ziehe ich (aus der Kategorie Beans) mein persönliches JImagePanel-Bean. Und wie man am Eigenschaftsfenster sieht, werden nur drei Properties angezeigt. So wie ich das im BeanInfo-Editor festgelegt hatte.

Für das Property "border" gibt es schon einen schönen Editor, den ich über den Button [...] aufrufen kann. Für appearance und backgroundImage sieht die Sache noch etwas Mau aus.

Im dritten Teil zeige ich, wie man für die zwei neuen Eigenschaften eigene Editoren hinterlegen kann.

Teil 1 | -> Teil 2 | Teil 3 | Teil 4

Manchmal kann man schon vergessen, warum NetBeans überhaupt den Teil "Beans" im Namen trägt. Dabei ist es gerade in der NetBeans-IDE recht einfach im Form-Editor eigene Java-Bean-Komponenten einzufügen.

Sicherlich, im Entwicklungsprozess von Version 5.5 zu 6.5 ist ein praktisches Werkzeug, zwischenzeitlich in Version 6.0, unter die Räder gekommen: Der BeanInfo-Editor. Dabei hat gerade dieses Tool in Vergangenheit viel Handarbeit abgenommen, die bei der Pflege von BeanInfo-Klassen auf einem so zukommen.

Auch die aktuelle Version in 6.5 lässt noch einige Wünsche offen, aber es ist wieder schön bequem geworden zu seinen POJO-Klassen BeanInfo-Deskriptoren hinzuzufügen.

NetBeans hat für Java-Bean-Komponenten einiges an Assistenten bereitgestellt. Diese Assistenten stellen i.d.R. nur einfache Java-Templates zur Verfügung. Mit New File... -> Kategorie "JavaBeans Objects" kommt man an die Vorlagen heran.

• JavaBeans Component
  Erzeugt eine einfache serialisierbare Java-Klasse mit PropertyChangeSupport und dazu einem Beispiel-Property.
• BeanInfo und BeanInfo w/o Icon
  Erstellt eine BeanInfo-Klasse (mit oder ohne Icon-Abfrage), die sich auf eine Java-Klasse bezieht. Die BeanInfo-Klasse arbeitet mit einem MultiView-Editor für den Java-Quelltext und einem Designer.
• PropertyEditor
  Dieser Assistent erzeugt eine sehr einfache Vorlage eines eigenen Eigenschafts-Editor, der für bestimmte Properties festgelegt werden kann. Die Klasse erweitert nur PropertyEditorSupport.
• Customizer
  Mit dem Customizer-Assistenten wird ein GUI-Panel erstellt, der als besonderer grafischer Editor über den PropertyEditor zurückgegeben werden kann. NetBeans zeigt dann im Eigenschafts-Fenster für das Property einen zusätzlichen Button an, um diesen Customizer aufzurufen.
  Der Customizer ist ein JPanel und implementiert das Interface java.beans.Customizer.

Als Beispiel (wie man die Klassen verwendet), möchte ich hier ein JPanel-GUI Bean vorstellen,

• welches ein Hintergrund-Bild darstellt,
• dieses Bild skaliert oder zentriert darstellt
• und im GUI-Editor weitere Komponenten aufnehmen darf.

Für das Bean JImagePanel nehme ich nicht den Assistenten, um eine JavaBeans Component zu erzeugen. Einfach nur Strg+N -> Java Class auswählen und die Klasse "JImagePanel" nennen. Nun das Panel noch von JPanel ableiten, Fix Imports..., und schon haben wir ein einfaches Java Bean.

import javax.swing.JPanel;
public class JImagePanel extends JPanel {

}

Ein sehr einfaches Java-Bean. Um das Hintergrundbild im Panel anzeigen zu können, muss dieses als Property hinterlegt werden. Den Eingabecursor in den Body der Klasse setzen, Alt+Einf eintippen und im Kontextmenü "Add Property..." auswählen.

Im Dialog des Assistenten einfach den Namen auf "backgroundImage" setzen, für Type nehme ich den Browse-Button und gebe im Filter einfach ImageIcon ein und übernehme die Klasse javax.swing.ImageIcon. Außerdem sollte die Eigenschaft "private" sein und ein Haken bei "Bound" sollte noch gesetzt werden. Damit wird auch automatisch "Generate Property Change Support" aktiviert.

Da das Hintergrundbild entweder skaliert oder zentriert werden soll, käme da noch eine zusätzliche Eigenschaft hinzu. Man könnte ein boolean verwenden, nur um das Skalieren einstellbar zu machen. Bei false könnte man das Bild dann zentrieren. Das wäre aber schlecht erweiterbar. Also verwende ich eine Enumeration.

Ich füge der Klasse einfach folgende Zeile hinzu:

public static enum Appearance {SCALE, CENTER};

Dann erzeuge ich das passende Property hinzu: Alt+Einf -> "Add Property...". Den Namen auf "appearance" setzen, für Type den enum-Namen "Appearance", Zugriff wieder "private" und [X] Bound. Dann wieder [Ok] anklicken.

Jetzt ist in der (anfänglich einfachen) Java-Klasse eine Menge los. Zwei Properties sind hinzugekommen und PropertyChangeSupport. Außerdem darf man dem Bean nun Listener hinzufügen und entfernen. Ein richtig schönes Bean also!

Im zweiten Teil geht es an den BeanInfo-Editor, um nun die Darstellung der Eigenschaften in NetBeans zu steuern.

-> Teil 1 | Teil 2 | Teil 3 | Teil 4

Toni Epple, Mitglied des NetBeans Dream Team, hat einen schönen Beitrag zu den Features von NetBeans 6.5 für das JavaMagazine geschrieben.

Es gibt auch eine gekürzte Online-Version in zwei Teilen im JAXenter:

Teil 1 - Alles rund um das Release 6.5 mit Unterstützung für PHP und JavaFX

Teil 2 - Wenn's mal nicht so läuft – Profiler & Debugger

Beste Grüße,
  Josch.