Mercurial > dive4elements > river
view contrib/make_flys_release/README @ 5900:8698e3284b7a
Update after renaming and remove the binary artifact-database and common
author | Andre Heinecke <aheinecke@intevation.de> |
---|---|
date | Fri, 03 May 2013 18:03:41 +0200 |
parents | d03171f66511 |
children | 75803c9eb63b |
line wrap: on
line source
Konfiguration: ============== Zur konfiguration des make_release scripts können umgebungsvariablen verwendet werden oder man ändert die entsprechenden Variablen im Script. Wichtige variablen sind: FLYS_SOURCE_DIR TOMCAT_PORT MAPSERVER_URL FONT_PATH WIKI_URL LOG_DIR DEVELOPER DEFAULT_WD # Seddb Configuration SEDDBURL SEDDBPORT SEDDBBACK SEDDBUSER SEDDBPASS # Backend configuration BACKENDURL BACKENDPORT BACKENDBACK BACKENDUSER BACKENDPASS Prozess: ======== Als erstes muss man eine halbwegs aktuelle version von artifacts-common und artifacts-database in dem h2 verzeichnis verlinken. Beispiel: cd h2 ln -s ~/.m2/repository/org/dive4elements/artifacts-common/1.0-SNAPSHOT/artifacts-common-1.0-SNAPSHOT.jar ln -s ~/.m2/repository/org/dive4elements/artifact-database/1.0-SNAPSHOT/artifact-database-1.0-SNAPSHOT.jar Nachdem die Konfigurationen angepasst wurden, kann das Skript mittels sh make_release.sh VERSION von der Konsole gestartet werden. Anschließend werden die Quellen des dive4elements, des HTTP-Clients und von FLYS über SSH aus dem HG Repository ausgecheckt und in FLYS_SOURCE_DIR abgelegt. Wenn mit der option -t zusätzlich ausgewählt wird diese version zu taggen muss in der make_flys_release.sh der entsprechende accountname zum pushen des tags als DEVELOPER angegeben werden. Für den Client wird OpenLayers-2.11 heruntergeladen und in den Client verschoben. Zurzeit wird das komplette OpenLayers-2.11 Verzeichnis in den Client verschoben. Dies ist jedoch nur für die Entwicklung sinnvoll. Das Resultat des Skripts ist ein tar.gz, welches zwei Verzeichnisses beinhaltet: `server` und `client`. Im Server sind alle Konfigurationen sowie notwendige Bibliotheken zum Starten des FLYS Servers enthalten. Im Client ist lediglich das WAR Archiv für einen Servlet Container (z.B. Tomcat) enthalten. Importer: ========= Das script um den Importer zu bauen und zu paketieren liegt unter bin/make-importer-package.sh Dieses muss man anpassen und ein paar pfade setzen Wenn man ein "Standalone" Paket bauen möchte kann man diesem script einen Parameter übergeben an welchem sich ein tarball befindet der mit ins importer paket gepackt werden soll. Dieser Tarball kann abhängigkeiten (gdal / proj / oracle) enthalten. Das skript um diesen tarball für sles zu erstellen ist bin/make-opt-package.sh Deployment: =========== Der tarball kann auf ein Zielsystem übertragen werden und dort entpackt werden. Bei den testsystemen der Intevation ist der Ort der Flys installationen üblicherweise /opt/flys/flys-version Anschließend deployt man den flys-client im webapps verzeichnis von tomcat (z.b. /usr/share/tomcat6/webapps ) ggf. in WEB-INF die web.xml überprüfen / anpassen. Bei einer konfiguration mit apache vhosts ist nun noch ein entsprechender vhost in der apache konfiguration einzurichten. Anschließend muss man noch sicher stellen das passende wms scripte im mapserver verfügbar sind. In /srv/www/cgi-bin müssen entsprechende river-wms und user-wms dateien liegen die auf die korrekte aktuelle version verweisen. Hinweis: Für Oracle muss in diesen scripten die NLS_LANG umgebungsvariable auf UTF-8 gesetzt werden. Beispiel für ein user-wms script: #!/bin/sh export LC_ALL="de_DE.UTF-8" export NLS_LANG=".AL32UTF8" export MS_MAPFILE=/opt/flys/current/server/flys.map /srv/www/cgi-bin/mapserv Die WMS urls sind in server/conf/floodmap.xml und server/conf/rivermap.xml konfiguriert. In server/conf/conf.xml muss dgm-path angepasst werden um an die richtige stelle zu zeigen an der im dateisystem die dgm's liegen. Wichtig: Der Pfad muss mit einem / enden Nun kann man den server starten. Dazu in das entsprechende server verzeichnis wechseln und ./bin/run ausführen. Der server muss mit diesem arbeitsverzeichnis gestartet werden.