NetBeansowy pracowniks oraz czyszczenie eclipsowego p2

Zainspirowany problemem tworzenia aplikacji ze szkieletem Visual Web JavaServer Faces (vel Woodstock) w dyskusji
Połączyć DataModel z komponentami Visual Web JSF na pl.comp.lang.java po dłuższej przerwie wróciłem do NetBeans IDE. Woodstock jest zbiorem kontrolek do budowania interfejsu użytkownika JSF i w zasadzie spodziewałem się, że wszystko, czego zasmakowałem w "czystym" JSF ma zastosowanie i w nim. Zdaje się, że pomyliłem się w stosunku do kontrolki webuijsf:tableRowGroup, której atrybut sourceData nie akceptuje komponentów typu DataModel (!) Temat opiszę niebawem, ale do napisania tego wpisu skłoniła mnie zabawna sytuacja z generowaniem nazw zmiennych w NetBeans IDE korzystając z Ctrl+SPACJA. Wystarczyło napisać private Pracownik[] i wcisnąć wspomnianą kombinację klawiszy Ctrl+SPACJA i...


Przez moment nie mogłem dojść do ładu, skąd ta nazwa zmiennej - pracowniks. Dopiero po pewnym czasie zorientowałem się, że jest to angielska liczba mnoga dla typu Pracownik z tablicy. Natychmiast pomyślałem o Asteriksie ;-) Ech, tylko do czego użyć typu Asterik?! Może inne śmieszne zmienne?

Kolejną ciekawostkę znalazłem na grupie eclipse.technology.equinox, która dotyczyła działania Equinox p2. W ogóle, ostatnimi czasy o niczym innym się tam nie rozmawia, tylko o p2. Jeśli zaczyna brakować Ci dysku (mimo jego początkowej, niewyobrażalnej wręcz objętości), to może warto zainteresować się katalogiem p2/org.eclipse.equinox.p2.engine/profileRegistry/?

 jlaskowski@work /cygdrive/c/apps/eclipse
 $ du -sh p2/
 249M    p2/

 jlaskowski@work /cygdrive/c/apps/eclipse
 $ du -sh features/ plugins/
 6.8M    features/
 215M    plugins/

Dosyć dużo, nieprawdaż? Okazuje się, że Eclipse uruchamiając p2, wzbudza jakąś tam funkcjonalność, która odkłada we wspomnianym katalogu dość obszerny plik profile. Jakkolwiek planuje się ich wykorzystanie w Eclipse IDE 3.5, to w 3.4 zdają się być niepotrzebne. Zatem wystarczy pozostawić ostatnie 5 najmłodszych plików i zaoszczędzić trochę miejsca.

 jlaskowski@work /cygdrive/c/apps/eclipse
 $ ls p2/org.eclipse.equinox.p2.engine/profileRegistry/PlatformProfile.profile/ | wc -l
 46

 jlaskowski@work /cygdrive/c/apps/eclipse
 $ cd p2/org.eclipse.equinox.p2.engine/profileRegistry/PlatformProfile.profile

 jlaskowski@work /cygdrive/c/apps/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/PlatformProfile.profile
 $ ls -t | tail -n +6 | xargs rm

 jlaskowski@work /cygdrive/c/apps/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/PlatformProfile.profile
 $ du -sh .
 27M     .

Ja już mam to za sobą.

Repozytoria pakunków OSGi

Istnieje kilka repozytoriów pełnoprawnych pakunków OSGi (z odpowiednimi nagłówkami w manifeście) dla popularnych projektów otwartych:

• SpringSource Enterprise Bundle Repository (aka BRITS)
• Spring-DM OSGi Repository
• Eclipse Orbit
• Knopflerfish bundle repository
• Apache Felix Commons
• OSGi Bundle Repository (OBR)
  

