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