Source

elexis-bootstrap /

Filename Size Date modified Message
autotest
debian
jenkins
lib
pde.test.utils
spec
src/main/java
tasks
246 B
0 B
1.5 KB
771 B
562 B
3.2 KB
1.8 KB
11.4 KB
2.3 KB
7.0 KB
1.5 KB
1.2 KB
3.9 KB
2.6 KB
6.2 KB
16.9 KB
3.6 KB
0 B

Einführung

Das Ziel von diesem Projekt ist die Kostensenkung im Schweizer Gesundheitswesen und die Zufriedenheit vom Elexis User. Dazu arbeitet Elexis auch mit Open Drug Database zusammen, welches anstrebt, möglichst viele Daten aus dem Gesundheitswesen öffentlich zugänglich zu machen.

Installation

Eine Demo-Version von Elexis kann auf der offiziellen Projektseite von Elexis” installiert werden. Falls Sie den Anleitungenn in diesem Readme folgen, werden sie mit wenig Aufwand die aktuellste Version von Elexis selber zusammenbauen können.

Komplette Erstellen mit Apache Buildr auf Linux, OS X oder Windows.

Falls Sie dieses Dokument bis zum Schluss lesen, alle darin enthaltenen Anweisungen verstanden haben und die notwendigen Anpassungen für Ihre Umgebung gemacht haben, können Sie als Belohnung mit folgenden Zeilen ein Elexis erstellen.

Mit den folgenden einfachen Schritten kommen Sie zu einem aus den Quelldateien kompilierten Elexis (auf dem Branch 2.1.7). Der Branch 2.1.7 entspricht, welcher zu Zeit (Dezember 2012) demjenigen, auf dem die meiste Entwicklung läuft. Er wird jedoch in den nächsten Wochen wohl zur Q-Linie erklärt und durch einen anderen ersetzt.

  • hg clone https://bitbucket.org/ngiger/elexis-bootstrap # Nur das erste mal
  • cd elexis-bootstrap
  • export P2_EXE=/Applications/eclipse
    • P2_EXE muss auf ein lokal installiertes Eclipse (oder mindestens den P2-Teil davon) zeigen. Für Juno muss auch P2_EXE auf eine Juno-Installation zeigen.
    • Bitte Pfad an Eure Installation anpassen. F
    • Forward slashes needed under Windows, too!
    • Under Windows den Befehl export durch set ersetzen.
  • ./gen_repo.rb --branch 2.1.7
    • Erstellt Repositories gemäss Angaben in elexis_conf[_override].rb oder bringst sie auf den auf den aktuellsten Stand
    • Unter Windows ./ weglassen
  • ./rebuild_all.rb
    • Erstellt OSGi-Repostory gemäss elexis-addons/ch.ngiger.elexis.opensource/desktop.dev.target, installiert delta, compiliert alles, erzeugt JAR-Dateien, eine Installation (für Ihr Betriebssystem) und den IzPack basierenden Installer (für alle unterstützten Betriebssysteme)
  • Testen ob mit Hilfe java -jar deploy/elexis-installer.jar Elexis installiert werden kann, aufstartet und korrekt läuft.
  • Testen ob das unter deploy/elexis-opensource/<your_os> erzeugte Elexis aufstartet und korrekt läuft.

Falls alles in Ordnung ist können Sie mit dem Entwickeln beginnen oder weiterfahren.

Der Entwickler wird ja Elexis vorwiegend aus seiner Eclipse-Umgebung staren, debuggen, testen und verbessern. Folgende Punkte sind zu beachten:

  • Als Eclipse-Target Definitions elexis-addons/ch.ngiger.elexis.opensource/desktop.dev.target oder äquivalent setzen
  • Elexis via elexis-addons/ch.ngiger.elexis.opensource/ch.elexis.branding.product.launch starten

Das rebuild_all.rb sollte jeweils vor einem Check-In gemacht werden und ebenso das erstellte Produkt.

Die Option —offline rebuild_all.rb erlaubt es, Elexis auch zu bauen, wenn das Netz nicht erreichbar ist. In diesem Fall werden einige Schritte übersprungen und geht davon aus, dass die gleichen Versionen wie beim vorhergehenden Build benutzt werden.

Für die Continuos Integration brauche ich Jenkins auf einem Debian squeeze, den ich wie folgt aufsetze:

  • Branch 2.1.7 von https://bitbucket.org/ngiger/elexis-bootstrap auschecken
  • Im Workspace folgende Zeilen als Shell aufrufen