Naturalnym jest, że skoro pakunki OSGi są zwykłymi plikami jar z odpowiednimi nagłówkami w manifeście (cf. Kolejny łyk OSGi - rozdział 3. Warstwa modułowa) dowolne repozytoria mavenowe (np. http://repo1.maven.org/maven2/) lub dowolne inne udostępniające jary, mogą być używane przy zestawianiu środowiska z wymaganymi zależnościami. Problemem jest określenie zależności między pakunkami poprzez nagłówki Import-Package, Export-Package, Ignore-Package, Private-Package, DynamicImport-Package i in. dla zwykłych plików jar, co nie jest obsługiwane przez Platformę OSGi bez dodatkowej pracy przy ich konfiguracji jako pakunki. Właśnie to jest zaletą pobrania plików jar z w/w repozytoriów - posiadanie gwarancji, że są one poprawnymi pakunkami. Założeniem repozytoriów jest udostępnianie poprawnie skonfigurowanych pakunków ze wszystkimi wymaganymi nagłówkami. Jako, że są to oddzielne repozytoria, zarządzane przez różne osoby, czasami prowadzi to do sytuacji, gdzie pakunek X w repozytorium R1 ma inne wymagania niż pakunek X w repozytorium R2 (niestety w tej chwili nie mogę znaleźć informacji o zgłoszonej rozbieżności między Orbit a BRITS). Światło na ich przydatność może rzucić wątek - BRITS vs. Temporary Spring-DM Repo, gdzie mimo prowadzenia dwóch repozytoriów przez pojedyńczą firmę SpringSource, nawet one mają niepoprawnie zdefiniowane pakunki.

Rozwiązaniem rozmieszczenia pakunków w repozytorium jest specyfikacja OSGi RFC 112 Bundle Repository. Innym sposobem zaradzenia problemom z nieścisłymi deklaracjami pakunków jest projekt Pax URL, który pozwala na instalację dowolnego pliku jar dostępnego poprzez inne protokoły dostępu niż domyślne http czy file, np. classpath, mvn, wrap lub narzędzie bnd. Bez względu jakiego narzędzia zastosujemy, część pracy i tak będziemy musieli wykonać samodzielnie, np. przy wykorzystaniu mechanizmu prześwietlania w Javie (Reflection API), gdzie nazwa klasy podawana jest niejawnie. W takiej sytuacji skorzystanie z gotowego pakunku dla popularnego projektu otwartego z w/w repozytoriów może być najmniej czasochłonnym rozwiązaniem (jeśli istnieje).

Zabawa dla wytrwałych i dociekliwych: Co oznacza skrót BRITS będący alternatywną nazwą dla repozytorium SpringSource Enterprise Bundle Repository? (odpowiedzi można szukać w SpringSource Application Platform ships).

Eclipse IDE 3.5M2 a Eclipse Equinox i OSGi R4.2

Dzisiaj, podczas pobierania pełnej wersji Equinoksa (wraz ze wszystkimi dostępnymi pakunkami) - eclipse-equinox-3.5M1.zip pojawił się poniższy komunikat:

The Equinox downloads are meant as a base for building OSGi applications. As such, they do not include an application of their own and simply running the framework will do nothing.

Teraz już wiem, co autorzy mieli na myśli. Po prostu pobieram samo środowisko uruchomieniowe dla pakunków OSGi (w świecie Eclipse będą to wtyczki), bez których nie ma co oczekiwać funkcjonalności oferowanej przez Eclipse IDE. Podobnie jak z serwerem aplikacyjnym Java EE 5, bez aplikacji korporacyjnych, nie ma czego więcej oczekiwać od niego, poza udostępnieniem usług, na bazie których można je konstruować. Dodatkowo, komunikat może być o tyle ważny, gdyż po pobraniu paczki Eclipse Equinox 3.5M1 i rozpakowaniu, pojawi się katalog eclipse z podkatalogami features oraz plugins, co idealnie odpowiada strukturze bogatego funkcjonalnie Eclipse IDE (w końcu to nic innego jak zestaw wtyczek w katalogu plugins uruchamianych na Equinoksie).

Uważni obserwatorzy projektu Eclipse IDE zauważyli zapewne pojawienie się wersji Eclipse IDE 3.5M2, w której pojawiły się zmiany w obszarze Equinoksa (opisane w dokumencie Eclipse 3.5 M2 - New and Noteworthy dla Equinox):

Security Manager enhancements
This milestone includes an implementation of RFC 120 from the OSGi R4.2 draft specification. RFC 120 specifies enhancements to the Conditional Permission Admin service which is used to manage the permissions assigned to bundles. The enhancements include adding the ability to grant or deny permissions based on conditions, and to manage conditions as an ordered list of rules. For more information see the OSGi R4.2 draft spec.

oraz

New publisher bundle
p2 has introduced a new bundle called the publisher, which provides infrastructure for generating, packaging, and publishing metadata and artifacts into p2 repositories. The publisher provides an extensible API that clients can extend to perform customized publishing to repositories, and includes an advice mechanism for injecting additional metadata into the generation and packaging process.

Nie powinno dziwić, że Equinox przewodzi peletonowi platform OSGi zabierając się za realizację specyfikacji OSGi R4.2, która jakkolwiek w fazie szkicu, potrzebuje środowiska referencyjnego, aby pomóc w akceptacji proponowanych funkcjonalności przez programistów. Dla Java EE 5 referencyjną implementacją jest GlassFish, a dla OSGi jest nią Eclipse Equinox. Zastanawiam się jednak, czy powinienem prowadzić doświadczenia z Equinoksem dystrybuowanym w ramach Eclipse IDE (org.eclipse.osgi_3.5.0.v20080916-2300.jar), czy pobierać bezpośrednio ze strony domowej Eclipse Equinox (org.eclipse.osgi_3.5.0.v20080804-1730.jar). Aktualność samodzielnego Equinoksa nie pozostawia złudzeń - ten dystrybuowany z Eclipse jest aktualniejszy oraz gwarantuje się jego działanie przez włączenie do Eclipse IDE, więc od razu przechodzę na niego. Kilka dni temu próbowałem pobrać wersję Eclipse Equinox 3.5M2 i niestety, ale kończyło się na "404 File Not Found". Może jutro?

p.s. Od momentu zainteresowania OSGi doszła mi kolejna sekcja, którą monitoruję pod kątem zmian w Eclipse - sekcja "Equinox" w "New and Noteworthy". A u Ciebie? ;-)

