17.12.2007

Máme

1. hotovou impl pro KF
2. jméno pro projekt (OBCC, OSGi Bundle Compatibility Checks)

Úkoly do Vánoc

• názvy balíků: KF patch = cz.zcu.kiv.obcc.kfcore, KF bundle = cz.zcu.kiv.obcc.kfXXXXX
• udělat binární patch pro KF + INSTALL popis
• doc: (1) neskloňovat "bundle", (2) doplnit odkazy na zdroje
• oboje mi pls poslat
• dát to do SVN (struktura: top-level adresář "KF", v něm trunk/ a taky releases/ do kterého finální impl KF)

(!) KF má bundle cache, při odinstalaci a následné instalaci ji používá => vynucení instalace buď změnou datumu buildu v Manifestu, nebo ručním vyčištěním cache (fwdir adresář)

10.12.2007

(!) KF nebere v potaz Manifest systémového bundle => exporty apod řeší ručně v kódu.

• (tj. ne tak jak napsáno v konceptu řešení z minula, zatím neřešit přes událost, ale implementaci kontrolovaného update udělat uvnitř KF a vystrčit do fasády high-level metody)

• fasádovou třídu do Framework bundle, která zpřístupní metody cca UpdateStandard?() [= Framework.BundleUpdate?()] a UpdateChecked?(). Tyto metody využije náš update controller bundle.
• tj. ne tak jak napsáno v konceptu řešení z minula, zatím neřešit přes událost, ale implementaci kontrolovaného update udělat uvnitř KF a vystrčit do fasády high-level metody

Zjištěno

3.12.2007

• KF BundleArchive? -> memory/disk impl, ta "memory" neumi vratit JAR path (vraci null)
  • kdyby se chtěly kontroly dělat na memory KF variantě, musela by se napsat rekonstrukce JAR archivu z paměťových dat -> zatím nebudeme řešit, kdyžtak se k tomu vrátíme až bude hotova impl pro disk.

Udělat

• fasádovou třídu do Framework bundle, která zpřístupní metody cca UpdateStandard?() a UpdateChecked?(). Tyto metody využije náš update controller bundle.

Problém: v KF se nedá legálně dostat na .jar instalovaných/běžících bundlů (fw používá Bundle-UpdateLocation? který ale není nastavován, resp. "Location" odkud by stažen).

JB+PB: zjistit jestli se zastavují depending bundles když se daný updatuje (?navrhnout AboutToUpdate? událost-bcast).

26.11.2007

JB+PB: zjistit jestli se zastavují depending bundles když se daný updatuje (?navrhnout AboutToUpdate? událost-bcast)

Návrh konceptu řešení pro KF

1. jít do střev
2. fasádové API nad interní impl KF
3. využít BundleStorage?
4. modifikovat Framework.BundleUpdate?() metodu
5. před update vyhodit AboutToUpdate? událost
6. problém s kompatibilitou => Unresolved

Analogickou analýzu pro Felix.

• DEADLINE 3.12. prezentovat toto ve spojeni se stavajicim komparatorem

Vyhled

• dal pak loborovat na komparatoru (decl service spec)

5.11.2007

• prozkoumat proces aktualizace bundle (1) uzivatelsky, (2) jake udalosti ve frameworku vznikaji => jestli se da dostat na ctx/classloader/.jar stare verze a nove verze

• Pracovni osobni wiki

12.10.2007

• prozkoumat jak funguje ruční a decl spec service registrace a binding uvnitř KF
• => návrh jak napíchnout komparátor
• s PS převzít komparátor

• Organizační informace
• Zdroje
  • OSGI 4.1 spec
  • Knopflerfish
  • Felix

18.9.2007

Další schůzka cca 1.10.2007

• udělat si aplikaci v OSGi (knopfler, až bude tak ji cvičně testnout na Felix)

Později

Organizační informace

Bod zadání 1. "Seznamte se s platformou OSGi a jejími implementacemi, včetně služeb pro správu komponent a jejich vazeb."

• existuje v OSGi (a) wire admin service která umí dynamickou správu závislostí, (b) declarative service specs - oboje bude potřeba trochu prozkoumat

Dále

• od Lukáše převzít do správy komparátor

Kontrola nahraditelnosti komponent v platformě OSGi

Kontrola nahraditelnosti komponent v platformě OSGi

Organizační věci