export P2_EXE=/var/lib/jenkins/juno/eclipse/
export PATH=${HOME}/.rvm/bin:${PATH}
rvm alias create default jruby-1.6.7.2
./gen_repo.rb —branch $ChooseBranch .
./rebuild_all.rb

Beim zweiten und folgenden Mal

Da jetzt die Repositories schon ausgecheckt sind, sollten folgende Befehle in kürzerer Zeit durchlaufen

  • ./gen_repo.rb --branch 2.1.7 # holt neueste Version aller Projektes holen
  • ./rebuild_all.rb

Hintergrund

  • Elexis basiert auf der Initiative von zwei Schweizer Ärzten Gerry Weirich und Peter Schönbucher und vielen weiteren wichtigen Personen.

Release Manager

  • Der Ruby-Liebhaber Niklaus Giger ist Release Manager von Elexis und der Kopf hinter diesem elexis-bootstrap Projekt.
  • Vielen Dank auch an den ersten Beta-Test im Rahmen des oddb.ch-Projektes, Zeno Davatz.

Kommerziellen Support zu Elexis finden Sie hier

Es gibt in der Schweiz ca. 15 Firmen die kommerziellen Support für das Med-Elexis bieten. Sind Sie noch nicht aufgelistet, teilen Sie uns das bitte mit.

Design der Build-Umgebung für Elexis (basierend auf Apache Buildr )

Aus verschiedenen Gründen wurde entschieden, dass Elexis beim Erstellen auf Projekten aus verschiedenen Quellcode-Repositories zugreift. Z.B. elexis-base, elexis-addons und Archie

Ein Vorschlag, welche Repositories verwendet werden, findet man in der Datei elexis_conf.rb. Dieser soll, wenn ein Benutzer dies anders haben will, in die Datei elexis_conf_override.rb kopiert und angepasst werden, um z.B. um proprietäre oder noch nicht zur Veröffentlichung bestimmte Repositories zu erweitern.

Das Script lib/gen_buildfile.rb parsed alle Unterverzeichnisse, um *.project-Dateien zu finden. Aus diesen Informationen (+ META-INF/MANIFEST.MF, resp. feature.xml) wird ein buildfile erstellt, welches ziemlich einfach ist.

lib/gen_buildfile.rb fügt für diverse Projekte noch Checks ein, welche es Apache Buildr erlauben zu testen, ob der Build erfolgreich war (z.B. ob eine Datei verpackt ist oder nicht, eine gewisse Grösse hat, etc). Dies ist sehr hilfreich, wenn man an die Build-Scripts selber verändert, und hat schone manche Verschlimmbesserung verhindert.

Java

Elexis setzt SUN-Java 6. Builds mit OpenJDK wurden auch schon erstellt. Java 7 wurde nicht eingehend getestet. Der Java-Compiler von SUN verhält sich in gewissen Fällen anders, als derjenige von Eclipse (eclipsec). Die Unterstützung von Apache Buildr für den Eclipse compiler ist jedoch im Moment nicht verfügbar. You need to hava the JDK installed, too.

Eclipse

Install “Eclipse for RCP and RAP Developers” from eclipse.org. Diese wird nur dazu benutzt, um einen p2-installer für die Delta-Packete aufzurufen. Die

Benötigte Hilfsprogramme

setup on Linux (Debian squeeze)

The following Debian packages (beside a working Eclipe installation) were needed:

sudo aptitude install mercurial mercurial-git fop git ant ant-contrib sun-java6-jdk

You need to install also rvm. I recommend the default installation method which places everything under ~/.rvm.

bash -s master < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

setup on Windows

  • For Mercurial with hg-git or git see separate chapter below
  • Install jruby 1.6.7.2 and associated *.rb files with jruby
  • Install wget
  • Install MSys-Git with all utilities, like patch, wget, curl. Or installe patch and curl from other source
    • You find a detailled explanaition under http://uncod.in/blog/installing-msysgit-on-windows7/. Follow it with this exception
    • when the screen “Adjusting your PATH environment” is show, select the (third option) “Run Git and included Unix tools from the Window Command Prompt”

setup on MacOSX

  • For Mercurial with hg-git or git see separate chapter below

Homebrew

  • Auf OS X benutzen wir für die Installation von diversen Hilfsmitteln Homebrew
https://github.com/mxcl/homebrew/wiki/installation

  • brew install wget