Katalog plugins i automatyczna instalacja pakunków OSGi na Equinoksie

Już kiedyś wspominałem o tym dokumentcie - Equinox QuickStart Guide - ale nigdy jakoś nie usiadłem nad nim i dokładnie przeanalizowałem jego treści. Tym razem jednak, po kilku dniach zestawiania potrzebnych pakunków do uruchomienia Spring-DM 1.2.0-m2-SNAPSHOT na Eclipse Equinox i przekroczeniu 10 pakunków koniecznych do jego uruchomienia, stwierdziłem, że wystarczy tych ręcznych robótek i pora skrócić moje cierpienia - pójść po rozum do głowy i skorzystać z ułatwień, które są na wyciągnięcie ręki - automatyczne uruchamianie pakunków przy starcie Equinoksa. Przy okazji, poznając działanie Equinoksa poznajemy działanie całego Eclipse, który mechanizm wtyczek oparł całkowicie o OSGi z Equinox w roli środowiska uruchomieniowego.

Podczas uruchamiania Equinoksa poleceniem

 java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

uruchomiony zostaje automatycznie pakunek systemowy - org.eclipse.osgi. Ma on identyfikator 0 i będzie tak na każdej platformie OSGi (oczywiście nazwa pakunku systemowego będzie inna, specyficzna dla danej platformy).

 jlaskowski@work /cygdrive/c/apps/equinox
 $ java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730

