„Sposób OSGi” polega na tworzeniu oddzielnych pakietów zawierających dyskretne, spójne elementy funkcjonalne. Czasami te pakiety zawierają klasy narzędzi, czasami zależą od klas narzędzi i konfigurują własne usługi OSGi.

Użytkownicy raczej nie będą narażeni na pakiety. Dbają bardziej opodanie, oprogramowanie, które wykonuje zadanie lub rozwiązuje problem. Zwykle aplikacja używa wielu pakietów (powiedzmy, importowanych przez Import-Package) do wykonywania swoich zadań.

Jaki jest najlepszy sposób sformalizowania tej relacji w świecie OSGi? Przykładowym wymaganiem byłoby coś tak prostego, jak pokazanie aktualnego numeru wersjiaplikacji (nie pakiet) do użytkownika. Jak odkryłby ten numer wersji?

Eclipse ma koncepcję zwaną „funkcjami”, ale nie jest to standard OSGi.

Peter Kriens manapisał o aplikacjach OSGi a jego artykuł ma sens. Odejdę od tego, że aplikacja może mapować do pakietu; po prostu pakiet korzysta z innych pakietów w jakiś sposób. Ale jeśli chce się utworzyć pakiet aplikacji za pomocą Import-Package, nie widzę, jak można to zrobić z punktu widzenia rozwoju.

Jednym ze sposobów może być posiadanie „pakietu aplikacji”, który używa pakietu Require-Bundle i ma własną wersję, ale Require-Bundle nie jest mile widziany w świecie OSGi.

Używanie Import-Package do importowania wszystkich wymaganych pakietów z wymaganymi wersjami dodaje jednakznaczący koszty utrzymania dla dewelopera do tego stopnia, że ​​nie wydaje mi się to wykonalne. Za każdym razem, gdy dokonywana jest najmniejsza zmiana, nawet w pakiecie implementacyjnym, wersja pakietu musi zostać zaktualizowana, a następnie zależność od wersji pakietu zaktualizowana w „pakiecie aplikacji”.