ingo@4065: Konfiguration:
ingo@4065: ==============
aheinecke@5253: Zur konfiguration des make_release scripts können umgebungsvariablen
aheinecke@5253: verwendet werden oder man ändert die entsprechenden Variablen im Script.
ingo@4065: 
aheinecke@5253: Wichtige variablen sind:
aheinecke@5253: FLYS_SOURCE_DIR
aheinecke@5253: TOMCAT_PORT
aheinecke@5253: MAPSERVER_URL
aheinecke@5530: FONT_PATH
aheinecke@5253: WIKI_URL
aheinecke@5268: LOG_DIR
aheinecke@5253: DEVELOPER
aheinecke@5253: DEFAULT_WD
ingo@4065: 
aheinecke@5253: # Seddb Configuration
aheinecke@5253: SEDDBURL
aheinecke@5253: SEDDBPORT
aheinecke@5253: SEDDBBACK
aheinecke@5253: SEDDBUSER
aheinecke@5253: SEDDBPASS
aheinecke@5253: 
aheinecke@5253: # Backend configuration
aheinecke@5253: BACKENDURL
aheinecke@5253: BACKENDPORT
aheinecke@5253: BACKENDBACK
aheinecke@5253: BACKENDUSER
aheinecke@5253: BACKENDPASS
ingo@4065: 
aheinecke@6163: FEATURES_XML (Wenn gesetzt pfad zu einer zu verwendenden features.xml)
aheinecke@6163: 
ingo@4065: Prozess:
ingo@4065: ========
aheinecke@5900: Als erstes muss man eine halbwegs aktuelle version von artifacts-common
aheinecke@5900: und artifacts-database in dem h2 verzeichnis verlinken.
aheinecke@5900: 
aheinecke@5900: Beispiel:
aheinecke@5900: cd h2
aheinecke@5900: ln -s ~/.m2/repository/org/dive4elements/artifacts-common/1.0-SNAPSHOT/artifacts-common-1.0-SNAPSHOT.jar
aheinecke@5900: ln -s ~/.m2/repository/org/dive4elements/artifact-database/1.0-SNAPSHOT/artifact-database-1.0-SNAPSHOT.jar
aheinecke@5900: 
ingo@4065: Nachdem die Konfigurationen angepasst wurden, kann das Skript mittels
aheinecke@5253:   sh make_release.sh VERSION
tom@7996: von der Konsole gestartet werden. VERSION kann dabei ein Tag oder der Name
tom@7996: eines Branches sein. Anschließend werden die Quellen des
ingo@4065: dive4elements, des HTTP-Clients und von FLYS über SSH aus dem HG Repository
aheinecke@5253: ausgecheckt und in FLYS_SOURCE_DIR abgelegt.
aheinecke@5253: 
tom@7996: 
aheinecke@5253: Wenn mit der option -t zusätzlich ausgewählt wird diese version zu taggen
aheinecke@5253: muss in der make_flys_release.sh der entsprechende accountname zum pushen
aheinecke@5253: des tags als DEVELOPER angegeben werden.
ingo@4065: 
ingo@4065: Für den Client wird OpenLayers-2.11 heruntergeladen und in den Client
ingo@4065: verschoben. Zurzeit wird das komplette OpenLayers-2.11 Verzeichnis in den Client
ingo@4065: verschoben. Dies ist jedoch nur für die Entwicklung sinnvoll.
ingo@4065: 
ingo@4065: Das Resultat des Skripts ist ein tar.gz, welches zwei Verzeichnisses beinhaltet:
ingo@4065: `server` und `client`. Im Server sind alle Konfigurationen sowie notwendige
ingo@4065: Bibliotheken zum Starten des FLYS Servers enthalten. Im Client ist lediglich das
ingo@4065: WAR Archiv für einen Servlet Container (z.B. Tomcat) enthalten.
aheinecke@5097: 
aheinecke@5097: Importer:
aheinecke@5097: =========
aheinecke@5179: Das script um den Importer zu bauen und zu paketieren liegt unter
aheinecke@5179: bin/make-importer-package.sh
aheinecke@5179: Dieses muss man anpassen und ein paar pfade setzen
aheinecke@5097: 
aheinecke@5179: Wenn man ein "Standalone" Paket bauen möchte kann man diesem script
aheinecke@5179: einen Parameter übergeben an welchem sich ein tarball befindet
aheinecke@5179: der mit ins importer paket gepackt werden soll. Dieser Tarball
aheinecke@5179: kann abhängigkeiten (gdal / proj / oracle) enthalten.
aheinecke@5179: Das skript um diesen tarball für sles zu erstellen ist
aheinecke@5179: bin/make-opt-package.sh
aheinecke@5266: 
aheinecke@5266: Deployment:
aheinecke@5266: ===========
aheinecke@5266: Der tarball kann auf ein Zielsystem übertragen werden und dort entpackt werden.
tom@8464: Bei den Testsystemen der Intevation ist der Ort der Installationen
aheinecke@5266: üblicherweise /opt/flys/flys-version
aheinecke@5266: 
aheinecke@5266: Anschließend deployt man den flys-client im webapps verzeichnis von tomcat
aheinecke@5266: (z.b. /usr/share/tomcat6/webapps )
aheinecke@5266: ggf. in WEB-INF die web.xml überprüfen / anpassen.
aheinecke@5266: 
aheinecke@5266: Bei einer konfiguration mit apache vhosts ist nun noch ein entsprechender
aheinecke@5266: vhost in der apache konfiguration einzurichten.
aheinecke@5266: 
aheinecke@5266: Anschließend muss man noch sicher stellen das passende wms scripte im
aheinecke@5266: mapserver verfügbar sind. In /srv/www/cgi-bin müssen entsprechende
aheinecke@5266: river-wms und user-wms dateien liegen die auf die korrekte aktuelle version verweisen.
aheinecke@5618: Hinweis:
aheinecke@5618: Für Oracle muss in diesen scripten die NLS_LANG umgebungsvariable auf UTF-8 gesetzt werden.
aheinecke@5618: Beispiel für ein user-wms script:
aheinecke@5618: 
aheinecke@5618:     #!/bin/sh
aheinecke@5618:     export LC_ALL="de_DE.UTF-8"
aheinecke@5618:     export NLS_LANG=".AL32UTF8"
aheinecke@5618:     export MS_MAPFILE=/opt/flys/current/server/flys.map
aheinecke@5618:     /srv/www/cgi-bin/mapserv
aheinecke@5618: 
aheinecke@5266: Die WMS urls sind in server/conf/floodmap.xml und server/conf/rivermap.xml konfiguriert.
aheinecke@5266: 
aheinecke@5326: In server/conf/conf.xml muss dgm-path angepasst werden um an die richtige stelle
aheinecke@5326: zu zeigen an der im dateisystem die dgm's liegen.
aheinecke@5326: Wichtig: Der Pfad muss mit einem / enden
aheinecke@5326: 
tom@8464: Die bis hierhin beschriebenen Tätigkeiten nach dem Entpacken des Tarballs
tom@8464: können auch mittels eines Skriptes automatisiert bzw. für bestimmte Systeme
tom@8464: angepasst werden.
tom@8464: Über die Umgebungsvariable INSTALL kann ein Pfad zu einem solchen Skript
tom@8464: angegeben werden, dass dann mit in den Tarball gepackt wird.
tom@8464: 
aheinecke@5266: Nun kann man den server starten. Dazu in das entsprechende server verzeichnis wechseln
aheinecke@5266: und ./bin/run ausführen. Der server muss mit diesem arbeitsverzeichnis gestartet werden.
aheinecke@5960: 
aheinecke@5960: '<,'>s/void \(.*\)(\(.*\));/void \1(\2) {\r    d->\1(\2);\r}\r