Przy pierwszym uruchomieniu tworzony jest katalog configuration w katalogu bieżącym (z możliwością wskazania innego parametrem -configuration).

 jlaskowski@work /cygdrive/c/apps/equinox
 $ ls -lt
 total 988
 drwxr-xr-x+ 3 jlaskowski None       0 Sep 28 21:27 configuration
 -rwx------+ 1 jlaskowski None 1009283 Sep 22 16:07 org.eclipse.osgi_3.5.0.v20080804-1730.jar

Instalacja pakunków odbywa się poleceniem install <plik_pakunku>. Jeśli założę katalog plugins (na razie przyjmijmy, że jest to nazwa całkowicie przypadkowa), a w nim umieszczę pakunek spring-osgi-core-1.2.0-m2-SNAPSHOT.jar, jego instalacja będzie wyglądała następująco:

 jlaskowski@work /cygdrive/c/apps/equinox
 $ java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730

 osgi> install file:plugins/spring-osgi-core-1.2.0-m2-SNAPSHOT.jar
 Bundle id is 1

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730
 1       INSTALLED   org.springframework.bundle.osgi.core_1.2.0.m2-SNAPSHOT

Kolejne uruchomienie platformy OSGi gwarantuje uruchomienie pakunków do stanu, który był bieżącym przed zatrzymaniem całej Platformy, np. poleceniem close dla Equinoksa. Właśnie katalog configuration jest katalogiem, gdzie utrwalone zostają informacje o stanie pakunku (i skasowanie go powoduje skasowanie danych pakunków, co równoważne jest z uruchomieniem początkowym Equinoksa).

 jlaskowski@work /cygdrive/c/apps/equinox
 $ java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730
 1       INSTALLED   org.springframework.bundle.osgi.core_1.2.0.m2-SNAPSHOT

Przy pojedyńczym pakunku sprawa jego instalacji i uruchomienia nie jest poważnym zadaniem. Sprawa zaczyna się komplikować, kiedy przychodzi nam uruchomić, powiedzmy, 20 pakunków. Wtedy pozostaje nam liczyć na poprawny katalog configuration, albo...config.ini.

Plik config.ini w katalogu configuration jest plikiem konfiguracyjnym Equinoksa, w którym definiuje się, jakie pakunki mają zostać uruchomione i gdzie one w ogóle się znajdują. Dodając do tego wsparcie pakunku org.eclipse.update.configurator nie musimy umieszczać nazw wszystkich pakunków do instalacji w pliku config.ini, a wystarczy umieścić je w katalogu plugins.

Zatem plik config.ini prezentuje się następująco:

 eclipse.ignoreApp=true
 osgi.bundles=org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start

a sama struktura katalogowa tak:

 |____configuration
 | |____config.ini
 |____org.eclipse.equinox.common_3.4.0.v20080421-2006.jar
 |____org.eclipse.osgi_3.5.0.v20080804-1730.jar
 |____org.eclipse.update.configurator_3.2.200.v20080417.jar
 |____plugins
 | |____spring-osgi-core-1.2.0-m2-SNAPSHOT.jar

Pakunek org.eclipse.equinox.common pobrałem ze strony Equinox Stable Build: 3.5M1, natomiast org.eclipse.update.configurator znalazłem w katalogu Eclipse Ganymede w plugins (nigdzie indziej nie mogłem go namierzyć).

Przy powyższej konfiguracji każdy z pakunków umieszczonych w katalogu plugins będzie zainstalowany automatycznie podczas uruchomienia Equinoksa.

 jlaskowski@work /cygdrive/c/apps/equinox
 $ java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730
 1       ACTIVE      org.eclipse.equinox.common_3.4.0.v20080421-2006
 2       ACTIVE      org.eclipse.update.configurator_3.2.200.v20080417
 3       INSTALLED   org.springframework.bundle.osgi.core_1.2.0.m2-SNAPSHOT

Z pewnością znacząco uprości zabawę z uruchomieniem wszystkich pakunków Spring-DM niezbędnych do uruchomienia aplikacji webowych na Apache Tomcat 6.0.18 w ramach Equinoksa. Do tej pory wymagało to ręcznego uruchamiania około 20 pakunków przy każdorazowym usunięciu katalogu configuration (!)

