Maven csomagépítés ügyfélre szabottan (best practices)

Java

Hi,

A cím kb. a Maven customized release management best practices :) témakört fedné le :).

Van egy wicket alapú alkalmazásom mindenféle környezetfüggő properties fájllal megtűzdelve.

- Application.properties
A rendszer által használt általános paramétereket tartalmazza
- database.properties
host, db stb.
- log4j.properties

A cél az lenne, hogy az ügyfél környezetétől függően (db és egyéb paraméterek) tudjak war-t előállítani. Vidámabb lennék, ha nem kellene minden deploy után ezeket újra állítani. Erre várnám az ötleteket.

Köszönöm!

  • 4960 megtekintés

Alapvetően a profile-ok erre jók, más kell dev környezetben más teszten és élesben. De az egyéb alkalmazásszintű konfigurációkat érdemes az alkalmazáson kívül tárolni, lehetnek az alapbeállítások az alkalmazásban, de lehetőséget kell teremteni ezek felüldefiniálására, pl. hogy ha megváltozik a db ipcíme, akkor ne kelljen új verziót kiadni.
Azt tudom hogy a log4j konfigurálható külső útvonalról.

( vicziani | 2012. 09. 25., k – 11:26 )

Szia,

Ezzel a Maven egyik alapelvét szeged meg, hogy egy projekt, egy artifact. A profile-okat is lehetőleg kerülni kéne.
A javasolt megoldás, hogy mindenhova ugyanazt az artifact-ot teszted ki, és a környezet tartalmazza a beállításokat. Pl. DataSource, JNDI, properties állományok. Ezzel nagyfokúan egyszerűsíted az életed. Ez a szabványos mód is, így tudja managelni az üzemeltetés. Gondold bele, egy ip változáshoz új alkalmazást kell kiadni?
Ha mégis nagyon más kéne, én külön projekteket csinálnék hozzá, ügyfelenként, a profile-os megközelítést nem preferálom. De ez csak az én véleményem.

Viczi
http://jtechlog.blogspot.com

Rengeteg megoldás létezhet.
Mi Tomcat-ben mindent JNDI-be tettünk, azaz a server.xml-ben tároltunk.
Pl.: http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html, lásd env-entry.
De lehet ezt odáig is bonyolítani, hogy megnézed, hogy pl. itt van-e egy path megadva a property fájlra. Ha van, akkor onnan olvasod fel, ha nincs, akkor pedig classpath-ról. Így a fejlesztőknek semmit nem kell állítani, mert checkout után a classpath-ról felolvasott property-ről megy. De lehet pl. environment property-ből is felszívni, ahogy a Log4J csinálja.

A lényeg, hogy ne az alkalmazásban legyen a környezeti információ (max. a default, fejlesztési környezeté).

Viczi
http://jtechlog.blogspot.com