Sunday, April 15, 2012
Peformance Trick beim Durchlesen von Views
Eines vorweg für alle die mit Java auf Kriegsfuß stehen. Der Beispielcode ist zwar in Java. Das selbe sollte jedoch auch in anderen Sprachen z.B. Lotusscript funktionieren. Ich zeige dann am Ende des Posts den Code auch in Lotusscript versprochen
In vielen meiner Programme oder Agenten kommt Code vor, der alle Dokumente einer bestimmten View lesen und verarbeiten muss. wie z.B.
...
Document doc = view.getFirstDocument();
while (doc != null) {
Document tempdoc = doc;
//Mach irgendwas mit diesem doc
doc = view.getNextDocument(doc);
tempdoc.recycle();
}
...
Ausführungsdauer dieses Code bei unserer CRM Datenbank ca. 43 Sekunden.
Dabei war ich bis jetzt immer sehr enttäuscht über die Performance die Notes hier bietet. Das lesen von größeren Datenmengen dauert einfach ewig. Was hauptsächlich daran liegt, dass jeder Lesevorgang in der View eine Transaktion auslöst. Viel effizienter wäre es wenn Notes gleich ganze Blöcke lesen würde. Bisher gab es dazu keine Möglichkeit im Domino API. Bei der view gibt es das auch nach wie vor nicht. Aber im Rahmen der Performanceverbesserungen bei xPages wurden neue Features beim ViewNavigator eingeführt und die kann man sich hier zunutze machen.
Hier der selbe Code wie oben nur umgebaut auf die Verwendung eines ViewNavigators:
...
ViewNavigator navigator = view.createViewNav();
ViewEntry entry = navigator.getFirstDocument();
while (entry != null) {
Document doc = entry.getDocument();
//Mach irgendwas mit diesem doc
ViewEntry tempEntry = entry;
entry = navigator.getNextDocument();
tempEntry.recycle();
}
...
Das bringt natürlich noch keine Verbesserung des Laufzeitverhalten, sondern bringt sogar eine Verschlechterung auf 53 Sekunden.
Aber der ViewNavigator besitzt neue Methoden die ein geblocktes Lesen erlauben. Die Voraussetzung dafür ist einmal, dass man die View aus dem man den Navigator erstellt das Autoupdate abgewöhnt mit view.setAutoUpdate(false).
Dann kann man den ViewNavigator mit navigator.setBufferMaxEntries(x) mitteilen, dass man gerne x Sätze auf einmal lesen will. Dies verbessert die Performance enorm. (Update laut Domino Wiki darf der Wert x zwischen (2 und 400) sein. Ich habe festgestellt, dass höhere Werte als 400 eine leicht bessere performance bringen. Siehe auch Kommentag von Ulrich Krause)
Folgender Code von oben ergänzt mit Blocking läuft auf meiner Maschine in unter 10 Sekunden statt der 43 Sekunden im usprünglichen Code ohne Blocking.
...
view.setAutoUpdate(false);
ViewNavigator navigator = view.createViewNav();
navigator.setBufferMaxEntries(1024);
ViewEntry entry = navigator.getFirstDocument();
while (entry != null) {
Document doc = entry.getDocument();
//Mach irgendwas mit diesem doc
ViewEntry tempEntry = entry;
entry = navigator.getNextDocument();
tempEntry.recycle();
}
...
Das ist ja schon mal nicht schlecht.
Es gibt aber noch 2 zusätzliche Optionen mit denen man unter bestimmten Umständen noch zusätzliche Performance erzielen kann.
Wenn man wie in den obigen Beispiel die viewEntrys Spalten nicht benötigt, dann kann man das laden der Spaltenwerte unterdrücken. Je nach dem wie viele Spalten die View enthält, habe ich in meinem Tests nocheinmal eine Laufzeitreduktion um 10% erreichen können. Diese Option kann man mit navigator.setEntryOptions(ViewNavigator.VN_ENTRYOPT_NOCOLUMNVALUES) setzen.
Bei manchen Arten von Views kann es auch etwas bringen, die Entryoption navigator.setEntryOptions(ViewNavigator.VN_ENTRYOPT_NOCOUNTDATA); zu setzen. Laut meinen Informationen verhindert es die automatische Zählung bei kategorisierten Ansichten. Ich habe es aber noch nicht praktisch verwendet.
Noch einen zusätzlichen Performancegewinn, kann man erzielen, wenn man nur bestimmte Dokumente aus der View verarbeiten will, in dem man in der View die Selektionsfelder als Spalten aufnimmt, und dann das Dokument nur dann liest, wenn im Viewentry die Spaltenwerte den Selektionskriterien entsprechen. Hier sind die Performancegewinne noch stärker ausgeprägt als bei der klassischen Methode. Außerdem kann man natürlich noch die ganzen anderen Vorteile eines ViewNavigators verwenden. z.B. einen ViewNavigator mit allen Dokumenten einer bestimmten Kategorie einer kategorisierten View zu erstellen.
Hier noch wie am Anfang versprochen das oben angeführte Beispiel in Lotus script:
...
view.Autoupdate=false
Set navigator=view.Createviewnav()
navigator.Buffermaxentries=1024
navigator.Entryoptions=1 ' keine Spaltenwerte lesen.
Set entry=navigator.Getfirst()
While Not entry Is Nothing
Set doc=entry.Document
'Mach was mit dem Dokument
Set entry=navigator.Getnext(entry)
Wend
...
Würde mich über Kommentare zu den Performanceverbesserungen die Ihr in euren Anwendungen erzielen konntet freuen.
Friday, April 13, 2012
Standardausgabe von Javaplugins im Notesstandardclient
Oft schreibt man zu Debugzwecken in eigenen Plugins Statusmeldungen an die Standardausgabe. Diese werden wenn man den Notesclient aus Eclipse aufruft auch toll in der Console von Eclipse angezeigt. Aber wo findet man diese Ausgabe wenn man den Client normal gestartet hat. Die Antwort ist ganz einfach im Menü "Hilfe" ->Support gibt es den Punkt "Trace anzeigen" wenn man diesen aufruft, bekommt man eine XML Seite in der neben vielen anderen Meldungen auch die Ausgaben die man in seien Plugins an die Standardausgabe geschickt hat angezeigt werden.
Problem mit nicht Casesensitiver Suche in SQL
Bei vielen alphanumerischen Suchen in meinen Javaprogrammen habe ich bisher folgendes Pattern verwendet:
Ein PreparedStatement mit folgenden SQL erstellt "select *from table where ucase(name)=?"
Sting caseInsentiveSuchbegriff=suchbegriff.toUpperCase();
ps.setString(caseInsentiveSuchbegriff)
ResultSet rs=ps.executeQuery();
Das hat bisher auch sehr gut funktioniert, bis mir gestern ein Benutzer gesagt hat, dass er keine Suchbegriff mit einem "ß" findet. Nach kurzer Debugsitzung war auch klar warum. Java verwendet für Strings Unicode in dem kein großes "ß" definiert ist und verwandelt daher ein "ß" in ein "SS". Unserer Datenbank db/2 auf OS/400 gibt bei ucase('ß') aber ein "ß" zurück. Daher findet das Query keinen Satz.
Die einfachste Lösung für das Problem ist die upperCase auf lowerCase umzubauen und dann funktionieren auch Suchen nach "ß" einwandfrei.
P.S.
Interessant ist in diesem Zusammenhang, dass folgender Code false ergibt.
"groß".equals("groß".toUpperCase().toLowerCase());
Was ganz logisch ist, da "groß" nach dem toUpperCase() zu "GROSS" wird und bei dem toLowerCase() dann zu "gross" konvertiert wird.
Ein PreparedStatement mit folgenden SQL erstellt "select *from table where ucase(name)=?"
Sting caseInsentiveSuchbegriff=suchbegriff.toUpperCase();
ps.setString(caseInsentiveSuchbegriff)
ResultSet rs=ps.executeQuery();
Das hat bisher auch sehr gut funktioniert, bis mir gestern ein Benutzer gesagt hat, dass er keine Suchbegriff mit einem "ß" findet. Nach kurzer Debugsitzung war auch klar warum. Java verwendet für Strings Unicode in dem kein großes "ß" definiert ist und verwandelt daher ein "ß" in ein "SS". Unserer Datenbank db/2 auf OS/400 gibt bei ucase('ß') aber ein "ß" zurück. Daher findet das Query keinen Satz.
Die einfachste Lösung für das Problem ist die upperCase auf lowerCase umzubauen und dann funktionieren auch Suchen nach "ß" einwandfrei.
P.S.
Interessant ist in diesem Zusammenhang, dass folgender Code false ergibt.
"groß".equals("groß".toUpperCase().toLowerCase());
Was ganz logisch ist, da "groß" nach dem toUpperCase() zu "GROSS" wird und bei dem toLowerCase() dann zu "gross" konvertiert wird.
Bestehende Eclipse RCP auf den Mac portieren Teil2
Nach dem ich mich in Teil 1 damit beschäftigt habe, wie man eine Eclipse RCP für den Mac kompilieren kann, möchte ich mich jetzt damit beschäftigen, was man beim Zugriff auf Lotus Notes aus der RCP heraus beachten muss. damit diese auch auf dem Mac funktioniert.
Bevor wir uns um die Portierung auf den Mac kümmern ein paar prinzipielle Dinge wie der Zugriff auf Notes technisch funktioniert.
Die Klassen des Java APIs von Lotus Notes befinden Sich in der Notes.jar. Diese Datei finden Sie unter Windows im Verzeichnis C:\Program Files (x86)\IBM\Lotus\Notes\jvm\lib\ext. Diese Datei muss sich im Klassenpfad befinden, damit Sie verwendet werden kann. Ich habe diese Datei der Einfachheit in ein Plugin importiert, dass die Klassen exportiert, damit ich nicht jedesmal die Notes.jar suchen muss. Prinzipiell kennt das Java API von Notes zwei Zugriffsmöglichkeiten:
DIIOP
Dafür muss ein eigener DIIOP Task am Server laufen, der die Zugriffe auf die Dominodaten durchführt. Auf den Client ist dann nichts mehr weiter nötig als die Notes.jar. Ich verwende diese Möglichkeit nicht sehr gerne, da erstens die Performance sehr bescheiden ist und DIIOP viele Bugs hat.
Lokaler Zugriff
Dabei fungiert die Notes.jar nur als leichtgewichtiger Wrapper für die DLL nlsxbe.dll die Teil des Notes Clients ist. Die Notes.jar besteht sozusagen nur aus JNI Aufrufen. Jeder Aufruf einer Methode in der Notes.jar ruft im Hintergrund eigentlich eine Methode in der nlsxbe.dll auf. Das API der liblsxbe.dll wurde ursprünglich für Lotusscript erstellt und wird von der Notes.jar mitbenützt. Der Vorteil davon ist, dass sich das Java Api praktisch 1:1 zu dem Lotusscript API verhält. Was die Einarbeitung von Lotusscript Anwendern verkürzt. Der Nachteil für Javaentwickler ist, dass das API teilweise seltsame Eigenheiten wie z.B. die Notwendigkeit von recycle() zum aufräumen von C++ Objekten aus nlsxbe.dll notwendig macht.
Leider ist es jetzt aber so, dass die nlsxbe.dll im Hintergrund noch andere DLL's des Notes Client verwendet.
Warum muss man das ganze überhaupt wissen? Ganz einfach wenn man in sein Programm die Notes.jar einbindet und per lokalen Zugriff auf Notes Daten zugreifen will, muss die JVM die notwendigen DLL's finden. Die JVM sucht die DLL's im sogenannten Library_Path. Dieser wird mittels der JVM Option "-Djava.library.path="C:\Program Files (x86)\IBM\Lotus\Notes" gesetzt. Nun findet die JVM zumindest mal die nlsxbe.dll. Aber das die nlsxbe.dll noch andere DLL's laden will, dabei aber vom Java library path nichts mehr weiß, muß das selbe Verzeichnis wie oben auch im Windows PATH sein.
In einer RCP setzt man den Library Path am besten in der Product Beschreibung auf der Launcherseite. Diese Einstellungen können und müssen für jede Plattform extra gesetzt werden.
Hier die Einstellung für Windows
Die Doppelten "\\" sind notwendig, damit beim Erstellungsvorgang der RCP keine Zeilenschaltungen eingefügt werden.
Zusätzlich muss auf Windows unbedingt noch in der Systemsteuerung des Zielcomputers die Pfadvariable angepasst werden. Leider gibt es keine Möglichkeit dies direkt in der RCP Anwendungen zu machen. Da ich sowieso immer MSI installer baue, ist das aber kein Problem.
Hier die Einstellung für den Mac
Am Mac werden DLL's die hier die Endung .dyld haben nicht über den Pfad aufgelöst, sondern der Mac sucht diese in diversen Standardsuchpfaden in denen Notes aber nicht enthalten ist und in den Verzeichnissen die in der Umgebungsvariable "DYLD_Library_PATH" angegeben sind. Wie kann man so eine Umgebungsvariable am Mac setzen. Wie immer am Mac geht das nicht so einfach wie in anderen Umgebungen. Während es unter Windows ein UI gibt um die Umgebungsvariablen zu ändern muss man in Mac OS X wie in Unix mit Konfigurationsdateien arbeiten:
Eine globale Änderung der Umgebungsvariablen kann man für einen Benutzer machen indem man die Datei "environment.plist" im versteckten Verzeichnis ".MacOSX"anlegt. (Wie zeige ich versteckte Dateien und Ordner am Mac an?)
Die Datei muss folgenden Aufbau haben:
Falls man Lotus Notes in ein anderes Verzeichnis installiert hat, muss man natürlich den Pfad anpassen.
Diese Vorgehendsweise hat aber den Nachteil, dass auch andere Programme durch diese Änderung beeinflusst werden und Apple in manchen Versionen seines Betriebssystems diese Vorgehendsweise überhaupt unterbunden hat.
Deshalb die bessere Möglichkeit ist es in der von Eclipse erstellten Applikation die info.plist zu ändern. Die info.plist ist am Mac die zentrale Datei die steuert wie ein Programm aufgerufen werden soll. Man findet die Datei wenn man mit der rechten Maustaste auf eine Applikation klickt und in dem Kontextmenü den Punkt "Paketinhalt zeigen" aufruft. Dann zeigt der Finder den Inhalt der Applikation an. Im Verzeichnis Contents befindet sich dann die info.plist. Einfach die Datei mit dem Editor öffnen und innerhalb des dict Blocks folgenden Inhalt einfügen.
<key>LSEnvironment</key>
<dict>
<key>DYLD_LIBRARY_PATH</key>
<string>/Applications/Notes.app/Contents/MacOS</string>
</dict>
Vorsicht Änderungen an der info.plist werden in MacOSX gecached und der Mac erkennt diese Änderungen leider nicht. Deshalb muss man nach der Änderung unbedingt den Cache aktualisieren:
Dazu geht man in ein Terminal und führt folgenden Befehl aus:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/eclipse/XXX.app
Wobei /eclipse/XXX durch den Applikationsnamen und Pfad ersetzt werden sollte.
Dann sollte auch der Zugriff auf das Java API von Notes funktionieren.
Bevor wir uns um die Portierung auf den Mac kümmern ein paar prinzipielle Dinge wie der Zugriff auf Notes technisch funktioniert.
Die Klassen des Java APIs von Lotus Notes befinden Sich in der Notes.jar. Diese Datei finden Sie unter Windows im Verzeichnis C:\Program Files (x86)\IBM\Lotus\Notes\jvm\lib\ext. Diese Datei muss sich im Klassenpfad befinden, damit Sie verwendet werden kann. Ich habe diese Datei der Einfachheit in ein Plugin importiert, dass die Klassen exportiert, damit ich nicht jedesmal die Notes.jar suchen muss. Prinzipiell kennt das Java API von Notes zwei Zugriffsmöglichkeiten:
DIIOP
Dafür muss ein eigener DIIOP Task am Server laufen, der die Zugriffe auf die Dominodaten durchführt. Auf den Client ist dann nichts mehr weiter nötig als die Notes.jar. Ich verwende diese Möglichkeit nicht sehr gerne, da erstens die Performance sehr bescheiden ist und DIIOP viele Bugs hat.
Lokaler Zugriff
Dabei fungiert die Notes.jar nur als leichtgewichtiger Wrapper für die DLL nlsxbe.dll die Teil des Notes Clients ist. Die Notes.jar besteht sozusagen nur aus JNI Aufrufen. Jeder Aufruf einer Methode in der Notes.jar ruft im Hintergrund eigentlich eine Methode in der nlsxbe.dll auf. Das API der liblsxbe.dll wurde ursprünglich für Lotusscript erstellt und wird von der Notes.jar mitbenützt. Der Vorteil davon ist, dass sich das Java Api praktisch 1:1 zu dem Lotusscript API verhält. Was die Einarbeitung von Lotusscript Anwendern verkürzt. Der Nachteil für Javaentwickler ist, dass das API teilweise seltsame Eigenheiten wie z.B. die Notwendigkeit von recycle() zum aufräumen von C++ Objekten aus nlsxbe.dll notwendig macht.
Leider ist es jetzt aber so, dass die nlsxbe.dll im Hintergrund noch andere DLL's des Notes Client verwendet.
Warum muss man das ganze überhaupt wissen? Ganz einfach wenn man in sein Programm die Notes.jar einbindet und per lokalen Zugriff auf Notes Daten zugreifen will, muss die JVM die notwendigen DLL's finden. Die JVM sucht die DLL's im sogenannten Library_Path. Dieser wird mittels der JVM Option "-Djava.library.path="C:\Program Files (x86)\IBM\Lotus\Notes" gesetzt. Nun findet die JVM zumindest mal die nlsxbe.dll. Aber das die nlsxbe.dll noch andere DLL's laden will, dabei aber vom Java library path nichts mehr weiß, muß das selbe Verzeichnis wie oben auch im Windows PATH sein.
In einer RCP setzt man den Library Path am besten in der Product Beschreibung auf der Launcherseite. Diese Einstellungen können und müssen für jede Plattform extra gesetzt werden.
Hier die Einstellung für Windows
Zusätzlich muss auf Windows unbedingt noch in der Systemsteuerung des Zielcomputers die Pfadvariable angepasst werden. Leider gibt es keine Möglichkeit dies direkt in der RCP Anwendungen zu machen. Da ich sowieso immer MSI installer baue, ist das aber kein Problem.
Hier die Einstellung für den Mac
Am Mac werden DLL's die hier die Endung .dyld haben nicht über den Pfad aufgelöst, sondern der Mac sucht diese in diversen Standardsuchpfaden in denen Notes aber nicht enthalten ist und in den Verzeichnissen die in der Umgebungsvariable "DYLD_Library_PATH" angegeben sind. Wie kann man so eine Umgebungsvariable am Mac setzen. Wie immer am Mac geht das nicht so einfach wie in anderen Umgebungen. Während es unter Windows ein UI gibt um die Umgebungsvariablen zu ändern muss man in Mac OS X wie in Unix mit Konfigurationsdateien arbeiten:
Eine globale Änderung der Umgebungsvariablen kann man für einen Benutzer machen indem man die Datei "environment.plist" im versteckten Verzeichnis ".MacOSX"anlegt. (Wie zeige ich versteckte Dateien und Ordner am Mac an?)
Die Datei muss folgenden Aufbau haben:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>DYLD_Library_PATH</key> <string>/Applications/Notes.app/Contents/MacOS</string> </dict> </plist>
Falls man Lotus Notes in ein anderes Verzeichnis installiert hat, muss man natürlich den Pfad anpassen.
Diese Vorgehendsweise hat aber den Nachteil, dass auch andere Programme durch diese Änderung beeinflusst werden und Apple in manchen Versionen seines Betriebssystems diese Vorgehendsweise überhaupt unterbunden hat.
Deshalb die bessere Möglichkeit ist es in der von Eclipse erstellten Applikation die info.plist zu ändern. Die info.plist ist am Mac die zentrale Datei die steuert wie ein Programm aufgerufen werden soll. Man findet die Datei wenn man mit der rechten Maustaste auf eine Applikation klickt und in dem Kontextmenü den Punkt "Paketinhalt zeigen" aufruft. Dann zeigt der Finder den Inhalt der Applikation an. Im Verzeichnis Contents befindet sich dann die info.plist. Einfach die Datei mit dem Editor öffnen und innerhalb des dict Blocks folgenden Inhalt einfügen.
<key>LSEnvironment</key>
<dict>
<key>DYLD_LIBRARY_PATH</key>
<string>/Applications/Notes.app/Contents/MacOS</string>
</dict>
Vorsicht Änderungen an der info.plist werden in MacOSX gecached und der Mac erkennt diese Änderungen leider nicht. Deshalb muss man nach der Änderung unbedingt den Cache aktualisieren:
Dazu geht man in ein Terminal und führt folgenden Befehl aus:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/eclipse/XXX.app
Wobei /eclipse/XXX durch den Applikationsnamen und Pfad ersetzt werden sollte.
Dann sollte auch der Zugriff auf das Java API von Notes funktionieren.
Thursday, April 12, 2012
Versteckte Dateien ansehen am Mac
Ich stehe ja immer mit dem Mac ein wenig auf Kriegsfuss. Sachen die unter Windows und auch unter Linux mit einem Klick erledigt sind, gehen auf dem Mac etwas schwerer. Jedes mal weiß ich wieder nicht wie man versteckte Dateien im Finder anzeigen kann. Dabei geht es doch so einfach :-)
In Programme Dienstprogramme gehen und dort das Terminal öffnen.
Dann den Befehl "defaults write com.apple.finder AppleShowAllFiles true" eingeben und den Finder neu starten. Dies kann mit dem Befehl "killall Finder" gemacht werden.
Rückgängig kann man das ganze wieder mit dem Befehl "defaults write com.apple.finder AppleShowAllFiles false" gemacht werden. Auch dazu muss man für sofortige Wirksamkeit den Finder mit "killall Finder" neu starten.
In Programme Dienstprogramme gehen und dort das Terminal öffnen.
Dann den Befehl "defaults write com.apple.finder AppleShowAllFiles true" eingeben und den Finder neu starten. Dies kann mit dem Befehl "killall Finder" gemacht werden.
Rückgängig kann man das ganze wieder mit dem Befehl "defaults write com.apple.finder AppleShowAllFiles false" gemacht werden. Auch dazu muss man für sofortige Wirksamkeit den Finder mit "killall Finder" neu starten.
Bestehende Eclipse RCP auf den Mac portieren Teil1
Ich habe eine Eclipse RCP Anwendung erstellt, die Daten über das Java API aus einer Notesdatenbank ausliest und verarbeitet. Diese Anwendung wurde in erster Linie für Windows erstellt aber durch die Plattformunabhängigkeit von Java sollte die Anwendung ja auch problemlos am Mac laufen. Bei meinen Versuchen der Portierung auf den Mac bin ich dabei auf ein paar Hürden gestossen, die nicht ganz einfach zum Umschiffen waren:
Teil1: Installation des Deltapacks in die Targetplattform
Das Deltapack muss die selbe Version haben wie die Targetplattform. Für 3.7 findet man das Delta Pack z.B. auf http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/winPlatform.php .
Den Inhalt des Zips dann einfach in das Verzeichnis der Targetplattform entpacken.
In seiner Eclipse Entwicklungsumgebung muss man nach dem Entpacken die Targetplattform neu einlesen, damit Eclipse die Änderungen erkennt.
Danach sollte es problemlos möglich sein die bestehende Anwendung nicht nur für die aktuelle Plattform sondern auch für andere Plattformen wie den Mac zu erstellen.
Man geht dazu in die Produktdefinition der RCP Anwendung. Als erstes auf die Seite "Dependencies" und klickt dort auf den Knopf "Add required plugins". Es sollten dann automatisch die Fragmente für die verschiedenen Platfformen hinzugefügt werden.
Jetzt kann man auf der Overview Seite auf den Link "Eclipse product export wizard" klicken. Wenn das Deltapack ordnungsgemäß installiert wurde, dann bekommt man in dem Assistenten die Möglichkeit die RCP für verschiedene Plattformen zu packen. Ganz wichtig ist, es wenn man eine Anwendung für den Mac erstellt diese unbedingt in ein ZIP zu exportieren, da es sonst zu Problemen mit den Dateinamen unter Windows kommen kann.
Auf der nächsten Seite des Assistenten kann man dann die Zielplattform auswählen dier erstellt werden soll. In meinen Fall Mac OS cocoa.
Das erstellte ZIP kann man dann einfach auf dem Mac in den Programme ordner entpacken und die Anwendung kann schon mal aufgerufen werden.
Für den Zugriff auf Notes sind jedoch noch weitere Schritte nötig, die ich im nächsten Blog Post näher erklären will.
Teil1: Installation des Deltapacks in die Targetplattform
Das Deltapack muss die selbe Version haben wie die Targetplattform. Für 3.7 findet man das Delta Pack z.B. auf http://download.eclipse.org/eclipse/downloads/drops/R-3.7-201106131736/winPlatform.php .
Den Inhalt des Zips dann einfach in das Verzeichnis der Targetplattform entpacken.
In seiner Eclipse Entwicklungsumgebung muss man nach dem Entpacken die Targetplattform neu einlesen, damit Eclipse die Änderungen erkennt.
Danach sollte es problemlos möglich sein die bestehende Anwendung nicht nur für die aktuelle Plattform sondern auch für andere Plattformen wie den Mac zu erstellen.
Man geht dazu in die Produktdefinition der RCP Anwendung. Als erstes auf die Seite "Dependencies" und klickt dort auf den Knopf "Add required plugins". Es sollten dann automatisch die Fragmente für die verschiedenen Platfformen hinzugefügt werden.
Jetzt kann man auf der Overview Seite auf den Link "Eclipse product export wizard" klicken. Wenn das Deltapack ordnungsgemäß installiert wurde, dann bekommt man in dem Assistenten die Möglichkeit die RCP für verschiedene Plattformen zu packen. Ganz wichtig ist, es wenn man eine Anwendung für den Mac erstellt diese unbedingt in ein ZIP zu exportieren, da es sonst zu Problemen mit den Dateinamen unter Windows kommen kann.
Das erstellte ZIP kann man dann einfach auf dem Mac in den Programme ordner entpacken und die Anwendung kann schon mal aufgerufen werden.
Für den Zugriff auf Notes sind jedoch noch weitere Schritte nötig, die ich im nächsten Blog Post näher erklären will.
Vorstellung
Ich bin beruflich mit der Erstellung von Programmen im Umfeld von Lotus Notes und dem System i der IBM befasst. Dabei verwende ich hauptsächlich Java als Programmiersprache. In diesem Bereich stosse ich immer wieder auf Probleme, die einige Internetrecherche erforderten um Sie zu lösen. Oft habe ich dabei die Lösung in diversen Blogs gefunden. Ich möchte daher dieses Blog betreiben, um erstens gefundene Lösungen für mich selber zu dokumentieren und auf der anderen Seite eventuell auch den einen oder anderen mit meinen Lösungen zu helfen. Wie oft ich blogge kann ich noch nicht sagen, ich würde mich aber über Kommentare zu meinen Lösungen freuen.
Subscribe to:
Posts (Atom)
ad