WAS 7.0 już jest oraz JDD 2008 i NetBeans Day 2008 nadchodzą

Nie mogłem doczekać się, aż to opublikuję i w końcu jest! Wielki dzień dla społeczności Korporacyjnej 5-tki (Java EE 5), gdyż IBM wypuścił na runek długooczekiwany produkt IBM WebSphere Application Server V7.0 (IBM WebSphere Application Server V7.0 delivers an agile, solid foundation for SOA to align the advancements of business and IT). Nie planuję rozpisywać się nad jego możliwościami, bo są one znane i (nie)lubiane ;-) Ważne, że czekamy jedynie na JBoss AS 5, który ma zamknąć okres rozwoju serwerów aplikacyjnych w ich krucjacie do pełnego wsparcia specyfikacji Java EE 5. Szczęśliwcy, którzy mogą już pracować z Korporacyjną 5-tką, a wszystkim pozostałym zaleca się natychmiastową migrację na nową platformę. Zdaje się, że kolejnym obowiązkowym elementem serwerów aplikacyjnych Java EE 5 będzie OSGi. Niewiele serwerów udostępnia możliwość uruchamiania aplikacji korporacyjnych budowanych na bazie pakunków, ale wiele korzysta z nich wewnętrznie. Sądzę, że wsparcie dla OSGi będzie kolejnym dużym krokiem w rozwoju serwerów aplikacyjnych, czym znacznie powinny uprościć tworzenie złożonych aplikacji korporacyjnych. W niezwykle ciekawych czasach żyjemy (i wciąż żyjemy, mimo codziennych ochów, echów, i innych sercowych atrakcji, nie wspominając o wszechobecnym stresie ;-))!

Korzystając z chwili rozgłoszę również dwie nadchodzące imprezy, których mam przyjemność być aktywnym uczestnikiem - JDD 2008 w Krakowie oraz NetBeans Day 2008 w Poznaniu i Gdańsku. Pierwsza już za niecałe 3 tygodnie - 16 października, a druga tydzień później - 25 października w Poznaniu, po czym kolejnego dnia - 26 października - przenosi się do Gdańska. Już nie mogę doczekać się podzielenia się z Wami nowinkami z obszaru OSGi i Spring Dynamic Modules (Spring-DM) w Krakowie, a przeglądem nowości NetBeans 6.5 w Poznaniu i Gdańsku. Już od miesięcy przygotowuję się do występów, więc merytorycznie jestem przygotowany conajmniej na 3+ ;-) Dodatkowe pytania i sugestie, o czym chcielibyście posłuchać w kontekście Spring-DM, a później NetBeans IDE 6.5 mile widziane. Nikt nie życzy sobie spędzenia godziny na moim przedłużającym się wystąpieniu, więc stwórzmy miejsce wymiany doświadczeń, gdzie zostanie zaprezentowanego wiele technicznego materiału i pojawią się ciekawe pytania. Liczę na Was, nie mniej niż Wy na mnie!

Za kilka dni - 7 października o godz. 19:00 - w Warszawie odbędzie się pierwsze spotkanie blogerów piszących o IT dla pasjonatów IT - Bloggers Underground. Spotkanie organizowane przez grupę microsoftową, aczkolwiek obiecano, że będzie wyłącznie merytorycznie (czyli nie pojawią się wstawki jaka to Vista jest cacy i takie tam). Zaproszony, od razu zapisałem się z nadzieją podpatrzenia, jak inni sobie radzą w temacie dzielenia się wiedzą poprzez blogi (nawet, jeśli zajmują się niszowymi rozwiązaniami spod znaku MS ;-)). Zawsze wierzę, że poznawanie nowych osób, to miejsce na nowe pomysły i tym razem jestem przekonany, że nie będzie inaczej. Zapraszam w imieniu organizatorów.