Mercurial

Wir brauchen ein funktionierende Installation von Mercurial.
Wer git-basierende OpenSource-Repositories von Elexis wie elexis-hilotec-plugins (Alternative KGView und OpenDocument-Anbindung) oder Jörg Sigles noatext plugin nutzen will, installiert am besten hg-git oder git. (Für Windows empfehle ich MSys-Git. Under MacOSX wird git mitgeliefert. gen_repo.rb brauch git für git-Repositories, falls es “git —version” aufrufen kann.

  • Einstellungen:
Unter hgrc.example findet man die vom Release Manager gebrauchten Einstellungen. Bitte durchgehen, anpassen an die eigenen Bedürfnisse und dann unter $HOME/.hgrc speichern.

  • Zu ignorierende Dateien
Entwickler benutzen verschiedene Editoren, OS und erstellen deshalb am besten eine $HOME/.hgignore-Datei. Damit erreicht man das Kommandos wie hg status nicht jede Menge von Backup-Dateien wie tst.java~ anzeigen.

JRuby

Beim von uns verwendete Apache Buildr verwenden wir jruby. Die aktuelle verwendet Version 1.6.7.2 wird nur in der Datei .rvmrc gesetzt und hier dokumentiert. jruby 1.7.0 (welches per Default Ruby 1.9-Syntax unterstützt), führt zu Probleme, welche wir noch nicht gelöst haben. Um leicht zwischen verschiedenen Ruby-Versionen wechseln zu können, setzen wir RVM (siehe unten) ein. Es muss also vorgängig einmal rvm install jruby-1.6.7.2 aufgerufen werden.

  • Debian

  • sudo aptitude install texlive texinfo texlive-latex-extra texlive-lang-german mercurial mercurial-git fop git ant ant-contrib sun-java6-jdk

LaTeX needed to create documentation

This step is not mandatory as the build scripts will silently skip creating documentation if they cannot find the program fop and texi2pdf.

  • Debian/Linux

sudo aptitude install texlive texinfo texlive-latex-extra texlive-lang-german

Then there is the file floatflt.sty missing, which was expelled from Debian as being not free enough.

The following steps solve this problem:

wget http://mirror.ctan.org/macros/latex/contrib/floatflt.zip
unzip floatflt.zip
cd floatflt
latex floatflt.ins
sudo mkdir /usr/share/texmf/tex/latex/misc/
sudo cp floatflt.sty /usr/share/texmf/tex/latex/misc/
sudo texhash

(adapted from http://lists.debian.org/debian-user-german/2004/10/msg01147.html)

  • Windows: You will need MiKTeX.
  • MacOSX:
    • You need wget, LaTex and fop installed. We recommend MacTeX (ca. 1.8 GB)
    • brew install fop

Beim ersten Install auf OSX muss RVM und jruby-1.6.7.2 installiert werden

Für den täglichen Gebrauch und nach dem ersten Build bei täglichen commits:

  • ruby rebuild_all.rb

Der erste Build kann ruhig eine Stunde dauern, da viel runtergeladen wird (korrekte Eclipse-version, Delta-Packete, Scala, ant). Ebenso wird unter $HOME/.m2 ein Repository erstellt, wo alle Maven Artefakte (auch die der gesamten Installation) zwischen gelagert sind.

Falls man keine Änderungen an den Abhängigkeiten zwischen den Plug-Ins gemacht hat, reicht folgender Befehl, um einen stand-alone-Version von Elexis zu erzeugen.
rvm jruby-1.6.7.2 do buildr test=no package
Dieser Befehl braucht ca. 3 Minuten, um alle Abhängigkeiten zu prüfen

Jenkins Builds from Niklaus Giger

ruby rebuild_all.rb

Tipps und Tricks

Besten Dank an Zeno Davatz der geholfen hat, die Builds unter MacOSX zu erstellen und zu testen. Ebenso hat er viele Ideen zu diesem Readme beigetragen.

Buildfile neu erstellen wenn der Pfad für Java nicht korrekt ist auf OS X und Linux

  • vim lib/gen_buildfile.rb
  • ruby lib/gen_buildfile.rb

oder z.B. für Mac OS X

  • export P2_EXE=/Applications/eclipse

Build bricht ab und meldet einen Fehler wie “PermGen Error”

Lösung: Umgebungsvariable JAVA_OPTS setzen, z.B. export JAVA_OPTS="-Xmx1024m -XX:MaxPermSize=312m"

Dies muss meistens gesetzt werden, falls die Dokumentation und Javadoc generiert wird.

Postgres unter MacOSX

  • Datenbankverbindung für Postgres auf OS X testen
psql —username elexis —password —host=localhost —port=5432 elexis

  • Postgres ist ab OS X Lion per default installiert, wenn man Postgres also nochmals installiert muss man darauf achten, dass der Pfad von Postgres in /etc/paths zuerst kommt.

Wenn man wieder von Scratch arbeiten möchte, muss man folgendes tun

  • rm -rf ~/elexisdata
  • einen neuen Mandanten anlegen. Der heisst bei fast allen ma mit Passort man und irgend einer Dummy-Email-adresse zb. tst@tst.org. Dann nochmals aufstarten
  • Die Verbindung mit der Datenbank wieder definieren, nochmals aufstarten
  • jetzt einloggen

Dump der DemoDB und oder KonfigurationsDB

Auf den Pfad gehen, wo die Datei db.h2.db gefunden werden kann. Dies ist bei der DemoDB /pfad/zur/installation/demoDB und für die Datenbank mit der lokalen Konfiguration $HOME/elexisdata/elexisdb.

  • wget http://repo1.maven.org/maven2/com/h2database/h2/1.2.143/h2-1.2.143.jar
  • java -cp h2*.jar org.h2.tools.Backup erzeugt backup.zip
  • java -cp h2*.jar org.h2.tools.Recover erzeugt db.h2.sql (SQL-Dump)
  • java -cp h2*.jar org.h2.tools.RunScript -url jdbc:h2:./db -user sa -script db.h2.sql liest den SQL-Dump wieder herein
  • SQL-Tool. Voraussetzung: wie oben auf dem richtigen Pfad stehen und h2*.jar geholt haben. Mit dem Befehl java -jar h2*.jar öffnet sich auf dem host eine http-zugriff auf localhost:8082

DemoDB so modifizieren, dass man als Administrator einloggen kann

TODO: Via SQL-Tool auf DemoDB zugreifen. Weiss im Moment nicht, welchen Befehl ich eingeben muss, damit man Administratoren-Rechte erhält.

Arbeiten mit git und Github

TODO/upcoming

  • Integrate JUnit-Tests
  • Should .classpath files be stored in the repositories (I think not, as they are automatically generated by Eclipse and by Apache Buildr). I think they are not (always) part of the _sources.jar. e.g org.eclipse.mylyn.commons-feature. Therefore we should add .classpath to our .hgignore file.
  • Use p2 to create the application (right now they are created by copying files around)
  • Integrate PDE-Tests
  • Integrate Jubula-GUI-Tests
  • Improve generating a P2-update site
  • Improve Apache Buildr and buildr4osgi and move functionality from tasks/*.rake -> buildr and buildr4osgi. Make Niklaus Giger branch of buildr4osgi obsolete.
  • Add text templates to demoDB
  • Offer an option to be admin in the demoDB (e.g. to improve documentation)
  • Idea: Use MediaWiki to administrate Elexis documentation, integrate it into Eclipse-Help system (Main sources would be:
  • Far away: Debian package for Elexis (We would need first to package quite a lot of *.jar’s and be the first Eclipse RCP application in Debian)

Implementation notes

General remarks

Resolving the OSGi dependencies specified in the MANIFEST.MG files is done via buildr4osgi. Therefore we must specify an environment varible OSGi, which must give the full path, where the build process will download all needed plugins.

We need also the environment variable P2_EXE, which is used to populate the OSGi directory, build the p2-repository, etc. It must point to a working Eclipse installation (e.g. indigo-SR2, helios, juno worked fine for me. But not galileo).

The environment variable ChooseBranch points to the branch/tag we want to build, e.g. 2.1.7, 2.2.dev, 2.1.7.0.rc2

Elexis historically always used more than one repository for its source code (e.g. elexis-base, archie, elexis-addons, proprietary ones) and does not enforce any particular rule.

If you want to override the name/place of the repositories defined in elexis_conf.rb, copy the file to elexis_conf_override.rb and add/modify repositories as you like.

The Eclipse version to build against is define in elexis_conf.rb via as BuildCfg['EclipseVers'] ||= "juno-SR1"

You need to install the mercurial extension hggit to use git-repositories. If you don’t need any git-repository then copy elexis_conf.rb to elexis_conf_override.rb and comment out all references to git repositories.