Instalator zaplat

Roman Pichlík roman.pichlik na gmail.com
Pátek Září 12 20:01:18 CEST 2008


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 <rkoncier na qenet.net> 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 <rkoncier na qenet.net>:
>>
>>>
>>> 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
>>>
>>>
>>
>>
>>
>>
>
>



-- 
S pozdravem Roman "Dagi" Pichlik

/* http://www.sweb.cz/pichlik/ Blog pro kodery */



Další informace o konferenci Konference