Jeśli Ty wciąż zastanawiasz się, czy blog mógłby być dla Ciebie źródłem inspiracji i pomysłów zapraszam do lektury Najlepsze nasiona (gdzie nie będzie ziaren EJB, a jedynie nasiona, ale i tak warto). Autorka już niejeden raz ciekawie przedstawiła otaczającą mnie rzeczywistość i chętnie czytam jej wpisy, a teraz mogę wskazać jeden jako argument do założenia własnego bloga. Jeśli go nie masz, to właśnie dzisiaj jest ten dzień, abyś miał. Jeśli nie blog, to przynajmniej udział w grupie jugowej w Twoim mieście, organizacja konferencji, albo chociażby nieformalne spotkanie w grupie entuzjastów javowych. Cokolwiek, ale odejdź w końcu od komputera i spotkaj się z kimś nowym! Niedługo Warsjava+Eclipse DemoCamp 2008 w Warszawie, więc będzie okazja się spotkać i przegadać to i owo. A może udział w spotkaniu Warszawa JUG na MIMUW 30-tego? Będzie Szimano, więc dobra zabawa murowana (a że się doktoryzuje, więc i naukowo trochę również będzie ;-)). Zapraszam!

Equinox i jego diag do analizy wymagań pakunku OSGi

Dzisiaj postanowiłem spróbować odpowiedzieć kilku osobom o roli Spring Dynamic Modules (Spring-DM) w integracji Spring Framework, OSGi i aplikacji webowych. Efektem prac miała być demonstracyjna aplikacja webowa, gdzie biblioteki z WEB-INF/lib byłyby osobnymi pakunkami, a sam katalog byłby pusty. Już rozpisałem sobie plan działania - stworzenie projektu aplikacji webowej, pakunków, itp., uruchomienie platformy OSGi (w tej roli Equinox) ze Spring-DM, gdzie w roli głównej występowałby pakunek Spring-DM web extender (spring-osgi-web-extender), i...właśnie, w chwili kiedy napisałem nazwę tego pakunku postanowiłem zacząć od tyłu - od uruchomienia pakunku spring-osgi-web-extender. Jego rolą jest nasłuchiwanie na zdarzenia instalacji i odinstalowywania pakunków, i przy spełnieniu warunków dla pakunków OSGi będących aplikacjami webowymi - rozszerzenie war lub posiadanie katalogu WEB-INF - przekazanie ich do kontenera servletów (dostępne są Apache Tomcat lub Jetty). Już pisałem o nim trochę w notce Aplikacja webowa jako pakunek OSGi ze Spring Dynamic Modules, ale tamto dotyczyło Spring-DM 1.1.0 M2, a teraz pracuję z Spring-DM 1.2.0-m2-SNAPSHOT (zbudowanym samodzielnie ze źródeł - instrukcja w notce Budowanie Spring-DM ze źródeł) i wiele się zmieniło. Stwierdziłem, że do tematu podejdę na opak, gdzie narzędziami diagnostycznymi Equinoksa rozpoznam zależności pakunku spring-osgi-web-extender i po kolei będę je wczytywał. W końcu zbudowałem Spring-DM ze źródeł z włączonymi testami jednostkowymi, więc miałem pewność, że wszystkie niezbędne biblioteki-pakunki miałem w moim lokalnym repozytorium mavenowym.

Rozpocząłem od uruchomienia platformy OSGi, którą był Eclipse Equinox.

 jlaskowski@work /cygdrive/c/apps/equinox
 $ java -jar org.eclipse.osgi_3.5.0.v20080804-1730.jar -console

 osgi> ss

 Framework is launched.

 id      State       Bundle
 0       ACTIVE      org.eclipse.osgi_3.5.0.v20080804-1730

