Üdv!
Van egy "érdekes" problémám/ánk. A helyzet a következő, réges-régen elkezdtünk egy projektet fejleszteni akkor még Struts alapokon, később a Spring is bejött. Aztán szép lassan, ahogy jöttek a megrendelések más cégektől a projekt szétbomlott modulokra és ezeket a modulokat újra hasznosítottuk más projektekben.
Most ha van egy új cég akik megbíznak minket, úgy néz ki a dolog, hogy szépen fogjuk csinálunk a cégeknek egy backend és egy frontend modult és a CVS-ből behuzzuk azokat a modulokat amikre szüksége van az adott ügyfélnek.
Példa:
Kati nyit egy virágboltot, szeretné ha tudna számlázni, virágot szállítani és megrendelést felvenni. Akkor neki kell a számlázás modul, a szállítmányozás modul és a megrendelésfelvétele modul. Egy modul valójában mindig két modult takar, mert minden mondulnak vagy egy frontend és egy backend része.
Pisitike az új ügyfél nyit egy turbórágó boltot és szeretné ha tudna számlázni, de az árút csak helyben lehet átvenni, mert elolvadna mire kiszállítaná, korszerű hűtőberendezésre meg nincs pénze. :)
Tehát neki csak a számlázás modul kell.
(Direkt nem autós!)
És itt jön a bibi, a számlázós modul a CVS Head repojába található, ha most az új Pistike workspace-be ki check-eljük és elkezdjük módosítani az üzleti logikát meg a frontendet, akkor amint commitoltuk az újításokat Katinak az oldala tönkremegy, mivel ugye ő is ezt a modult használja..
Sajnos beleestünk abba a csapdába, hogy újra akarunk hasznosítani, viszont mikor jön a projektvezető, hogy de jó lenne ha ez a gomb nem ott lenne hanem itt, vagy kéne pár új input mező, akkor nem mondhatjuk neki, hogy sajnos ez nem megoldható, mert akkor Katinál is megjelennek az új mezők. Ezért arra, gondoltunk, hogy minden mondulba lesz egy default kinézet, konfig és amikor kapunk egy új megbízást, akkor a szükséges modulokat ki checkelve a build script fogja és szépen ezt a default modulkonfigot áthúzza a megbízó backend és frontend monduljába (JSP-stől, CSS-estől kezdve mindenig). Ekkor ott már kedvünkre változtathatjuk a dolgokat, mert ügye ez projektenként változó. Az alap modulokra mégis azért van szükség, mert a Java osztályokat meghagyjuk ott és az egyedi modulba csak kiterjesztjük azokat és úgy változtatjuk.
Most így néz ki egy JBoss deploy:
kati_projekt.ear
|
|--Application_kati_Backend.jar
|--Application_kati_Frontend.war
|
|--Module_Szamlazas_Backend.jar
|--Module_Szamlazas_Frontend.war
|
|--Module_Szallitas_Backend.jar
|--Module_Szallitas_Frontend.war
|
|--Module_Megrendeles_Backend.jar
|--Module_Megrendeles_Frontend.war
pistike_projekt.ear
|
|--Application_pistike_Backend.jar
|--Application_pistike_Frontend.war
|
|--Module_Szamlazas_Backend.jar
|--Module_Szamlazas_Frontend.war
A jelenlegi problémák között található pl az, hogy minden modulnak külön session-je van. Ezért ha átlépsz egy modulból egy másikba, ott nem lesz meg az, hogy te most éppen be vagy jelentkezve vagy nem. Ezért a JBoss SSO-jat használjuk, de ez annyira nem jó nekünk. Akkor például, ha valaki nyelvet vált az egyik modulba és a sessionbe letároljuk, hogy az aktuális nyelv kínai, akkor modult váltva megint vissza fog ugrani a nyelv az alapértelmezettre, mert az ottani session-be ez nincs lementve.
A merge-elés ezt is megoldaná, de ez még csak egy felvetés, a megvalósításról eddig nem sok szó esett. Olyan gondok is vannak, hogy akkor, hogy lesz megoldva a Spring konfig fájlok használata, mert ugye most minden mondulba külön web.xml van és külön akarmi-servlet.xml.
Egy másik gond, hogy az egyik modul még Struts 1.1-el üzemel. Ami enyhén szólva is brutális, olyan táblázatokat generál a Struts taglib, hogy ember legyen a talpán aki azt CSS-el megformázza, ezt a modult szeretnénk migrálni Spring-re, de az is elég sok bonyodalmat okoz.
A kérdésem, hogy ti hogy oldjátok/oldanátok meg ezeket a problémákat, van-e erre valami bevett szokás?
szerk: Úgylátom valaki már találkozott pont ugyanezzel a problémával. Az egyetlen különbség, hogy mi Ant-ot használunk.