Myslim ze kumulativne byt to bolo menej bolestive aj pre mna
aj pre klienta.
Tak aby som to zhrnut (verziu tri budem pouzivat ako verziu na ktoru chem updatovat): 1. updater bude obsahovat iba kniznice ktore je nutne updatovat na verziu 3 a vsetky tieto kniznice budu automaticky skopirovane do povodne naistalovanej verzie 2. v updateri bude subor so zoznam kniznic (suborov) ktore sa vo verzii 3 uz nenachadzaju a tie budu automaticky vymazane z naistalovanej verzie 3. body 1. a 2. budem prevadzat pre tieto casti: jar, ejb, xml a ine subory. War subory musia byt rozbalene a az potom sa moze updatovat! 4. vsetky subory ktore obsahuju nejake specificke informacie (napr. connection settings, custom properties) predtym zadane v instalatore alebo configuracii povodnej aplikacie
musia byt prenesene do novych (updatnutych suborov)
tam my vychadza ako dobra pomocka ulozit si vsetky specificke nastavenia z instalovania do jedneho properties suboru a tento subor by bol ulozeny v povodnej applicakacii) takze este pred updatom budem musiet povytahovat z applikacie vsetky klientske zmeny (keby som to robil hned od verzie 1 nemusel som mat starosti :) )
5. no a samozrejme nakoniec zas vsetko zbalit a nastartovat

Takze podla tohoto systemu moj updater bude obsahovat uz len nove kniznice (nie tie kniznice co sa nemenili) to je trosku zmena oproti tomu co som mal v hlave predtym kde updater obsahoval vsetko a tak mi teraz vlastne odpada problem
manazovania ktore kniznice updatnut.

Som rad ze sa mi podarilo si to hlave trochu zrovnat o co sa vlastne budem snazit.

Diky za pomoc
Dufam ze som uz nic nezabudol co by ma mohlo potrapit.
Robo

Roman Pichlík wrote:
no a nebylo by lepsi, kdyby zaplata ve verzi 3. byla kumulativni, tedy
ze by obsahovalo to co bylo updatovano jak pro verzi 1. tak 2?. Pokud
to tak nejde, tak bych vyzadavoal, aby uzivatel nejdrive naaplikoval
zaplatu 1. a potom 2. Delat nejake hashe a porovnavani mi prijde jako
koledovani si o pruser.

On Fri, Sep 12, 2008 at 7:55 PM, Robert Koncier <[EMAIL PROTECTED]> wrote:
Dik za radu Roman.

Takto nejako som si to predstavoval,
aj ked este nemam moc jasno okolo mechanizmu
ako sa rozhodujem ktoru kniznicu updatnut a ktoru nie.

Uz len pripad ked tym istym updatom (napr na verziu 3) by som mal byt
schopny
updatnut verziu 1 a aj verziu 2, to znamena ze updater musi obsahovat
zmenene kniznice
voci verzii 2 ale aj voci verzii 1 (cize vseobecne vsetky kniznice pre novu
verziu).

Viem ze nemozem porovnavat datumy vytvorenia kniznic a ani porovnavanie
velkosti
nie je vhodny sposob rozhodovania ktora kniznica je zmenena.
A tak isto robit nejake staticke zoznamy suborov  ktore treba updatnut pre
verziu 1 potom pre
verziu 2 atd... nie su dost pohodlne na pracu pre ant.

Rozmyslal som o sposobe rozhodovania na zaklade cisla verzie ktore mozno
naist v manifeste
ale zistil som ze vela kniznic verziu neobsahuje.

Tak neviem ci nebudem vytvarat nejaky hashcode pre kazdu kniznicu v ear
baliku
a ak je hashcode rozdielny tak prevediem update pre danu kniznicu ak je
rovnaky tak kniznicu
necham tak. Myslis ze by to fungovalo?

Robo


Roman Pichlík wrote:
Nevim jestli je na to nejaky vzor, ale dost o tom pochybuji. My jsme
to udelali tak, ze jsme si postavili vlastni update tool. V
jednoduchosti funguje tak, ze vezme dany patch (politicky spravne
nazyvany update) a:

- rozbali se
- zkontroluje se verze na kterou muze byt aplikovan plus zavislosti na
jinych patches (jednoduchy XML deskriptor)
- vezme se EAR a pripadne WARy, ktere se rozbali
- na predem definovanem miste uvnitr patche se najde Anti build file a
spusti se dohodnuty target. Jako vstup je mu predan adresar s
rozbalenym EARem
- na konci se EAR a WARy zase zabali a uzivatel je vyzvan, aby si EAR
redeploynul

2008/9/11 Robert Koncier <[EMAIL PROTECTED]>:

Ahoj vsetci,

chcel by som Vas poprosit o radu akym smerom ist pri rieseni instalatora
zaplat.
Aby som blizsie vysvetlil o co mam vlastne zaujem.

Mam java enterprise aplikaciu balenu v ear subore (je tam zopar EJBs a
zopar
WARs a mnozstvo JARs)
beziacu pod weblogicom a jbossom az uz mam tej mojej applicacie tretiu
verziu.
Pokazde sa menilo dost kodu a dost
kniznic je novych alebo sa vymazalo/pridalo zopar suborov.
Zakazdym som novu verziu riesil preinstalovanim povodnej co vsak uz dalej
nie je mozne a musim to vyriesit akymsi instalatorom zaplat (alebo
updater).

Aby som povedal pravdu, tak nemam ani zdanie ako to urobit
alebo akej chytrej myslienky sa drzat.
Exituje nejaky osvedceny postup (nejaky pattern) ako to urobit ako
manazovat
zmeny
aby vedel instalator zmenit spravne veci.

V konecnom dosledku by som si chcel na to napisat
ant skript a pouzit ho v antInstalleru.

Dakujem za kazdu radu, za kazde nakopnutie spravnym
smerom alebo odkaz na nejaky open project kde sa nieco podobne
pouziva.

Mozno ze moja myslienka je uplne chybna a existuje uplne iny sposob
drzania applikacie uptodate - prosim poradte ak viete.

Dakujem
Robo








Odpovedet emailem