Następnie zainstalowałem pakunek spring-osgi-web-extender (z lokalnego repozytorium mavenowego).

 osgi> install file:/C:/.m2/org/springframework/osgi/spring-osgi-web-extender/
   1.2.0-m2-SNAPSHOT/spring-osgi-web-extender-1.2.0-m2-SNAPSHOT.jar
 Bundle id is 1

 osgi> headers 1
 Bundle headers:
  Bnd-LastModified = 1222091464343
  Build-Jdk = 1.5.0_14
  Built-By = jlaskowski
  Bundle-Activator = org.springframework.osgi.web.extender.internal.activator.WarLoaderListener
  Bundle-Description = Spring/OSGi web extender. Detects war bundles and deployes them into the configured web container.
  Bundle-DocURL = http://www.springframework.org
  Bundle-License = http://www.apache.org/licenses/LICENSE-2.0
  Bundle-ManifestVersion = 2
  Bundle-Name = spring-osgi-web-extender
  Bundle-SymbolicName = org.springframework.bundle.osgi.web.extender
  Bundle-Vendor = Spring Framework
  Bundle-Version = 1.2.0.m2-SNAPSHOT
  Import-Package = org.apache.commons.logging,org.osgi.framework;version="1.3",org.springframework.beans.factory;version="2.5.4",
   org.springframework.core;version="2.5.4",org.springframework.core.task;version="2.5.4",org.springframework.osgi;version="1.2.0.m2",
   org.springframework.osgi.context;version="1.2.0.m2",org.springframework.osgi.context.support;version="1.2.0.m2",
   org.springframework.osgi.util;version="1.2.0.m2",org.springframework.osgi.web.deployer;version="1.2.0.m2",
   org.springframework.osgi.web.deployer.jetty;resolution:=optional;version="1.2.0.m2",
   org.springframework.osgi.web.deployer.support;version="1.2.0.m2",org.springframework.osgi.web.deployer.tomcat;
   resolution:=optional;version="1.2.0.m2",org.springframework.scheduling.timer;version="2.5.4",
   org.springframework.util;version="2.5.4"
  Manifest-Version = 1.0
  Private-Package = org.springframework.osgi.extender.internal.util,
   org.springframework.osgi.extender.internal.util.concurrent,
   org.springframework.osgi.web.extender.internal.activator,
   org.springframework.osgi.web.extender.internal.scanner
  Spring-DM-Version = 1.2.0-m2-SNAPSHOT
  Spring-Version = 2.5.6-SNAPSHOT
  Tool = Bnd-0.0.238

UWAGA: Na zrzucie linia z poleceniem install oraz dla nagłówków Import-Package i Private-Package są "złamane" dla celów prezentacji.

Jak widać na powyższym zrzucie, w nagłówku Import-Package, pakunek spring-osgi-web-extender wymaga wielu pakietów udostępnianych przez inne (wspierające) pakunki. To właśnie wybrałem jako temat rozpoczynający prace - poprawnie zdefiniować wszystkie wymagane zależności pakunku spring-osgi-web-extender na podstawie Import-Package.

Przeglądając źródła Spring-DM, a konkretnie pomy, doszedłem do pierwszych wymaganych pakunków, które spełnią istnienie pierwszego pakietu na liście Import-Package - org.apache.commons.logging:

• org/slf4j/com.springsource.slf4j.org.apache.commons.logging/1.5.0/com.springsource.slf4j.org.apache.commons.logging-1.5.0.jar
• org/slf4j/com.springsource.slf4j.api/1.5.0/com.springsource.slf4j.api-1.5.0.jar
• org/slf4j/com.springsource.slf4j.log4j/1.5.0/com.springsource.slf4j.log4j-1.5.0.jar
• org/springframework/osgi/log4j.osgi/1.2.15-SNAPSHOT/log4j.osgi-1.2.15-SNAPSHOT.jar
  

Po ich zainstalowaniu i uruchomieniu pozostało określić dostawców pozostałych pakietów. Tylko, że po jakimś czasie może pojawić się pytanie - które jeszcze pakiety/pakunki nie są dostępne? Zacząłem rozmyślać, jak fajnie byłoby mieć narzędzie ala Maven w OSGi, które pobierze wymagane pakunki, aby środowisko było poprawnie zestawione dla wybranego pakunku, albo co najmniej ujawni brakujące pakiety. I jakoś szczęśliwie się zdarzyło, że przeglądając wynik equinoksowego polecenia help znalazłem odpowiedź - diag.

 osgi> help
 ---Eclipse Runtime commands---
   diag - Displays unsatisfied constraints for the specified bundle(s).
   enableBundle - enable the specified bundle(s)
   disableBundle - disable the specified bundle(s)
   disabledBundles - list disabled bundles in the system

Polecenie diag dokładnie spełnia moje oczekiwania - wyświetla wymagania niespełnione w środowisku dla wybranego pakunku.

 osgi> diag 1
 file:/C:/.m2/org/springframework/osgi/spring-osgi-web-extender/
  1.2.0-m2-SNAPSHOT/spring-osgi-web-extender-1.2.0-m2-SNAPSHOT.jar [1]
   Direct constraints which are unresolved:
    Missing imported package org.springframework.beans.factory_2.5.4.
    Missing imported package org.springframework.core_2.5.4.
    Missing imported package org.springframework.core.task_2.5.4.
    Missing imported package org.springframework.osgi_1.2.0.m2.
    Missing imported package org.springframework.osgi.context_1.2.0.m2.
    Missing imported package org.springframework.osgi.context.support_1.2.0.m2.
    Missing imported package org.springframework.osgi.util_1.2.0.m2.
    Missing imported package org.springframework.osgi.web.deployer_1.2.0.m2.
    Missing imported package org.springframework.osgi.web.deployer.jetty_1.2.0.m2.
    Missing imported package org.springframework.osgi.web.deployer.support_1.2.0.m2.
    Missing imported package org.springframework.osgi.web.deployer.tomcat_1.2.0.m2.
    Missing imported package org.springframework.scheduling.timer_2.5.4.
    Missing imported package org.springframework.util_2.5.4.

I to jest dokładnie to! Tych pakietów jeszcze nie zainstalowałem. To jest jednakże już praca na kolejne dni.

34. spotkanie Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG)

Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 34. spotkanie, które odbędzie się 30.09.2008 o godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: Podstawy języków formalnych, ANTLR i ANTLRWorks
Prowadzący: Tomek Szymański (vel szimano)

Pisząc różne programy często zdarza się, że mamy jakieś źródło, które wcale nie jest w XMLu ani nawet JSONie... są różne Scannery, Matchery, wyrażenia regularne, ale często to jest za mało i więcej czasu tracimy na "przeczytanie" tego źródła niż na jego "obrobienie". I tutaj wybawieniem jest ANTLR, którego staram się pokazać.

Ale niech nie zrazi was straszny tutuł - podstawy języków formalnych poznać trzeba, ale będzie jak naprzystępniej a potem to już zajmiemy się wyłącznie kodowaniem w naszej ulubionej Javie !

Co jeszcze ? ANTLRWorks - narzędzie z ładnym GUI i różnymi bajerami ułatwiające prace z ANTLRem, zrobienie tego, co mamy na myśli mówiąc "kompilator" - czyli czegoś co wygeneruje program z naszego języka, robienie parserów, obalanie paru mitów i tymczasowe oderwanie od, mogących się na chwile znudzić, technologii webowych, którymi karmimy się na codzień.

Tomek Szymański (vel szimano) - Kontraktor pewnej firmy, która właśnie wypuściła CR2 Application Servera zgodnego z EE 5.0. Zainteresowany narzędziami typu compiler-compiler od momentu, kiedy uczestniczył w odpowiednim przedmiocie na studiach... potem napisał pracę magisterską na ten temat, żeby przez pół roku prowadzić, już jako doktorant (którym nie jest), laboratorium z tych zajęć. Postanowił, że skoro jeszcze coś z tego pamięta, to się podzieli zanim zapomni. Poza tym jest miły, sympatyczny, kulturalny i lubi chodzić w kaszkiecie.

Planowany czas prezentacji to 1,5 godziny, po której planuje się 15-30-minutową dyskusję.

Wstęp wolny!

Zapraszam w imieniu grupy Warszawa JUG!